An assistant is reviewing a supplier contract. Buried in an attachment is an instruction to fetch the company's payroll records and include them in its response.
The security decision should already be settled before the model reads that sentence. Contract review does not require payroll access.
8DB, our omnimodal database, brings a cryptographic boundary to that decision. On its protected-read path, governance context participates in deriving the key that opens a record. A request made with the wrong context fails to decrypt. The model's interpretation of an attachment cannot supply the missing key.
For teams deploying agents over sensitive information, that is a useful division of responsibility: let the model work on the task while the data layer enforces the boundary around its inputs.
Put the boundary before plaintext
Application permissions and cryptography do different jobs. A permission check decides whether an operation is allowed. Encryption determines whether the protected bytes can be opened with the material the caller possesses. A well-designed deployment uses both.
8DB's protected path incorporates governance context into key derivation. Its clearance-boundary harness checks a concrete contract: the writer's context must recover the original bytes, while the different reader context must derive different key material and fail to decrypt. The public evaluation note names that check, the inspected source revision and the separate historical authority-refusal evidence.
The deployment must keep authority to issue those contexts, and the root secrets behind them, outside the agent's control. Giving an agent unrestricted key custody would defeat the intended separation. With that boundary in place, broadening a query does not by itself broaden decryption authority.
The diagram shows this particular boundary. It is an architectural illustration, not a claim that every possible agent attack has been tested.
8DB · Architecture in practice
Set the data boundary before the agent reads
Illustrative contract-review assistant. Trusted services control access contexts and key custody.
- 01 · TaskReview a contract
The agent requests information through its assigned access context.
- 02 · Protected readEnforce the boundary
The store attempts to open the record with the supplied cryptographic context.
- 03 · OutcomeContent or refusal
The tested matching context opens the bytes. A mismatched context fails to decrypt.
Tool permissions and output controls govern what the agent does next.
A broader request does not supply the missing decryption authority.
Keep useful guardrails around the agent
OWASP's prompt-injection guidance recommends least privilege and controls implemented outside the language model. 8DB's protected reads give that approach a concrete data-layer mechanism.
An agent still needs safeguards for the information it is authorized to see: narrow tool permissions, appropriate output handling and approval for consequential actions. Together, those controls address two different situations. Cryptographic access boundaries protect data outside the agent's permitted context; application controls govern what it does with data inside it.
This distinction helps a buyer ask a better question than whether an agent is "safe." Which records can this identity decrypt, through which path, and what actions can it take with the result?
Make policy changes observable
Access also has a lifecycle. A contractor leaves, a case closes or an authorization expires. Testing only the initial read misses the moment when the boundary matters most.
8DB's evaluator work includes stale-authority and unknown-policy refusal cases. The useful acceptance criterion is observable: the protected operation must refuse the disallowed access under the declared current policy. Changing an epoch label alone does not remove plaintext already released or keys retained elsewhere. Key custody, recovery and caches therefore belong in the same deployment review.
That gives a security team something specific to test on its own system, including after a restart or restored image. Our stored-data security overview explains the wider boundary; the four illusions of post-quantum database security examines why algorithms, keys and lifecycle controls must be evaluated together.
Evaluate the boundary your agent actually uses
Start with one permitted document and one restricted document. Run the permitted read through the real agent integration and verify the recovered content. Then repeat the restricted read through that same path, including a request induced by an untrusted attachment.
Next change the relevant authority, restart the service and repeat the operation. Inspect any alternate retrieval route or cache that could deliver plaintext. The result should show where access was enforced and which conditions caused refusal.
The useful starting point is an implemented boundary with an explicit acceptance check. Run that check through your own integration, where key custody, alternate retrieval routes and output handling meet. The public note separates source inspection from retained execution results so your team can request or reproduce the right evidence.
The practical benefit is a smaller data-exposure surface for useful agents. Teams can give an assistant the records it needs while keeping the authority over unrelated protected records elsewhere.
Use the three-step boundary check: permitted read, restricted read, then an access change and restart. If you want help applying it, tell us one record type your assistant should never open. A record type is enough; keep the actual records private.
Evidence scope Protected-read mechanisms · Boundary acceptance checks · Evaluation guidance. Explore the evidence.