Security
Effective 1 November 2026
n8v runs AI coding agents on your source code, so the questions we expect are concrete: where the code goes, who can reach it and what happens when something breaks. This page answers them for the service as it runs on the effective date above. It has three parts: a security overview, our responsible disclosure policy and our security.txt file.
Security overview
1. Where your data is
- The primary database (PostgreSQL 16) runs on a server in Helsinki, Finland. Its backups are stored in a bucket restricted to the EU jurisdiction.
- The web application and API run in Dublin, Ireland. A move to Stockholm, Sweden, is under consideration.
- Agent sandboxes currently run in the USA (Oregon), in our sandbox provider's default region. Its EU region is not enabled for n8v yet, and no date for a move is set.
- Our subprocessor page lists every provider, what it processes and where.
2. Isolation
- Every task runs in its own sandbox: a separate microVM with its own kernel, not a container on a shared host.
- Agents reach your repositories through our GitHub App. It only covers the repositories you grant it when you install it, and the access tokens GitHub issues for it expire after one hour.
- Sandboxes pause after 15 minutes of inactivity. Our sandbox provider keeps paused sandboxes until they are deleted, so we delete them ourselves. An automated job deletes a sandbox 7 days after its task is archived and at the latest 30 days after its last activity, once all work in it has reached your repository host.
- Files you attach to tasks are stored in a private bucket and served only through short-lived signed links.
3. Encryption
- All connections to the web app, API, realtime service and file storage use TLS.
- The database only accepts TLS connections, and the application verifies its certificate in full.
- Credentials you give us (model provider keys and tokens, environment variables, OAuth tokens for GitHub, Slack, Gmail and Plane, MCP credentials) are encrypted in the database with AES-256-GCM. The key is derived from a master key that is kept outside the database.
- File storage and sandbox storage are encrypted at rest by the providers.
- Webhooks we send are signed with HMAC-SHA256 and a timestamp, so your endpoint can verify them.
4. Access
- You sign in with GitHub or with a one-time link sent to your email address. We recommend requiring two-factor authentication in your GitHub organisation.
- Sessions expire after 60 days. API access uses API keys or OAuth 2.0 client credentials that you can revoke.
- Our database server only accepts SSH keys, runs a firewall and installs security updates automatically. The database itself only listens locally; outside connections must use TLS and SCRAM-SHA-256 authentication through a connection pooler.
- n8v staff only look at your content when you ask for support, to investigate a security incident or abuse, to keep the service running, or when the law requires it. When staff act as your account to help you, we record who did it and when.
5. Backups and recovery
- Database changes are archived continuously, at least every 60 seconds.
- A base backup runs every day (a full backup every week). We keep the five most recent full backup chains, about 35 days.
- A restore drill runs every month and checks the restored data against production.
- A health check runs every 5 minutes and alerts us about database, backup, disk or certificate problems. A separate watchdog on other infrastructure checks every 10 minutes that the checks still report, that backups keep arriving and that the app responds.
6. AI-specific safeguards
- We do not train AI models on your content. OpenAI, Anthropic and Google, which we use under our own accounts, do not either. Models reached through OpenRouter are served by upstream providers under their own terms; see section 12 of the Terms of Service.
- Experimental models whose operators keep prompts are off by default, never switched on through a preview programme, and only available after an explicit opt-in.
- Agents read untrusted text: issues, web pages, dependencies, emails. Such text can contain instructions meant to mislead them (prompt injection). Limit what agents can reach, keep secrets scoped and review what they produce before it lands in production.
- Commits made by agents carry a co-author line that identifies our GitHub App, so you can always see which changes came from an agent.
7. What you are responsible for
- Install the GitHub App only on the repositories agents need.
- Keep branch protection and required reviews on production branches.
- Give agents scoped, revocable secrets, never production credentials that allow irreversible actions.
- Review and test AI Output before you merge or deploy it.
- Remove people who leave your team.
- Tell us at [email protected] as soon as you suspect a compromise.
8. Incidents
If a personal data breach affects your data, we notify your admins without undue delay and within 48 hours, and keep you updated as we learn more. Our Data Processing Agreement sets out the details.
9. Certifications
n8v does not hold a security certification such as SOC 2 or ISO 27001 yet. Some of our providers do; we share their reports where their terms allow.
10. What we are still building
We list these openly, and they are also listed in Annex III of our Data Processing Agreement:
- an EU region for sandboxes;
- a dedicated database server with an encrypted disk;
- client-side encryption of database backups;
- moving any files attached under our earlier setup, which used unguessable but public links, to private storage;
- removing the remaining tokens that older versions stored without encryption;
- self-service export and deletion;
- logging of staff access to customer content through the admin pages (acting as your account to help you is recorded since 1 November 2026).
Responsible disclosure policy
We welcome reports from security researchers and work with them to fix problems quickly. This policy follows the Dutch National Cyber Security Centre's guideline on coordinated vulnerability disclosure. It also covers vulnerabilities in our iOS app and CLI.
1. Scope
In scope:
- n8v.online and the n8v.online subdomains we operate for the service;
- our public API, A2A endpoint, OAuth endpoints and webhooks;
- the realtime service used by the web app;
- the n8v GitHub App, iOS app and CLI;
- isolation between customers, including prompt injection that crosses from one customer to another and escape paths out of your own sandbox.
Out of scope:
- systems of our providers and of the services you connect (for example GitHub, our sandbox provider, Cloudflare, Vercel, Slack, Telegram, Plane, Google and AI model providers); please report to them directly;
- denial of service and load testing;
- social engineering, phishing of our staff and physical attacks;
- reports without a demonstrated security impact, such as missing security headers, clickjacking on pages without sensitive actions, software version disclosure or email configuration findings;
- self-XSS, and issues that need an outdated browser or a rooted or jailbroken device;
- output of automated scanners without a working proof of concept;
- jailbreaks or unwanted content from AI models, unless they give access to data or systems of n8v or other customers.
2. Rules
- Use your own accounts. Do not access, change or delete data of other customers.
- If you encounter personal data, secrets or customer code, stop, do not copy it, and tell us which data you saw.
- Use the minimum access needed to show the problem. Do not install backdoors or keep access.
- Keep automated testing below 5 requests per second.
- Research sandbox isolation only from your own sandboxes, and do not attack our providers' infrastructure.
- Keep the details confidential until we have fixed the problem, and agree the disclosure date with us.
3. Safe harbour
If you act in good faith and follow this policy, we will not report you to the police or take legal action against you for your research. We cannot make that promise on behalf of third parties or the Public Prosecution Service, but if a third party takes action against you, we will confirm that you acted under this policy.
4. How to report
Email [email protected] in English or Dutch. Please include:
- the affected asset (URL, endpoint, app version);
- a description of the vulnerability and its impact;
- the steps to reproduce it, or a proof of concept;
- how we can reach you.
Please do not report vulnerabilities through social media or public issue trackers.
5. What you can expect
| Step | Target |
|---|---|
| Acknowledgement of your report | Within 3 business days |
| First assessment and severity | Within 10 business days |
| Status updates | At least every 14 days |
| Fix of a critical vulnerability | Within 7 days |
| Fix of a high-severity vulnerability | Within 30 days |
| Fix of a medium-severity vulnerability | Within 90 days |
| Public disclosure | After the fix, or 90 days after your report, whichever comes first, on a date we agree |
We do not pay bounties at the moment. With your permission we thank you by name below.
Acknowledgements
We name researchers here, with their permission, once the problem they reported is fixed.
security.txt
Our contact details for security researchers are also published in machine-readable form, following RFC 9116, at /.well-known/security.txt.