Compliance

Start here — what you actually have to do

If you are a developer: mostly nothing. The properties below are how the system behaves by default. You do not switch on encryption, and there is no compliance mode to enable.

What you do control is four choices, each of which changes your obligations:

Choice	Effect
Where you run the agent	It runs on your infrastructure, so that is where personal data sits. This is your residency answer.
Which model the router points at	Point it at an on-box model and no personal data reaches a third party — the sub-processor question disappears. Point it at a hosted provider and that provider becomes a sub-processor you must disclose.
Whether you write policy	Deny-by-default applies once rules exist. An unconfigured deployment is permissive, deliberately, so upgrades never lock an operator out of their own agent. Writing the first rule is how you opt in.
Session retention	Two different stores, and only one of them expires. External session transcripts are kept 365 days by default and pruned by the agent; set `retentionDays` in the config’s `external` block to anything from 1 to 365. The harness session trails (`<harness root>/projects/<workdir>/<session>.jsonl`) are never pruned — nothing expires them, so deciding how long to keep them, and deleting them, is yours.

And three things remain yours no matter what:

Whatever your engine writes to disk. An engine is your code. If it caches, logs or exports anything, none of the properties on this page apply to it.
Your own application’s logs.
The host the agent runs on. These guarantees assume it is intact.

If you are filling in a security questionnaire or DPIA, the sections below are written to be cited: each row names the specific obligation it speaks to. Read What this does NOT do before you answer anything — several questions are best answered by the limitations rather than the properties.

The shift this makes

Most privacy regulation asks you to promise things and keep records showing you tried. Several of those promises become properties you can demonstrate mechanically — the difference between “our policy says staff don’t read customer messages” and “the software cannot read them.”

Two properties carry most of the weight.

Breach safe harbour

A relay agent holds ciphertext it cannot decrypt. Under GDPR Art. 34(3)(a), notification to data subjects is not required where measures such as encryption render the data unintelligible to unauthorised persons. HIPAA works the same way: PHI secured to NIST standards is not unsecured PHI, so its exposure is not a reportable breach.

This is the single largest practical benefit, and it applies to the party most likely to be breached — the one in the middle.

Approval is a cryptographic operation only the user can perform. GDPR Art. 7(1) requires the controller to be able to demonstrate consent; DPDPA §6(1) requires clear affirmative action.

A checkbox produces a database row that anyone with database access could have written. This produces an artifact that only the data subject could have produced.

Obligation	What the architecture provides
Art. 25 — protection by design and by default	The sealed path is the only path. There is no configuration in which a relay reads content.
Art. 5(1)(c) — data minimisation	Cross-agent requests are typed, per-destination schemas. A booking request carries dates and preferences — never the calendar or the conversation.
Art. 4(5), 32(1)(a) — pseudonymisation	An engine receives a hash of the identity, never the address. It can distinguish, meter and tier customers without holding personal data.
Art. 32(1)(a) — encryption	End to end, and at rest with no plaintext store.
Art. 7(1) — demonstrable consent	See above.
Art. 22 — solely automated decisions	Where approval is required, a decision is not based solely on automated processing. Human intervention is enforced cryptographically rather than procedurally.
Art. 34(3)(a) — breach notification	See above.
Chapter V — international transfers	EDPB Recommendations 01/2020 name encryption with keys held solely by the exporter or data subject as an effective supplementary measure. Data crossing a border is sealed, with no key at the transit party.
Art. 30, 35 — records and DPIAs	Remain yours — but session records give you the raw material, and the properties above are what a DPIA can rely on.

HIPAA


§164.312(a)(2)(iv), (e)(2)(ii) — encryption at rest and in transit	Both addressed.
Breach Safe Harbor (45 CFR §164.402 and HHS guidance)	Secured PHI is not unsecured PHI. A breach of ciphertext held without keys is not reportable.
§164.502(b) — minimum necessary	Schema-bounded requests.
§164.312(b) — audit controls	Requests, approvals and releases are ordered, addressable records.
§164.308(a)(4) — access management	Per-identity policy, deny by default once configured.

India DPDPA 2023

Section	Fit
§6(1) — free, specific, informed, unambiguous, by clear affirmative action	Approval is an affirmative cryptographic act.
§6(4) — withdrawal as easy as giving	Declining to unseal is withdrawal. There is no endpoint to call and nothing to revoke.
§8(5) — reasonable security safeguards	Encryption end to end; nothing plaintext at rest.
§8(2) — responsibility for processors	A processor that cannot read content is a smaller surface to stand behind.
§2(g), §6(9) — Consent Manager	The user-side consent model maps closely to this role. India is the only major regime that names it explicitly.

EU AI Act

Relevant because engines are models.

Art. 14 — human oversight. Where approval is required, an agent cannot act without the person. Oversight is enforced, not documented.
Art. 10 — data governance. Typed requests bound what enters a model’s context.
Practical effect on prompt injection: a compromised model can ask for anything and still cannot send it.

Deployment choices that change the analysis

Run a local model and no personal data reaches a third party. Model choice lives in the router, per engine. Point it at an on-box model and the sub-processor question disappears entirely — the strongest available answer for health data and Art. 9 special categories.

Sub-processor disclosure becomes a config file. Because model routing is explicit and per-engine, you can enumerate exactly which providers see what, rather than investigating it.

Data stays where you put it. The agent runs on your infrastructure. Personal data does not leave your control by default, which answers residency and sovereignty questions without a contractual clause.

What this does NOT do

Three different kinds of limitation. Only the third is future work.

Inherent — permanent trade-offs, disclosed

Metadata is not hidden. Who contacted whom, when, and how often is visible to the agents involved. Content is sealed; the communication graph is not. Under GDPR, that metadata is still personal data.

Your own agent reads your own session. Sealing applies to content arriving from other parties. Your agent processes your own conversation in the clear, because it must.

The engine reads session content in plaintext — it must, to be useful. You cannot reason over data without seeing it; homomorphic encryption and trusted enclaves are not practical answers here, and enclaves relocate trust rather than removing it.

What the architecture does instead is assume the engine may be hostile and bound what it can do: it holds no credentials, cannot reach the network beyond loopback, cannot select its own capability, and cannot send anything without an approval only the user can produce.

The residual risk is that a hostile engine can influence what the user approves. Typed, schema-bounded requests reduce this — the user reviews fields, not prose — but do not eliminate it.

Access and portability get harder, not easier. Where only the user can decrypt, a controller may be unable to produce data in response to an Art. 15 or Art. 20 request. Encryption you do not hold keys to cuts both ways.

Key loss is data loss. There is no recovery path. That is a design decision with a compliance consequence.

Rotation is the agent’s choice, not forced. Key material is derived per generation window, so keys obtained at different times differ. Keys already held can be reused — including straight through a platform outage — and nothing evicts a key a session is already using.

This is a current limitation rather than a design position: periodic re-keying during a live session is anticipated, but it is not implemented and its operational effects are not yet established. If your control framework requires enforced rotation of keys in active use, treat this as not available today.

Bounded — true, and the scope is the answer

A local session is as trusted as the machine it runs on. An agent on a compromised host offers nothing. The isolation properties assume the host is intact.

Policy is only as good as its configuration. Deny-by-default applies once rules exist. An unconfigured deployment is permissive by design, so that upgrades do not lock operators out.

Open — being worked on

Terminating a session at another party. A user should be able to end a conversation they started at a remote agent, and receive acknowledgement. The proof mechanism for this exists and is used elsewhere in the system; extending it to cross-agent sessions is in progress. Until it ships, treat Art. 17 erasure across agents as an operator process rather than an automated one.

Identifiers in operational logs. Most log output truncates identities. A small number of paths still emit full addresses to stdout, which is personal data with no stated retention (Art. 5(1)(e)). Being addressed.

What remains yours

No architecture discharges these:

lawful basis, and records of processing (Art. 30)
data protection impact assessments (Art. 35) — likely required for agentic processing
processor agreements and BAAs
breach detection and the 72-hour notification clock
retention schedules, and honouring data subject requests
securing the host the agent runs on

On SOC 2 and ISO 27001

Those certify an organisation operating a service. Self-hosted software is not in scope for either. Your own deployment may be certified, and these properties support that — but the software itself is not, and no vendor can hand you one for something you run yourself.

Mapped against GDPR (EU 2016/679), the HIPAA Security and Breach Notification Rules as amended, India’s DPDPA 2023, and the EU AI Act as adopted. Reviewed August 2026. Regulations change; verify against current text.

Why not OAuth — the technical reason the data path is built this way
Dead Drop Encryption — the key exchange underneath these properties
Policy and approved builds — access control in practice