An Agent Can Only Leak What Its Process Can Decrypt

Every week brings a new demonstration of an agent talked into doing something it should not: reading a file it was never meant to see, summarising a record outside the user's remit, pasting a secret into a tool call. The fixes offered are always the same shape. A stronger system prompt. A classifier on the input. A policy engine in the orchestrator. A permission check in front of the retriever. Each is a piece of software standing between the model and plaintext, and each can be misconfigured, bypassed by an input nobody anticipated, or simply skipped by a cache that outlived its authorisation.

Here is the uncomfortable arithmetic. An agent's effective access is not what its policy says. It is the union of everything its process can decrypt, minus whatever the filters happen to catch. If the store holds plaintext behind a check, the check is the boundary, and the boundary is made of the same material as the attack.

This article is for the engineers and security leads building agentic systems over real data: platform teams, AI security, the people who will be asked after the incident why the agent could read that. It describes the one boundary a prompt cannot negotiate with, and what 8DB has demonstrated about it.

Move the decision below the model

8DB does not decide access with a check in front of plaintext. Labels, clearances and policy epochs are inputs to key derivation.¹ A read whose clearance does not satisfy the record's label does not receive a denial message over plaintext. It fails to derive the key, and what it gets is ciphertext. There is no exception path, because there is no plaintext copy to fall through to.

Think about what that does to an injected instruction. The model can be persuaded to ask for anything. The orchestrator can be tricked into forwarding the request. The retriever can be made to run the query. And the answer comes back sealed, because the process making the request was never given what it takes to open that record. The attack succeeded at every layer that was made of software and failed at the one that is made of mathematics.

What "policy is an input to the key" means in practice

• Labels and clearances are cryptographic facts. A record written under a label can be opened only by a process holding material derived under a satisfying clearance. Change the reader's clearance and you change what derives, not what a filter permits.²
• Policy changes advance an epoch. When a policy is revised, the epoch moves, and material derived under the old epoch no longer opens records written under it. Revocation is a key event, not a configuration edit that has to propagate everywhere before it means anything.
• Data keys are never stored. Each is derived at use from a root secret and the record's governance state at write time. A compromised agent host yields ciphertext and no key table, because there is no key table.³
• It works without a network. The core tested operations run with the network disabled, so the boundary holds in an air-gapped enclave or on an edge node exactly as it does in a data centre.

The claim in our independent evaluation package is stated this way: the engine enforces label and clearance boundaries and policy or epoch changes through key derivation and decryption outcomes, with core operations executable while the evaluator network is disabled. It is accepted only when every named harness passes against a frozen baseline, unauthorised and stale-policy access is rejected in the tested cases, and the run is performed on an isolated host without our source code.

Why this matters more as agents get better

The better the model, the more convincing the injected instruction it can be made to follow, and the more capable the tool chain it can be made to drive. Every defence built from prompts and filters gets weaker as the thing it constrains gets stronger. A boundary built from key derivation does not care how persuasive the request is. That inversion is the reason to put governance in the data layer now, while agent deployments are still small enough to move.

The same property gives you the audit

Because governance state is part of the record, every read an agent performed can be attributed to the clearance and epoch under which it succeeded, and every record carries its provenance. When someone asks what the agent could see and why, the answer is a query over the store, not a reconstruction from logs. The companion piece, Show Your Work: Provenance as a Query, covers that side.

Evidence notes

A cryptographic boundary bounds what an agent can read. It does not make the agent wise about what it has legitimately read: an agent with clearance for a record can still be talked into summarising it to the wrong person, and that is an output-side problem for the orchestrator. We state the limits, in the notes to this article, because a boundary you overestimate is worse than one you understand.

Where to start

• One agent, one policy. Send us the tools an agent can call, the data it reaches and the access model you intend. We will return an acceptance plan that states which reads must fail as ciphertext and how the evaluator harness proves it.
• Your worst injection. The attack you have already seen or fear most. We will show where in the chain it succeeds and where it stops.
• The evaluator bundle. A source-free artifact with frozen baselines is available so your security team can run the governance claim on an isolated host before any integration.

Write to hello@8braid.com with the subject "Agent data boundary: acceptance plan". You will hear back from an engineer.

Sources and further reading

• OWASP Top 10 for Large Language Model Applications ↗
• NIST SP 800-53 Rev. 5: Security and Privacy Controls ↗
• 8DB: Governance That Changes the Ciphertext, Not the Prompt
• 8DB: What an Independent Evaluator Should Be Able to Run

Footnotes

1. On the tested store path, as exercised by the governance claim in our independent evaluation package. ↩

2. A root trust anchor still has to be provisioned and protected, entropy and custody are still the deployment's job, and the package makes no claim to a complete mandatory-access-control certification over every lattice state. ↩

3. A party holding the root and the write-time inputs can decrypt regardless of later policy; that is why re-encryption sweeps exist. ↩

Continue the technical conversation

Where could this help your work?

Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.

Discuss this work