Your support agent needs a customer's order history. It also has a search tool connected to internal documents. A message arrives saying the refund can only be processed after the agent retrieves an unrelated payroll file.
The useful security question is concrete: can that request obtain the payroll bytes?
8DB gives teams a protected data path they can test below the model. In the inspected clearance-boundary test, the matching cryptographic context recovers the original record; the mismatched context fails to decrypt it. That makes a data-access requirement observable independently of whether the model follows a malicious instruction.
For a security lead moving an agent into production, this is a practical advantage: define the records the agent needs, keep other records outside its decryption authority, and exercise both outcomes through the integration you intend to deploy.
Turn an access policy into a test
Start with a small, representative fixture. Give the agent a permitted order record and place a payroll record outside its assigned access context. Try the ordinary support request, then a request designed to cross that boundary.
The successful result has two parts. The agent can retrieve the order information needed to help the customer. The payroll request receives no usable plaintext through the protected path. A refusal is useful only if the legitimate task still works.
8DB's clearance test provides a specific foundation for this exercise: changing the tested clearance input changes the derived key, and authenticated decryption fails under the mismatched context. The application's trusted services must issue those contexts correctly and protect the root material. The test does not establish every possible clearance relationship or certify an entire deployment.
8DB · Define the acceptance boundary
Four requests. Four things to verify.
Illustrative support agent: useful access, protected records and controlled delivery.
Return the information needed for the support task.
Protected read + assigned contextReturn no usable plaintext through the protected path.
Cryptographic context + key custodyApply the new authority and inspect retained copies.
Authorization + cache lifecyclePrevent delivery outside the permitted recipient set.
Application output controlsKeep each control responsible for its job
The data boundary works alongside tool permissions and output controls. OWASP recommends limiting agent functionality and permissions, using the end user's security context, and enforcing authorization in downstream systems. Those controls help prevent an agent from reaching beyond its task even when its instructions are manipulated. OWASP: Excessive Agency
Apply that separation to the support example. The store controls protected retrieval. The tool layer controls whether the agent may issue a refund. The delivery layer controls who receives the reply. Reading an order legitimately does not authorize sending it to an arbitrary address.
Keep root secrets and privileged context issuance outside the agent's reach. An agent host that has those secrets has a different security boundary from one that can only request narrowly authorized reads. The deployment should make that distinction explicit.
Test the day after access changes
An agent can remain active while a customer relationship, employee role or policy changes. Include that transition in the acceptance plan.
8DB's evaluation material includes stale-authority and unknown-policy refusal cases. For your integration, exercise a previously allowed read after authority changes, then inspect caches, exported data and retained credentials. Previously disclosed plaintext needs its own lifecycle controls; updating policy cannot make an external copy disappear.
This gives the policy change a testable finish line: the next protected read follows current authority, and the application handles information it already received according to its retention rules. The agent-memory article covers that lifecycle in more detail.
Put the boundary on your acceptance plan
The protected store is one part of the system you are evaluating. Run the allowed request, the forbidden request, the changed-authority request and the wrong-recipient request through your real tool path. Preserve the request identity, observed outcome and configuration with each result.
That is how a cryptographic mechanism becomes useful assurance: a reviewer can see what it protects, while the application retains the access it needs to do its job. Our evaluation guide explains the evidence to request; a bundle being available is separate from a completed independent assessment.
Send hello@8braid.com one allowed read and one read your agent must never receive. We can use that pair to scope an 8DB data-boundary evaluation around your application.
Evidence scope Implementation-reviewed · Scoped evaluation paths · Conceptual visual. Explore the evidence.