Make Prompt Injection Harmless to Your Data: Clearance Lives in the Key, So a Hijacked Agent Decrypts Nothing It Was Not Cleared For

Every agentic system deployed against high-consequence data has the same two questions hanging over it. Can the agent reach data it should not? And when it recommends something, can a human find out why? Most platforms answer the first with a permission layer between the model and the plaintext, and the second with logs. Both answers are made of software that sits beside the data and can be misconfigured, bypassed or lost. Neither survives the conditions the tactical edge imposes: disconnected nodes, no reach-back to an identity or key service, and adversaries who capture hardware.

This article is for the people building and evaluating agentic intelligence and sensemaking platforms for defence and government missions: platform architects, AI assurance leads, security engineers and the integrators who assemble models, agents and orchestration into a fielded system. It describes what a data substrate has to do so that governance and attribution are properties of the data rather than promises of the application, and it states what 8DB has demonstrated to an independent evaluator against that requirement.¹

The substrate decides what the agent can know

An agent does not have clearance. It has access to whatever its process can decrypt. If the store holds plaintext behind a permission check, then the agent's effective clearance is the union of every bug in that check, every prompt injection that talks the orchestrator into a wider query, and every cache that outlives its authorisation. Prompt-level guardrails do not change what the process can read.

8DB puts the decision one layer down. Labels, clearances and policy epochs are inputs to key derivation on the tested store path. A read under a clearance that does not satisfy the label does not return a denied message over plaintext; it fails to derive the key, and the bytes stay sealed. A policy change advances the epoch, and material derived under the old epoch no longer opens what was written under it. An agent constrained this way is constrained by cryptography, not by the quality of its instructions.

This is the tested claim in our evaluation package, stated in the evaluator's terms: the engine enforces label and clearance boundaries and policy or epoch changes through key derivation and decryption outcomes, and it does so with core operations executable while the network is disabled. It is accepted only if every named harness passes and matches its frozen baseline, unauthorised and stale-policy access is rejected in the tested cases, and the evaluator runs the whole thing on an isolated host.²

Why an analyst can trust an agent's answer

The second question, why did the agent conclude this, is a provenance question, and provenance stored as a log is a reconstruction. 8DB carries it per datum. Every record is content-addressed and attributable to its source, and a dataset is authenticated with one ML-DSA-87 signature over a SHA-384 Merkle root with a logarithmic inclusion proof per record. A reviewer can be handed one record, its proof and the signed root and verify that this datum was part of that authenticated dataset, without access to the rest of it and without trusting the operator. Tampered leaves and forged roots are rejected through an independent verifier path.

For a sensemaking platform, that means an AI recommendation can be traced to the specific data it rested on, and each of those inputs can be shown to be authentic and unaltered. What the substrate guarantees is that the inputs to the model's reasoning are attributable, and that the guarantee is checkable by someone who does not run the system.³

Fusion without siloed governance

Sensemaking at the edge fuses telemetry, geospatial data, imagery, relationships and time series from many sources. In most stacks each of those lives in its own engine with its own access model, so the agent's effective governance is the weakest of five. In 8DB, key-value, relational, document, blob, spatial, time-warped and graph and hypergraph data live in one sealed store under one protection path, so the picture the agent reasons over is fused and its governance is single.⁴

It keeps working when the link does not

Disconnected, intermittent and low-bandwidth operation is the normal condition, not the failure mode. The engine is embeddable and runs in process, the core tested operations need no external service, and key material is derived on demand rather than fetched, so cognition continues at the node when reach-back is gone. When connectivity returns, already-sealed intelligence moves between nodes through a post-quantum authenticated sealed-transfer primitive that uses ML-KEM-1024 and ML-DSA-87 operations and rejects tamper, wrong-key, man-in-the-middle and replay cases in the tested harness, without exposing application plaintext.⁵

Where to start

The right first conversation is about one workflow and one policy.

• One agent workflow. The sources it reasons over, the decisions it supports, and who is entitled to see what. We will return an acceptance plan that names the governance, provenance and offline behaviours as testable claims with the harnesses that back them.
• Your access-control model. Labels, clearances and epochs as you define them. The evaluator harness exercises multi-level cases; yours can be added.
• The evaluator bundle. A source-free artifact with frozen baselines is available so your assurance team can run the claims on an isolated host before any integration begins. See what an independent evaluator should be able to run.

Write to hello@8braid.com with the subject "Governed substrate for agentic sensemaking". You will hear back from an engineer.

Sources and further reading

• NIST SP 800-53 Rev. 5: Security and Privacy Controls ↗
• NIST FIPS 203: ML-KEM ↗ and FIPS 204: ML-DSA ↗
• NSA CNSA 2.0 Cybersecurity Advisory ↗
• 8DB: What an Independent Evaluator Should Be Able to Run
• 8DB: Category 5 Protection for Stored Data Where There Is No HSM and No Key Service

Footnotes

1. The boundary of the claim: 8DB is the protected data and memory substrate. It is not the model, the agent or the reasoning engine, and nothing we publish speaks to model accuracy, agent behaviour, autonomy or the quality of any sensemaking output. The cryptographic evidence behind the algorithms is a NIST demonstration-server result and an offline known-answer suite, which is corroborating evidence and not a CAVP certificate or CMVP module validation. A packaged, CI-gated build for rugged ARM64 edge hardware is a planned deliverable, and we describe it that way. ↩

2. The non-claims travel with the tested claim: this is not a complete mandatory-access-control certification over every lattice state, it does not make a root secret or a custody process unnecessary, and it does not by itself satisfy a control; it contributes implementation evidence. ↩

3. The model's reasoning is the integrator's responsibility. A substrate cannot vouch for it; it can only make the inputs attributable. ↩

4. The tested claim is bounded to the shapes the evaluator harness covers, those listed here. Vector, point-cloud, time-series and hypergraph support exists but is not claimed to carry uniform protected treatment until evaluator-visible tests say so. ↩

5. The claim is limited to the primitive. It is not a validation of any production transport, mesh, radio or DDIL implementation, and the evaluation package says so. ↩

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