Compliance
Start here — what you actually have to do
Section titled “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 or the audit trail, 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. |
| Who may reach it | The installer writes a starting policy that admits you, the owner, and refuses everything else. Each further policy rule admits a person or an agent by name. An agent with no rules at all enforces nothing, so never run one without them. |
| How long data is kept | The agent deletes nothing on its own: conversations, memories and the audit trail stay until you remove them. The one exception is sessions held for outside callers, which are kept for 365 days by default (external.retentionDays, 1 to 365). Deciding how long to keep the rest, and deleting it, is yours. |
And three things remain yours no matter what:
- Conversations and work files on disk. Settings, policy, sessions, approvals and consent records are sealed. Conversations, memories and work folders are ordinary files on the agent’s machine, so protect that disk; an encrypted disk covers them. If you bring your own engine, whatever it writes is yours too.
- Your own application’s logs.
- The host the agent runs on. These guarantees assume it is intact.
What you can show an auditor
Section titled “What you can show an auditor”- The audit trail. A sealed, chained record of sign-ins, turns, approvals, commands, agent-to-agent calls and changes to settings, without the content of any message. You can export it, verify it and send it to your SIEM.
- The compliance report. The controls in force, read from what the running agent recorded, checked line by line against SOC 2, HIPAA, the EU AI Act and India’s DPDP Act.
- The access review. Who may sign in, every policy rule, every signed-in session, every standing approval.
- Consent records. Each person’s acceptance of the workspace terms, with the exact words and their hash, and any withdrawal.
- The admin settings. Idle sign-out, the privacy notice and the AI notice, which you can lock against change.
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.
What it looks like
Section titled “What it looks like”Real screens and real output. Private values are blurred, not removed.
Consent. Each person accepts the terms before using the workspace. The acceptance is kept, sealed, with the exact words and their hash.
The AI notice. Under every message box, people are told they are working with an AI system.
Every step shown. The Advanced view lists each step the agent took and the sources it used.
Nothing runs unasked. A drafted job does nothing until a person presses Start.
Secrets stay sealed. An API key is sent encrypted and never shown again.
The record. One conversation in the audit trail: who, when, which engine and model, and the question and the reply only as hashes.
The report. The compliance report checks the controls in force against each framework, line by line.
The shift this makes
Section titled “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
Section titled “Breach safe harbour”Anything that carries messages between two agents, whether a tunnel, a gateway or the network, holds only 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.
Consent as an artifact, not a log row
Section titled “Consent as an artifact, not a log row”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. No setting lets anything between two agents read their messages. |
| Art. 5(1)(c) — data minimisation | A mission searches only the memories it lists. A memory served by another agent answers questions without its documents leaving that agent. The audit trail keeps a hash of each message, never its content. |
| 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 between identities. At rest, settings, policy, sessions, approvals, consent records and the audit trail are sealed. Conversations and memories are ordinary files, so encrypt the disk they sit on. |
| Art. 7(1) — demonstrable consent | See above. Each person’s acceptance of the workspace terms is also kept, sealed, with the exact words and their hash. |
| Art. 7(3) — withdrawal of consent | Privacy, at the bottom of the workspace, as easy as accepting. Recorded in the audit trail. Offered by default on a business licence; see Admin settings. |
| Art. 22 — solely automated decisions | Where approval is required, a decision is not based solely on automated processing. The agent enforces it rather than leaving it to procedure: a command that is not already allowed waits for a person. |
| 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 the audit trail and the compliance reports give you the raw material, and the properties above are what a DPIA can rely on. |
| §164.312(a)(2)(iv), (e)(2)(ii) — encryption at rest and in transit | In transit: end to end. At rest: the agent’s stores and the audit trail are sealed; conversations and memories need an encrypted disk. |
| §164.312(a)(2)(iii) — automatic logoff | The workspace signs people out when idle: after 15 minutes by default on a business licence. |
| 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 | A mission searches only the memories it lists. |
| §164.312(b) — audit controls | A sealed, chained audit trail of sign-ins, turns, approvals, commands and agent-to-agent calls, which you can export, verify and send to your SIEM. |
| §164.308(a)(4) — access management | Per-identity policy. The starting policy admits only the owner; everyone else needs a rule. The access review lists who has access. |
India DPDPA 2023
Section titled “India DPDPA 2023”| Section | Fit |
|---|---|
| §5 — notice | The terms screen shows a privacy notice before anyone accepts: the standard one, or your organisation’s own. |
| §6(1) — free, specific, informed, unambiguous, by clear affirmative action | Approval is an affirmative cryptographic act. Each acceptance of the terms is kept with the exact words and their hash. |
| §6(4) — withdrawal as easy as giving | A person withdraws in the workspace (Privacy) as easily as they accepted. The workspace then shows only the terms until they accept again, and the withdrawal is recorded in the audit trail. |
| §8(5) — reasonable security safeguards | Encryption end to end; the agent’s stores and the audit trail sealed 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
Section titled “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. A mission’s memories bound what it can draw into a model’s context.
- Art. 12 — record-keeping. The audit trail records each turn, approval and command automatically.
- Art. 50 — transparency. The workspace tells people they are working with an AI system and labels exported conversations as AI-generated.
- Practical effect on prompt injection: a compromised model can ask for anything, but it reaches only what policy allows, and a command that is not already allowed waits for a person.
Deployment choices that change the analysis
Section titled “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
Section titled “What this does NOT do”Three different kinds of limitation. Only the third is future work.
Inherent — permanent trade-offs, disclosed
Section titled “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. The identity files are hidden from it and it runs in a sandbox. A command that is not already allowed waits for a person’s approval, and every call it makes to another agent must pass both agents’ policy rules.
The residual risk is that a hostile engine can influence what a person approves. Showing the exact command in each approval reduces this, but does 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
Section titled “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 rules. An agent with no rules at all enforces nothing; the installer’s starting policy admits only the owner. Every rule you add admits someone, so review them; the access review lists them all.
Open — being worked on
Section titled “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
Section titled “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
Section titled “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.
The compliance report checks the agent’s controls against the SOC 2 criteria, line by line, as evidence for your own audit.
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.
- Audit trail — what is recorded, and how to export and verify it
- Compliance reports — the controls in force, and who has access
- Admin settings — idle sign-out, privacy notice, consent
- Dead Drop Encryption — the key exchange underneath these properties
- Policy and approved builds — access control in practice
- HexaEight and OAuth — how the two work side by side