Data Processing Agreement

This Data Processing Agreement ("DPA") is part of the agreement between Immersive Investments B.V., a private limited liability company (besloten vennootschap) under Dutch law with its statutory seat in The Hague, the Netherlands, registered with the Dutch Chamber of Commerce (KvK) under number 85865958, trading as n8v ("n8v") and the customer that has accepted the n8v Terms of Service (the "Customer"). It applies whenever n8v processes personal data on the Customer's behalf while providing the Service ("Customer Personal Data"). Terms defined in the Terms of Service have the same meaning here.

1. How this DPA is built

1.1 This DPA incorporates the standard contractual clauses between controllers and processors set out in the Annex to Commission Implementing Decision (EU) 2021/915 of 4 June 2021 (the "Clauses"), published at https://eur-lex.europa.eu/eli/dec_impl/2021/915/oj. The Clauses apply as if written out in full in this DPA, with the Annexes at the end of this DPA.

1.2 The parties select the following options in the Clauses:

1.3 Sections 2 to 11 of this DPA are additional clauses within the meaning of Clause 2(b). They do not contradict the Clauses. If they do, the Clauses prevail (Clause 4).

1.4 If the Customer acts as a processor for its own client, n8v acts as the Customer's sub-processor. The Customer confirms that its controller has authorised the use of n8v and the sub-processors in Annex IV, and the Customer passes on its controller's instructions to n8v.

2. Roles and instructions

2.1 The Customer is the controller of Customer Personal Data and n8v is its processor. n8v is a separate controller for the account, billing, security and analytics data described in its privacy notice.

2.2 The Customer's documented instructions (Clause 7.1) are:

1. the Terms of Service, including this DPA;
2. the Customer's use and configuration of the Service, including the tasks it gives agents, the repositories and services it connects, and its calls to the API; and
3. any other written instruction the parties agree.

2.3 The Customer is responsible for:

1. having a lawful basis for the processing it instructs, and for informing its data subjects;
2. only bringing personal data into the Service that it needs for its tasks. The Service is built for source code, not for production datasets about people;
3. not bringing special categories of personal data (Article 9 GDPR) or data about criminal convictions (Article 10 GDPR) into the Service, unless it has assessed the need and informed n8v in writing; and
4. the configuration of its connected services, agent permissions and credentials.

3. Sub-processors

3.1 The Customer gives n8v general written authorisation to engage the sub-processors listed on the subprocessor page, which forms Annex IV.

3.2 n8v informs the Customer at least 30 days before it adds or replaces a sub-processor, by email to the Customer's admins and on the subprocessor page. The notice names the sub-processor, its purpose, the data involved, its location and the transfer mechanism.

3.3 The Customer may object in writing within the notice period on reasonable grounds relating to data protection. The parties then discuss alternatives in good faith, such as not using the sub-processor for the Customer's data. If the objection is not resolved before the change takes effect, the Customer may terminate the affected part of the Service without penalty and receives a refund of prepaid fees and unused credits for the affected part.

3.4 If a sub-processor must be replaced urgently to keep the Service running or secure (for example because it fails or suffers a security incident), n8v may engage the replacement on shorter notice. It informs the Customer as soon as possible and the objection right in section 3.3 applies from that moment.

3.5 n8v imposes the same data protection obligations in substance on each sub-processor (Clause 7.7(b)) and remains fully responsible to the Customer for their performance (Clause 7.7(d)).

3.6 These are not sub-processors: the services the Customer connects and the model provider accounts or keys the Customer brings (see section 2 of the subprocessor page). Data flows to them on the Customer's instruction and under the Customer's own agreements with them. Experimental third-party models that the Customer explicitly opts into are outside this DPA.

4. International transfers

4.1 n8v transfers Customer Personal Data outside the European Economic Area only in line with Clause 7.8 and Chapter V GDPR: to recipients covered by an adequacy decision, including US recipients certified under the EU-US Data Privacy Framework (Commission Implementing Decision (EU) 2023/1795), or on the basis of the standard contractual clauses in Commission Implementing Decision (EU) 2021/914 (Module 3, processor to processor) with the sub-processor.

4.2 n8v is preparing a transfer impact assessment for each transfer that relies on standard contractual clauses, and provides a summary on request once it is complete.

4.3 If the Data Privacy Framework adequacy decision is suspended, amended or invalidated, n8v relies on standard contractual clauses with the affected sub-processors and informs the Customer of the change.

5. Security and confidentiality

5.1 n8v implements at least the technical and organisational measures in Annex III (Clause 7.4). It may change them over time, provided the overall level of protection does not decrease.

5.2 Only personnel who need access to run, support or secure the Service have access to Customer Personal Data. They are bound by confidentiality obligations.

5.3 n8v personnel access Customer Content only to provide support the Customer requests, to investigate a security incident or abuse, to keep the Service running, or to comply with the law.

6. Personal data breaches

6.1 n8v notifies the Customer of a personal data breach concerning Customer Personal Data without undue delay after becoming aware of it, and in any event within 48 hours. This supplements Clause 9.2.

6.2 The notification contains the information listed in Clause 9.2, as far as available, plus the time the breach was discovered and the measures n8v has taken. Information that is not yet available follows in stages, without undue delay.

6.3 n8v sends the notification to the Customer's admins by email and remains available through [email protected]. The Customer keeps its admin contact details current.

6.4 A notification is not an admission of fault or liability.

7. Assistance

7.1 n8v forwards to the Customer any request it receives from a data subject about Customer Personal Data and does not respond itself unless the Customer authorises it (Clause 8(a)).

7.2 The Customer can retrieve tasks and their messages through the API, and other Customer Content on request. Self-service export and deletion are not available in the product yet; until they are, n8v exports or deletes specific Customer Content on the Customer's written request within 30 days.

7.3 n8v assists with data protection impact assessments and prior consultations (Clause 8(c)) by providing the information in this DPA, the security overview and reasonable answers to follow-up questions.

7.4 Assistance through the standard features of the Service, and reasonable assistance required by the Clauses, is free of charge. For assistance that takes substantial effort beyond that, n8v may charge reasonable costs agreed in advance.

8. Audits

8.1 n8v makes available the information needed to demonstrate compliance (Clause 7.6(c)), including this DPA, the security overview, relevant sub-processor certifications or reports it is allowed to share, and answers to one reasonable security questionnaire per year.

8.2 If that information is not sufficient, or a supervisory authority requires it, or after a personal data breach, the Customer may carry out an audit itself or mandate an independent auditor bound by confidentiality who is not a competitor of n8v (Clause 7.6(d)). The Customer gives at least 30 days' notice (shorter after a breach), the audit takes place during business hours without undue disruption, and it happens no more than once in any 12 months except after a breach or at the request of a supervisory authority. Each party bears its own costs, unless the audit shows a material breach of this DPA by n8v, in which case n8v bears the reasonable audit costs.

8.3 Audits of sub-processors take place through the reports and certifications they provide, unless the Clauses require otherwise.

9. Return and deletion

9.1 During the term, the Customer can export Customer Content as described in section 25 of the Terms of Service.

9.2 When the agreement ends, the Customer chooses between return and deletion (Clause 10(d)). Customer Content remains available for export during the retrieval period in the Terms of Service, which is at least 30 days. After that period, n8v deletes Customer Personal Data from its active systems within 30 days.

9.3 Deleted data remains in database backups until they are overwritten, which happens on a rolling basis within about 35 days. n8v does not restore deleted data from backups except to recover from a disaster, and deletes it again if that happens.

9.4 E2B keeps paused sandboxes until they are explicitly deleted, so n8v deletes them itself. n8v deletes the Customer's sandboxes within 7 days after the agreement ends.

9.5 On request, n8v confirms the deletion in writing.

10. Liability

10.1 Each party's liability under this DPA is subject to the limitations in the Terms of Service, to the extent the law allows. This does not limit the rights of data subjects under the Clauses or under Article 82 GDPR.

11. Term and order of precedence

11.1 This DPA applies for as long as n8v processes Customer Personal Data, including after the end of the agreement.

11.2 In case of conflict: the Clauses prevail, then this DPA, then the Terms of Service.

11.3 This DPA is governed by Dutch law. The courts designated in the Terms of Service have jurisdiction.

Annex I: List of parties

Controller

Processor

Annex II: Description of the processing

Categories of data subjects

1. The Customer's authorised users, including the Customer itself when it is a sole trader.
2. People whose data appears in the Customer's repositories and tasks: authors and committers in commit history, contributors, reviewers, and people named in code, comments, issues, pull requests, documentation or test data.
3. People whose data appears in the connected services the Customer lets agents use: correspondents in email, members and message authors in Slack, authors and assignees of Plane work items, and people in systems reached through MCP servers.
4. The Customer's own clients, end users or other contacts, if the Customer brings their data into repositories, files, databases or environments that agents access.

Categories of personal data

1. Identification and contact data inside Customer Content: names, usernames, email addresses, commit metadata.
2. Content: source code, prompts, messages, agent outputs, files and attachments, voice recordings from dictation, command output and logs produced in sandboxes.
3. Credentials that may relate to individuals: API keys, OAuth tokens, environment variables and other secrets the Customer configures.
4. Communication content accessed through connected services: email messages and drafts, Slack messages, Plane work items.
5. Technical data from the Customer's own systems that agents access, such as IP addresses in logs.

Sensitive data

None intended (see section 2.3). If such data is nevertheless present, the measures in Annex III apply, in particular encryption in transit, restricted personnel access, the exclusion of model training and the deletion periods below.

Nature of the processing

Storage; retrieval; cloning repositories into isolated sandboxes; running code, tests and tools in those sandboxes; sending task context to AI model providers to generate outputs; creating branches, commits and pull requests; transcribing voice input; sending notifications to connected services; backup; deletion.

Purposes

Providing the Service under the agreement: running the tasks the Customer instructs, operating the integrations and the API, giving support the Customer requests, securing the Service and preventing abuse, and recovering from incidents.

Duration and retention

For the term of the agreement plus the retrieval and deletion periods in section 9. Within that term:

Processing by sub-processors

Subject matter, nature and duration as set out for each sub-processor in Annex IV.

Annex III: Technical and organisational measures

These measures describe the Service on the effective date of this version. Planned measures are listed separately and are not yet commitments.

1. Organisation and personnel

1. Production access is limited to named administrators, who are bound by confidentiality.

2. Access control for the Service

1. Users sign in with GitHub or with a one-time link sent to their email address, so multi-factor authentication depends on the user's GitHub settings. We recommend that customers require it in their GitHub organisation.
2. Sessions expire after 60 days. API access uses API keys or OAuth 2.0 client credentials.
3. Internal administration functions require the administrator role.

3. Access control for infrastructure

1. The database server accepts SSH with keys only; password login is disabled. fail2ban and a host firewall are active, and security updates install automatically.
2. PostgreSQL listens on the local interface only. External connections go through PgBouncer, which requires SCRAM-SHA-256 authentication and refuses unencrypted connections.
3. Backup storage uses credentials scoped to the backup bucket only.

4. Encryption

1. All traffic to the web application, API and object storage uses TLS.
2. The database only accepts TLS connections, and the application verifies the server certificate in full (TLS 1.3 negotiated, TLS 1.2 minimum).
3. Credentials and secrets (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. Each value gets a random salt and initialisation vector, and the key is derived with scrypt from a master key that is held as a secret in our hosting platform, not in the database. The application can still read tokens that older versions stored without encryption; removing these is a planned measure.
4. Object storage (Cloudflare R2) and sandbox storage (E2B on Google Cloud) are encrypted at rest by those providers.
5. Outgoing webhooks carry an HMAC-SHA256 signature with a timestamp.

5. Isolation

1. Each task runs in its own sandbox, a separate microVM with its own kernel.
2. Sandboxes pause after 15 minutes of inactivity. Because E2B keeps paused sandboxes until they are deleted, n8v deletes them as described in Annex II.
3. Repository access uses GitHub App installation tokens, which GitHub issues with a one-hour lifetime, for the repositories the Customer selected when installing the app.
4. Files attached to tasks are stored in a private bucket and served only through short-lived signed links.

6. Availability and recovery

1. The database streams its write-ahead log to backup storage continuously, at least every 60 seconds.
2. A base backup runs daily (a full backup weekly, deltas in between). The five most recent full backup chains are kept, about 35 days.
3. Backups are stored in a Cloudflare R2 bucket restricted to the EU jurisdiction.
4. An automated restore drill runs monthly and compares the restored data with production. The drill on 27 September 2026 restored the database in 46 seconds.
5. A health check on the database host runs every 5 minutes (database, pooler, archiving, backups, disk, certificate) and alerts the operator. An independent watchdog on separate infrastructure checks every 10 minutes that the host reports, that backups arrive and that the application responds.

7. Data minimisation, retention and model use

1. Short-lived coordination data in Redis expires within 24 hours.
2. n8v does not use Customer Content to train AI models. OpenAI, Anthropic and Google are used on terms that exclude training on API data. Models reached through OpenRouter are served by upstream providers under their own terms (Terms of Service, section 12.2).
3. Experimental models whose operators retain prompts are switched off by default, are not included in preview programmes, and are only enabled for an account after an explicit opt-in.

8. Development and change management

1. Changes go through version control, pull requests and automated tests before release.
2. Database schema changes follow a written runbook.

9. Incident response and assistance to the Customer

1. Breach notification within 48 hours, as in section 6.
2. To help the Customer meet Articles 33 and 34 GDPR, n8v provides: the categories and approximate number of data subjects and records concerned; the systems and sub-processors involved; the timeline; the likely consequences; the measures taken; and a contact point. It updates this information as the investigation proceeds.

10. Sub-processor management

1. n8v checks the security documentation and data processing terms of each sub-processor before engaging it. The status of each agreement is shown on the subprocessor page.

Planned measures (not yet in place)

1. Moving sandboxes to E2B's EU region (europe-west1, Belgium).
2. A dedicated database host with an encrypted disk (the current host also runs other services of the operator and its disk is not encrypted).
3. Client-side encryption of database backups before upload.
4. Moving any files attached under the earlier setup, which used unguessable but public links, to private storage.
5. Removing the remaining tokens that older versions stored without encryption.
6. Self-service export and deletion for customers.
7. Logging of administrator access to Customer Content through the admin pages. Administrators acting as a user's account are recorded since 1 November 2026.

Annex IV: List of sub-processors

The Customer has authorised the sub-processors listed on the subprocessor page (general written authorisation, Clause 7.7(a) Option 2). At the date of this version they are: Vercel Inc.; Hetzner Online GmbH; Cloudflare, Inc.; FoundryLabs, Inc. (E2B); Upstash, Inc.; PostHog, Inc.; OpenAI Ireland Ltd; Anthropic Ireland, Limited; Google LLC; OpenRouter, Inc.; Apple Inc.; Plus Five Five, Inc. (Resend); and, from the moment they are enabled after notice, Stripe, Loops and Daytona. The subprocessor page states the purpose, data, location and transfer mechanism for each.