Data processing agreement

1. Definitions

• Terms such as controller, processor, personal data, processing, data subject, personal data breach and supervisory authority have the meaning given in the GDPR.
• Customer Personal Data: personal data in Customer Content (as defined in the Terms) that Nightsquire processes on the Customer's behalf. Annex 1 describes it.
• Org: the Customer's organisation in the Service.
• Executor: a host that runs the steps of the Customer's runs, either a managed executor operated by Nightsquire for the Customer, or an executor the Customer provides and operates itself.
• Nightsquire AI: the AI model access Nightsquire provides as part of the Service.
• Sub-processor: a third party Nightsquire engages that processes Customer Personal Data.

2. Roles and scope

1. For Customer Personal Data, the Customer is the controller, or a processor acting for its own controller, and Nightsquire is the processor or sub-processor.
2. For account, sign-in, session, security and communication data about the people who use the Service, Nightsquire is the controller. The privacy policy covers that data; this DPA does not.
3. Annex 1 describes the subject matter, nature, purpose and duration of the processing, the types of personal data and the categories of data subjects.
4. The Customer is responsible for the lawfulness of the processing it instructs, including having a legal basis and informing data subjects, and for the personal data it lets the Service process.

3. Instructions

1. Nightsquire processes Customer Personal Data only on the Customer's documented instructions, unless EU or Irish law requires otherwise; in that case Nightsquire informs the Customer first, unless the law prohibits this.
2. The Customer's instructions are the Terms and this DPA; the configuration the Customer and its Users set in the Service, such as the connected GitLab instance, enabled projects, project configuration, the choice of executors and AI model, and network and tool settings; and other written instructions the parties agree.
3. Nightsquire tells the Customer without delay if, in its opinion, an instruction infringes the GDPR or other data protection law.

4. Confidentiality

Nightsquire ensures that everyone it authorises to process Customer Personal Data is bound by confidentiality, by contract or by law, and accesses Customer Personal Data only as far as needed to provide, secure or support the Service, or to comply with the law.

5. Security

1. Nightsquire implements the technical and organisational measures in Annex 2 to ensure a level of security appropriate to the risk (Article 32 GDPR). It may update them, provided the overall level of protection is not reduced.
2. The Customer is responsible for the security of what it controls, including its own executor hosts and their network; its GitLab instance, the bot user and its permissions; its own model provider account and credentials; its projects' network and tool settings; and who it lets trigger runs and access its Org.
3. The Customer is responsible for checking that the measures in Annex 2 are appropriate for the data it processes.

6. Sub-processors

1. The Customer gives Nightsquire general authorisation to engage sub-processors. The current sub-processors are listed in Annex 3.
2. Nightsquire informs the Customer before adding or replacing a sub-processor, by email to the Org's owners or in the dashboard. The Customer may object on reasonable data protection grounds. If the parties cannot resolve the objection, the Customer may end its use of the Service; this is its only remedy.
3. Nightsquire imposes data protection obligations on each sub-processor that offer at least the same protection as this DPA, and remains responsible to the Customer for its sub-processors' performance.

7. Services the Customer chooses itself

The following are not sub-processors of Nightsquire. The Customer engages and uses them under its own agreements and is responsible for them, including any transfers outside the EEA:

• a model provider of the Customer's own, such as Anthropic through the Customer's Claude API key, or any OpenAI-compatible API. Model calls then go directly from the executor to that provider under the Customer's account. Nightsquire stores the Customer's credential and hands it to the executor's gateway for each step that needs it;
• the Customer's GitLab instance, gitlab.com or self-managed, from which events are received and to which results are posted;
• the Customer's own executor hosts, and anything executors reach under the project's network policy, such as package and container registries and, in open network mode, any public internet host.

8. International transfers

Nightsquire processes Customer Personal Data in the EU and does not transfer it outside the EEA. If that changes, Nightsquire will do so only with appropriate safeguards under Chapter V GDPR, and will inform the Customer under section 6.

9. Assistance

1. Data subject requests. Taking into account the nature of the processing, Nightsquire helps the Customer respond to requests from data subjects. If Nightsquire receives a request directly, it forwards it to the Customer without undue delay and does not answer it unless the Customer instructs it to.
2. Other obligations. Nightsquire provides reasonable help with the Customer's obligations under Articles 32 to 36 GDPR (security, breach notification, data protection impact assessments and prior consultation), taking into account the information available to it.
3. Nightsquire may charge reasonable costs for help that goes beyond what the Service offers, after telling the Customer in advance.

10. Personal data breaches

1. Nightsquire notifies the Customer without undue delay, and where possible within 48 hours, after becoming aware of a personal data breach affecting Customer Personal Data.
2. The notification describes, as far as known, the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken or proposed. Information not yet available is provided as soon as it is.
3. Nightsquire takes reasonable steps to contain the breach and limit its consequences, and keeps a record of breaches.
4. The Customer decides whether to notify the supervisory authority and data subjects.

11. Deletion and return

1. When the Customer's use of the Service ends, Nightsquire deletes Customer Personal Data within 30 days, unless EU or Irish law requires it to keep it. Managed executors of the Org are destroyed, with their disks.
2. Before the end of the Service, the Customer's Org owners can export the Org from the dashboard as a JSON archive (configuration, projects, run and step metadata, members and the audit log; never secret values), downloadable for 7 days. Deleting the Org takes effect after a 7-day grace period in which it can be cancelled.
3. Copies in backups are overwritten within 30 days after deletion. Until then they stay protected under this DPA and are not used.
4. During the Service, the Customer can delete individual items where the Service offers this, such as credentials, projects and executors. Other deletions can be requested at security@nightsquire.dev.
5. Data stored on the Customer's own executors, in its GitLab instance or with its own model provider is not held by Nightsquire and is not covered by this section.

12. Information and audits

1. Nightsquire makes available the information reasonably needed to demonstrate compliance with Article 28 GDPR, including this DPA and its annexes, and answers reasonable written questions.
2. If that information is not sufficient, the Customer may have an audit carried out at its own cost, by itself or an independent auditor bound by confidentiality, at most once a year (more often after a personal data breach or at a supervisory authority's request), with at least 30 days' notice, during business hours, without disrupting the Service or giving access to other customers' data.

13. Liability, term and governing law

1. The limitations of liability in the Terms apply to this DPA, as far as the law allows.
2. This DPA applies for as long as Nightsquire processes Customer Personal Data for the Customer. Sections that by their nature continue after the end of the Service, such as 4, 10, 11 and 12, continue to apply.
3. If this DPA conflicts with the Terms on the processing of personal data, this DPA prevails.
4. This DPA is governed by the laws of Ireland, and the courts of Ireland have exclusive jurisdiction.

Annex 1. Description of the processing

Subject matter and purpose. Providing the Service to the Customer: receiving GitLab events for the Customer's enabled projects, deciding whether and how to act on them, planning and coordinating runs, running steps on executors, providing Nightsquire AI where the Customer uses it, storing the results, logs and records of runs, posting results to the Customer's GitLab through the bot user, and showing all of this in the dashboard.

Nature of the processing. Receiving, storing, organising, retrieving, displaying, transmitting and deleting data, mostly automatically. Steps run on executors: on managed executors that Nightsquire operates for the Customer on Scaleway, or on the Customer's own executors. Where the Customer uses Nightsquire AI, the agent's prompts, which contain code, issue text and tool output, are sent from the executor to Scaleway's AI inference service in Paris and the responses returned.

Access to the Customer's GitLab. Through the bot user, the Service reads the enabled projects and posts results to them. A run may also read other projects of the Customer's GitLab that it needs, such as CI includes, CI components and submodules, but only what the User who started the run can read themselves: the Service checks each such read against that User's GitLab access first and refuses it otherwise. The Service writes to the Customer's GitLab only through the bot user. It pushes to the run's own branch, or, for a CLAUDE.md a User asked for, to its <prefix>claude-md branch (the branch prefix the Customer configures, followed by claude-md) with a draft merge request. It opens and updates merge requests and posts comments, plans and reviews. It creates issues, such as follow-up issues, only when a User who may start runs asks for them. It never merges.

Duration. For as long as the Customer uses the Service, plus the deletion period in section 11.

Categories of data subjects.

• The Customer's Users and other members of its GitLab instance.
• People whose content or details appear in the Customer's GitLab projects: authors of and people mentioned in issues, merge requests and comments, commit authors, and people whose personal data is in repository content.
• Anyone else whose personal data the Customer chooses to include in projects, configuration or instance notes.

Types of personal data and where they are processed.

Nightsquire also keeps records of acceptance of the Terms (per User) and of this DPA (per Org): who accepted, which version, when, and the IP address and browser they accepted from. It keeps them as controller, as evidence of the agreement, for as long as the account or the Org exists; the privacy policy describes them.

Special categories of personal data (Article 9 GDPR) and data on criminal convictions are not intended to be processed. The Customer should not include them in projects processed by the Service.

Storage limits. Per-step budgets cap stored logs (default 20 MiB) and egress records (5,000 per step). Large repository bundles and source snapshots are dropped from a run's state once no later step needs them. Stored run data is deleted automatically after retention periods the Customer sets per Org within fixed bounds; defaults are 30 days for webhook payloads, 90 days for logs, transcripts, egress records, step files and executor update logs, 30 days for executor host egress records, and 365 days for the audit log. The notification delivery log is kept 90 days. Project access checks are removed with the membership or the project. Run and step metadata (status, timings, usage), access gaps, follow-up issues and CLAUDE.md suggestions are kept while the Org exists.

Annex 2. Technical and organisational measures

Hosting

• The control plane (application, database and file storage) runs on netcup in Nuremberg, Germany. Managed executors, Nightsquire AI, backups and transactional email run on Scaleway in Paris, France.
• Managed executors are dedicated to one Org and never shared between customers.

Encryption

• Every connection to the Service uses TLS: the dashboard and API, GitLab webhooks (created with SSL verification on), executor connections and calls to Nightsquire AI.
• Every stored secret is encrypted with AES-256-GCM under a data encryption key of its Org. Org keys are stored in the database only in wrapped form, encrypted with a platform key that is held in the server environment and never stored in the database.
• Executor credentials and registration tokens are stored only as SHA-256 hashes.

Credential handling

• Secrets are write-only through the API: once saved, the Service shows only their type, date and the last four characters.
• Secrets are never written to logs, and known secret values and common token formats are redacted from stored logs, transcripts and webhook payloads.
• Model credentials and the GitLab bot token never enter the container in which the agent runs. Each step gets random placeholders; the executor's egress gateway fetches the real credential for that step only, while it runs, and inserts it into outgoing requests. Each credential issue is recorded in the audit log, never the value.
• The gateway's GitLab route allows only the API calls the steps need. Pushes may only create or update the run's own branch or, for a CLAUDE.md, the bot's <prefix>claude-md branch, for which a draft merge request is opened. Issues, such as follow-up issues, are created only when a User who may start runs asks for them. Agent steps get a read-only GitLab route and no GitLab write access.
• Every run records the GitLab user who started it. Before a step reads a project other than the run's own, or creates an issue in one, the gateway asks the Service whether that user could do so in GitLab themselves. If not, or if the check fails, the request is refused and nothing from that project reaches the step.

Org isolation and access control

• Every record belongs to one Org. Database row-level security is a second layer behind an Org-scoped data access layer, checked at startup and by a cross-tenant test suite on every change.
• Webhooks are addressed by a random per-project key and verified with a per-project secret; unverified webhooks are rejected and nothing is stored.
• Executors belong to one Org and only receive that Org's work.
• Users sign in through the Customer's own GitLab instance or with a single-use email link. GitLab accounts are identified by their numeric user id, so a reused username cannot take over access. Only users the Org authorises can trigger runs.
• Owners and admins see every project of the Org. Members and viewers see only the projects their linked GitLab account can read, by a check at most 15 minutes old; without a current answer the project is hidden.
• Roles per Org: owner, admin, member and viewer. The platform admin interface shows Org metadata, never Org content; every operator action is recorded in a platform audit log.
• GitLab URLs supplied by customers are checked on every request: HTTPS only; private, loopback, link-local and the Service's own networks refused.
• Web application protection: same-origin checks, strict security headers, request size limits and time-outs, and rate limiting of sign-in.

Execution

• Each step runs in its own container, removed afterwards: non-root user, all Linux capabilities dropped, no privilege escalation, read-only root filesystem, CPU, memory, process and time limits. Where a step needs Docker, an unprivileged Docker daemon in a Sysbox sandbox runs alongside it, never on the host's Docker socket.
• Steps have no direct network access. They reach the network only through the egress gateway, which refuses loopback, link-local (including cloud metadata) and the executor's own networks, and private ranges unless the executor's operator exempts one, applies the project's network policy and records every connection.
• Executors connect outbound to the Service and accept no inbound connections from it.
• Managed executors are patched and rebooted in a maintenance window. An outbound lockdown of the host can be switched on; it is off by default.

Logging, retention and deletion

• An audit log per Org records sign-ins, settings and configuration changes, credential changes and issues, member changes, project and executor management, and run cancellations and retries.
• Retention periods per Org and data type, applied by an automatic job.
• Self-service Org export, and Org deletion after a 7-day grace period that destroys the Org's data encryption keys, so its secrets cannot be decrypted from the live database or from later backups.
• The database and stored files are backed up daily to Scaleway Object Storage in Paris, separate from the database, and kept for 30 days. Backups are useless without the encryption key, which is stored separately.

Organisation

• Access to production systems is limited to personnel who need it, bound by confidentiality.
• Changes go through merge requests with automated tests. Build images are pinned by digest.

Annex 3. Sub-processors

Not sub-processors (chosen and contracted by the Customer, see section 7): the Customer's own model provider, its GitLab instance and its own executor hosts. The marketing website at nightsquire.dev processes no Customer Personal Data.