The first generation of agents forgot everything at the end of the conversation, and that was a limitation. The second generation remembers, and that is a liability nobody has priced. An agent that keeps memory across sessions accumulates a record of what it read, what it was told, what it concluded and who it was working for. Every one of those memories is a fact about a person, a contract or a system, with an origin, a confidence and an audience. Most agent memory implementations store it as an embedding and a blob of text in a vector index, retrievable by anything that can compute a similar vector.
Ask three questions of that design. Who is allowed to recall this memory? Where did it come from, and how sure should the agent be of it? When the person it concerns asks for it to be gone, is it gone, and can anyone prove that? A vector index answers none of them, and enterprises are about to discover that their most capable systems hold their least governed data.
This article is for the people building agent platforms and the security and privacy teams who will inherit their memory stores: what a memory has to carry, what recall has to respect, what forgetting has to mean, and what 8DB does for each today.
A memory is a record with an origin
In 8DB a memory is not an embedding with a caption. It is a record that carries its provenance chain, the source it was derived from, the governance state under which it was formed, and a multi-axis confidence vector: sourced or inferred, how many independent observations support it, how recent it is, how reliable its method was.1 An agent recalling a memory recalls its pedigree with it. A memory formed from a single unverified message and a memory confirmed by three authoritative systems are different objects, and the agent can be built to treat them differently, which is the difference between an agent that learns and one that is gullible in perpetuity.
Because 8DB holds relational, document, vector and graph data in one store, the embedding used for recall, the text it summarises, the entity it concerns and the relationships it implies are one record under one protection path, not four systems with four access models.
Recall is bounded by cryptography, not by a prompt
The most important property of agent memory is who can recall it. In 8DB, labels, clearances and policy epochs are inputs to key derivation, so a memory written under one user's context does not decrypt for a process acting for another. There is no filter in front of the vector index to misconfigure; recall outside policy yields ciphertext. Revoke a user, advance the epoch, and the memories formed under their authority stop deriving for anyone who does not hold the new material. This is the tested claim in our independent evaluation package, and it holds with the network disabled, which matters for agents running at the edge or inside an enclave.
Forgetting has to be provable
"We deleted it" is the weakest sentence in privacy engineering, and it is the sentence agent platforms will be asked to defend. 8DB treats erasure as a structural operation that emits a certificate binding the hash of the erased content and its position, verifiable by a third party without the content.2 Where a later memory was derived from the one to be erased, the engine refuses to certify a clean removal and tombstones with the dependency preserved. We describe that boundary in full in Erasure and Immutability Are Not Enemies. For agent memory it has a useful consequence: the store can tell you which memories have become load-bearing for later conclusions, which is exactly the information a privacy review needs.
Memory that survives disconnection
Agents at the edge, in vehicles, in field kits and in air-gapped enclaves cannot call a memory service. 8DB is embeddable and runs in process, its core operations need no external key or identity service, and crash and power-loss recovery over committed sealed data is a tested claim. Sealed memories can move between nodes through a post-quantum authenticated transfer primitive without being decrypted to travel. The agent keeps its memory where it works.
Evidence notes
Nothing here governs what an agent does with a memory it legitimately recalls; output-side controls remain the orchestrator's job, and no store can make an agent's reasoning correct. What a governed memory does is make the agent's inputs attributable, its recall bounded, and its forgetting checkable: the three properties an enterprise will be asked about first.
What to bring us
- Your agent's memory schema. What it stores, for whom, and for how long. We will return an acceptance plan naming which memories must fail to recall for which processes, and how the evaluator harness proves it.
- One erasure request you could not fulfil cleanly. We will show where it hits the isolation boundary and what that says about the memory design.
- Your privacy reviewer. The evaluator bundle and public verifier exist so they can check the recall and erasure behaviour before the platform ships.
Write to hello@8braid.com with the subject "Governed agent memory: acceptance plan". You will hear back from an engineer.
Sources and further reading
- OWASP Top 10 for Large Language Model Applications
- GDPR Article 17: Right to erasure
- 8DB: An Agent Can Only Leak What Its Process Can Decrypt
- 8DB: The Database Is Part of the Model
Footnotes
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