Data Processing Agreement

Last updated: August 12, 2026. This Data Processing Agreement ("DPA") is incorporated into and forms part of the Parse for Agents Terms of Service. It applies when Parse processes personal data on behalf of a Customer under Article 28 of the EU General Data Protection Regulation (GDPR) and the UK Data Protection Act 2018.

1. Parties

This DPA is between Kurultai Labs LLC, a North Carolina limited liability company that operates Parse ("Processor" or "Parse"), and the entity that has subscribed to the Parse service ("Customer" or "Controller"). This DPA is governed by the laws of the State of North Carolina, United States.

The North Carolina Secretary of State entity ID is not published on this page. It is provided in writing on request to [email protected], and it appears in full on any counterpart executed with a Customer. See the entity block on the trust page.

2. Processing Activities

Parse processes the following categories of personal data on behalf of the Customer:

• Prompt text and content submitted for security screening and risk analysis
• API keys and metadata — key identifiers, usage counts, rate-limit data
• IP addresses — for rate limiting and abuse prevention (hashed)
• Screening results — risk scores, flags, verdicts returned to the Customer

The purpose of processing is limited to: (a) screening prompts for prompt injection, jailbreak, and adversarial threats; (b) returning risk assessments; (c) logging for security audit; and (d) aggregate analytics for detection improvement.

Model training

Parse does not use Customer content to train, fine-tune or evaluate any model. This is a property of the storage design rather than a promise: the screening endpoints (/v1/parse, /v1/screen-output, /v1/agent/trust/verify) do not retain prompt text or a hash of it, so no corpus of Customer content exists to train on. "Aggregate analytics for detection improvement" in (d) above means verdict counts, category distributions and rule hit rates — numbers, not text.

Two limits on that statement, both stated so the Customer does not have to discover them:

• POST /v1/evaluate is the exception to the no-retention rule. It holds the prompt while the run is in flight, then overwrites its copy with the first 100 characters plus a SHA-256 of the whole prompt, kept in server memory for the 500 most recent runs. Those records are not used for training either, but they are the one place Customer text persists at all. See the per-endpoint storage table.
• What OpenRouter and the model providers behind it do with text sent for semantic analysis is governed by their policies, not this DPA. A Customer who needs that transfer not to happen can pass mode: "pattern-only" per request, or set defaultMode: "pattern-only" for the whole organization, and the text is never sent.

3. Sub-processors

Parse uses the following sub-processors to deliver the service. Only OpenRouter receives prompt text, and only in full mode:

Flow-down of obligations (GDPR Art. 28(4)). Parse imposes on each sub-processor listed above the same data-protection obligations as those binding Parse under this DPA, in substance: engaging sub-processors only with the Customer's general authorisation as set out in this section, ensuring processing is governed by a written contract, applying the security measures of Section 6 in substance, taking the supplementary measures of Section 4 where the sub-processor receives personal data, assisting the Customer (through Parse) with data-subject requests and breach notification within the timescales of Sections 8–9, and deleting or returning personal data at the end of the service. Where a listed sub-processor operates under its own standard terms (OpenRouter, Cloudflare, Stripe), Parse has verified that those terms provide obligations equivalent to this DPA in substance before authorising the engagement, and the equivalent-terms check is repeated before each 30-day activation notice. OpenRouter receives prompt text only in full mode; the Art. 28(3)(b) instruction set for that engagement is limited to semantic risk scoring, with no training use permitted.

Any caller on any tier can keep prompt text away from OpenRouter by passing mode: "pattern-only" per request, which runs Layer 1 only. Organizations can also make this the default for every request by setting defaultMode to pattern-only on their screening policy (PUT /v1/policy), so the control does not have to be repeated per call. Prompt text still reaches Parse in the United States in either case — pattern-only prevents the onward transfer to OpenRouter, not the transfer to Parse. GDPR Art. 28(4) flow-down: Parse imposes the obligations of this DPA on each sub-processor in substance; see the flow-down clause beside the table above. New subprocessors are announced 30 days in advance.

Which model receives prompt text. When the semantic layer runs, OpenRouter routes the request to deepseek/deepseek-v4-flash. OpenRouter can serve a given model from more than one upstream host and Parse does not pin the upstream provider, so the company operating the hardware for a particular request is not fixed — the model is named here because it is the part Parse controls and can state truthfully. What that provider retains or trains on is governed by their policy and OpenRouter's, not by Parse's DPA. Passing mode: "pattern-only", per request or as an organization default, means the semantic layer does not run and no model receives the text at all.

4. International Data Transfers

Personal data may be transferred from the EEA, UK, or Switzerland to the United States under the European Commission's Standard Contractual Clauses (SCCs) adopted under Commission Implementing Decision (EU) 2021/914. Parse executes the SCCs as the data importer.

Transfer Impact Assessment (TIA)

A TIA is available to Customers under NDA. Summary findings:

• Surveillance risk: Parse operates on self-hosted infrastructure (Mac Mini), not AWS/GCP/Azure. No government access beyond what is legally compelled.
• Encryption: Data in transit uses TLS 1.2+ (TLS 1.3 negotiated by default). Prompt text is processed ephemerally and not persisted for the screening endpoints.
• Access controls: Single-tenant infrastructure with no third-party administrative access.
• Supplementary measures: Pattern-only mode prevents onward transfer of prompt text to the semantic-analysis subprocessor (OpenRouter, US) when used. Prompt text is still transferred to Parse for processing in the United States.

5. Data Residency

Processing currently occurs on infrastructure hosted in the United States (Mac Mini M4, behind Cloudflare's edge network). An EU/UK region is on the roadmap. Parse cannot offer EU data residency today: using the hosted API means prompt text is transferred to and processed in the United States, and the transfer is governed by the SCCs in Section 4 rather than avoided. Customers who need to reduce or eliminate that transfer can:

• Pass mode: "pattern-only" per request, which runs the deterministic layer only. Prompt text still reaches Parse in the United States, but is not forwarded to the semantic-analysis subprocessor (OpenRouter, US). This narrows the transfer chain; it does not keep prompt text on the customer's own infrastructure.
• Run the open-source prompt-guard pattern library inside their own environment. This is a standalone component, not the Parse platform: it performs local pattern screening only, without the hosted registry, policy engine, receipts, or semantic layer. Prompt text never leaves the customer's infrastructure in this configuration, because Parse is not in the request path at all.

6. Security Measures

Parse implements the following technical and organizational security measures:

• Encryption in transit: TLS 1.2+ (TLS 1.3 negotiated by default)
• API keys: bcrypt-hashed with salt at rest, plus a non-reversible lookup prefix. The Redis validation cache holds a SHA-256 of the key so the bcrypt comparison does not run on every request. The full key is never written down; it is shown once at generation.
• Sandbox isolation: Execution environments containerized with no network access
• Access controls: Single-operator infrastructure, no shared credentials
• Audit logging: All screening events and admin actions logged
• Retention enforcement: Automated daily purge job (see retention schedule)

7. Data Retention

Retention periods are documented on our Trust page. Screening endpoints do not persist prompt text. Metadata (usage counts, IP hashes) is retained per the schedule and purged automatically.

8. Data Subject Rights

Parse assists Customers in responding to data subject requests as required by GDPR Articles 15-22:

• Access (Art. 15): Customers can export their screening policies and configuration data
• Erasure (Art. 17): Customers can request deletion of their account and associated data
• Portability (Art. 20): Configuration data is exportable at any time
• Objection (Art. 21): Customers can disable any processing tier at will

To exercise these rights, Customers contact [email protected]. Parse responds within 30 days.

9. Breach Notification

Parse will notify the Customer of any personal data breach without undue delay and in any case within 72 hours of becoming aware of the breach, in accordance with GDPR Article 33. Notification includes:

• The nature of the breach and categories of data affected
• The likely consequences and measures taken
• Contact details: [email protected]

10. Audit Rights

Customers have the right to audit Parse's compliance with this DPA, subject to:

• 30 days' written notice
• Mutually agreed scope and timing
• Confidentiality and non-interference obligations

SOC 2 Type II certification is planned for Q1 2027. Until then, the trust page and trust package serve as the primary security attestation.

11. Data Protection Officer

For data protection inquiries, contact:

• Email: [email protected]
• Privacy: [email protected]

12. Changes to This DPA

Parse will notify Customers of material changes to this DPA at least 30 days in advance. Sub-processor additions are announced 30 days before activation.