Data Processing Agreement (Art. 28 GDPR) - FragonForge

Version: 2026-07-16

1. Parties and roles

This DPA is entered into between:

  • the Customer (the account holder using FragonForge), acting as the controller; and
  • Fragon Studios e.U., Moosfelderstraße 45, 4030 Linz, Austria, acting as the processor ("Provider").

It governs the processing of personal data by the Provider on behalf of the Customer under Art. 28 GDPR, in connection with the Customer's use of the FragonForge service. Where this DPA and the Terms of Service conflict on data protection, this DPA prevails.

2. Subject matter and duration

2.1 Subject matter. The Provider processes personal data contained in the repositories, issues, and source code that the Customer connects to FragonForge, and the associated account and operational data, solely to provide the Service as described in the Terms.

2.2 Duration. This DPA applies for as long as the Provider processes personal data on the Customer's behalf, that is, for the term of the underlying contract, and ends with the deletion or return of the data under clause 11.

3. Nature and purpose of processing

The Provider runs an autonomous coding agent on the Customer's instruction: it checks out a connected repository, executes the agent inside an isolated per-run sandbox, and proposes changes as branches and merge or pull requests. Processing operations include: storage of connection settings and credentials (encrypted), checkout of repository content into an ephemeral sandbox, execution of agent commands, generation of run logs (agent output only, secret-redacted), optional indexing of source code for retrieval on paid plans, and forwarding of the agent's model calls through an egress proxy to the Customer's own LLM provider.

4. Categories of data subjects and personal data

4.1 Data subjects may include: the Customer's personnel and authorized users; and any natural persons whose personal data happens to be contained in the Customer's repositories, issues, commits, or code (for example authors in commit metadata, or personal data embedded in code, comments, test data, or issues).

4.2 Categories of personal data may include: account and identity data of authorized users; forge access tokens and webhook secrets; repository and issue metadata; the content of issues and source code processed during runs (which may incidentally contain personal data); run logs; code-index chunks and embeddings on paid plans; and operational metadata.

4.3 The Customer determines what data it connects and is responsible for the lawfulness of that data and for not connecting special categories of data (Art. 9 GDPR) unless it has ensured a lawful basis and appropriate safeguards.

5. Documented instructions

5.1 The Provider processes personal data only on the Customer's documented instructions, including regarding transfers, unless required to process by Union or Member State law; in that case the Provider informs the Customer of that legal requirement before processing, unless the law prohibits it.

5.2 The Customer's documented instructions are set out in this DPA, the Terms, and the configuration and actions the Customer takes in the Service (for example connecting a repository, labeling an issue, triggering a run, enabling the code index). Additional or changed instructions must be agreed in text form.

5.3 The Provider informs the Customer if, in its opinion, an instruction infringes the GDPR or other data protection law.

6. Confidentiality

The Provider ensures that persons authorized to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality, and that access is limited to personnel who need it to provide the Service.

7. Technical and organizational measures (Art. 32)

The Provider implements appropriate technical and organizational measures to ensure a level of security appropriate to the risk. The measures are set out in Annex 1 and are derived from the Provider's published security architecture. The Provider may update the measures as technology evolves, provided the level of protection is not reduced.

8. Sub-processors

8.1 General authorization. The Customer grants the Provider general written authorization to engage sub-processors. The current sub-processors are listed in the Sub-processor list and in Annex 2.

8.2 Advance notice and objection. The Provider will inform the Customer of any intended addition or replacement of a sub-processor at least 30 days in advance, giving the Customer the opportunity to object on reasonable data protection grounds before the change takes effect.

8.3 Flow-down. The Provider imposes on each sub-processor, by contract, data protection obligations equivalent to those in this DPA, and remains fully liable to the Customer for the sub-processor's performance.

8.4 LLM providers are not sub-processors. The Customer's LLM provider is engaged under the Customer's own contract using the Customer's own API key. It is a recipient chosen and contracted by the Customer, not a sub-processor of the Provider. The Provider's egress proxy does not log or persist request or response bodies. See the Sub-processor list.

9. Assistance to the Customer

9.1 Taking into account the nature of the processing, the Provider assists the Customer by appropriate technical and organizational measures, insofar as possible, in fulfilling the Customer's obligation to respond to requests from data subjects exercising their rights under Chapter III GDPR. The Service also provides self-serve capabilities (for example account and data deletion, audit log export) that the Customer can use directly.

9.2 The Provider assists the Customer in ensuring compliance with the obligations under Art. 32 to 36 GDPR (security of processing, breach notification, data protection impact assessment, and prior consultation), taking into account the nature of processing and the information available to the Provider.

10. Personal data breach

10.1 The Provider notifies the Customer of a personal data breach affecting the Customer's data without undue delay after becoming aware of it, and at the latest within 72 hours after becoming aware.

10.2 The notification includes, to the extent 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. The Provider provides further information as it becomes available and cooperates with the Customer's response.

11. Deletion or return at end of processing

11.1 On termination of the processing, the Provider deletes the Customer's personal data, at the Customer's choice deletes or returns it, and deletes existing copies, unless Union or Member State law requires storage.

11.2 In FragonForge, offboarding triggers a documented full tenant purge: database rows, the code search index (database chunks and vector store), stored keys and tokens, and billing links are removed. It is a full deletion, not a soft delete, and is available self-serve from the app.

11.3 The Provider's statutory retention obligations (for example for invoices) are the documented exception and survive until they lapse; such retained data is not further processed.

12. Audit rights

12.1 The Provider makes available to the Customer the information necessary to demonstrate compliance with Art. 28 GDPR and allows for and contributes to audits, including inspections, conducted by the Customer or an auditor mandated by the Customer.

12.2 The parties agree that audits are conducted on reasonable prior notice, during business hours, no more than once per year absent a specific cause (for example a breach), subject to confidentiality, and in a manner that does not disrupt the Provider's operations or the security or data of other customers. The Provider may satisfy audit requests in the first instance by providing its security documentation and answers to a security questionnaire.

13. International transfers

The Provider does not transfer the Customer's personal data outside the EU/EEA in the course of operating the platform itself. The platform runs on infrastructure in the EU (Germany); data at rest stays in the EU. One exception applies to billing: payment processing through Stripe may involve a transfer of billing data to Stripe, Inc. (USA) under the EU-US Data Privacy Framework or standard contractual clauses, as set out in the Sub-processor list. Beyond this, if a transfer outside the EU/EEA ever becomes necessary, the Provider will not carry it out without the Customer's instruction and an appropriate Art. 46 GDPR transfer mechanism.

Transfers arising from the Customer's own choice of LLM provider occur under the Customer's own contract and are the Customer's responsibility as controller (see clause 8.4).

14. Order of precedence and miscellaneous

This DPA is governed by Austrian law, consistent with the Terms. If a provision is invalid, the rest remains in force. Changes require text form.

Annex 1 - Technical and organizational measures (Art. 32)

Derived from the Provider's published security architecture.

Execution and tenant isolation

  • Each run executes in a dedicated Kubernetes job created for that run and destroyed after it.
  • Sandboxes run under a hardened runtime: gVisor on Free and Solo; Kata Containers (per-run lightweight VM with a separate guest kernel) on Team and Business.
  • The sandbox image runs as a non-root user, is pinned by digest, and is vulnerability-scanned in CI before deployment. It ships no credentials.
  • Multi-tenant isolation is enforced in depth: every tenant-scoped row carries a tenant ID with a global query filter; tenant context is fail-closed (no tenant means zero rows); bypassing the filter is a build error enforced by a static analyzer; automated two-tenant leak tests gate the build.

Network isolation

  • A default-deny egress NetworkPolicy blocks all outbound traffic from the sandbox, enforced by a policy-enforcing CNI (Calico).
  • The only permitted destination is the platform gateway, which exposes server-side repository tools and an LLM egress proxy.
  • The sandbox authenticates with an opaque, 256-bit, hash-stored, time- limited per-run token, revoked when the run reaches a terminal state.
  • The LLM proxy allows only configured provider endpoints, guards against SSRF, and strips inbound authentication headers before forwarding.

Credentials and encryption

  • Forge tokens never enter the sandbox; clone, push, and merge-request creation happen on the control plane.
  • The LLM key never enters the sandbox; the proxy attaches it on egress, scoped to the provider fixed when the run token was minted.
  • Each organization has its own data encryption key; LLM keys, forge tokens, webhook secrets, and TOTP seeds are encrypted with it (AES-GCM).
  • Inbound webhooks are verified twice (signed per-tenant URL token plus the forge's payload signature against the tenant's webhook secret, compared in constant time).

Data minimization in logs and telemetry

  • The LLM egress proxy does not log or persist request or response bodies.
  • Run logs store agent output only, secret-redacted, capped at 64 KiB.
  • Telemetry records identifiers, durations, and token counts only, no code or prompts. Emails never contain repository content.

Access control and auditability

  • Role-based access control (Owner, Admin, Member, Viewer), fail-closed.
  • TOTP two-factor authentication with recovery codes; scoped personal access tokens bounded by the holder's live role; session listing and revocation; refresh tokens in HttpOnly cookies.
  • A tenant-scoped audit log records sensitive actions (logins, credential and role changes, run and billing events), with filtering and CSV export.

Data residency, backups, and lifecycle

  • The platform runs on dedicated servers in the EU (Hetzner, Germany); data at rest stays in the EU.
  • Databases have point-in-time-recovery backups to EU object storage with a 30-day retention window.
  • Run history retention follows the plan (30 days to 1 year).
  • Offboarding performs a full tenant purge (see clause 11.2).

Supply chain

  • Dependency audits gate the build (a moderate-or-higher advisory fails compilation); container images are scanned before deployment (critical findings block release).

Annex 2 - Approved sub-processors

See the Sub-processor list. At the date of this DPA the confirmed infrastructure sub-processor is Hetzner Online GmbH (Germany, hosting). Other categories are listed with their status in that document. LLM providers are not sub-processors (clause 8.4).