Agent Memory Is a Security Boundary — not just a data store
An agent's memory is where untrusted input becomes trusted, persistent fact. That makes it a security boundary — the place where a single poisoned write can corrupt every future decision. Most teams treat memory as a database. It's actually the most security-critical component in the whole stack.
Memory is a store of claims, not a store of authority. Recalling a fact does not grant that fact permission to drive an action. Agent memory security means enforcing that separation at the write and read boundaries.
Why memory is a security boundary
Unlike a prompt, which lasts one turn, memory persists. A poisoned memory entry is a persistent injection that re-fires on every future retrieval. It doesn't need a lucky single read — it just needs to be written once, then it works against the agent forever.
- Persistence amplifies harm. One bad write = weeks of corrupted decisions.
- Derivation compounds it. A poisoned root spawns poisoned descendants, spreading through the whole graph.
- Credentials land here. API keys and tokens that reach memory become a standing exfiltration target.
The memory attack surface
How AgentInterdict secures memory
- Origin-bound writes. A memory's authority is bound to its source. Instruction-shaped content from an unverified origin is quarantined, not persisted.
- Credentials-not-memory. Private keys, API tokens, JWTs and credential assignments are rejected or redacted before persistence — secrets never live in memory in usable form.
- Atomic derivation containment. A quarantined root and all its descendants are contained together, so the corruption doesn't spread.
- Retrieval ≠ permission. Recalling a memory never, by itself, authorises acting on it — the action is re-scored at execution time.
- Fail-closed tampering. Direct database tampering is detected and the runtime flips to
lockdown.