Contextual state continuity: verifying an agent's memory before it acts

What is this?

On July 2, 2026, researchers posted ElephantAgent: Contextual State Continuity in Agentic Systems to arXiv. The paper attacks a problem that most agent defenses skip over: an agent’s behaviour is driven not only by the user’s current query, but by an accumulated contextual state — the tools it has registered, their descriptions, and the memory it has written across earlier turns. If any of that state is quietly tampered with, the agent keeps running as if nothing happened.

Recent work on tool poisoning and memory poisoning has shown the shape of the threat: a maliciously crafted tool descriptor or a poisoned memory entry can bias an agent’s planning and execution long after the injection, with no obvious symptom at the moment of the malicious action. The authors frame this as a deeper, structural gap — there is no verifiable continuity of the security-critical part of an agent’s context. This is a defensive research writeup, not an exploit.

How it works

The proposal defines the contextual state as the bounded, security-critical subset of everything in an agent’s context — principally its tool state and memory, rather than the entire prompt history. The defense then borrows an idea from trusted-computing state-continuity systems and applies it to that evolving state.

Before processing each query, the runtime recomputes a digest of the local contextual state and verifies it against the latest authorized digest. A mismatch means the state changed out of band — it was not the result of an authorized transition — and the agent can refuse to proceed.

  query N arrives
      |
  recompute digest(tool_state + memory)
      |
  compare against latest AUTHORIZED digest  --- mismatch ---> halt / audit
      |  match
  execute, then record the new authorized transition in the ledger

Two mechanisms back this up. A linearizable ledger of authorized state transitions, maintained with replicated trusted hardware, is what lets the system detect out-of-band tampering rather than merely hash the state and hope. And because an attacker can also abuse the state in-band — writing a poisoned memory through a legitimate-looking path — the design adds historical traceability: a conditional, after-the-fact audit trail that supports recovering the agent to a known-good prior state. The specific protocol names, the trusted-hardware assumptions, and the prior state-continuity system it builds on are given in the paper.

Why it matters

Most agent security today watches the wrong moment. Guardrails and output filters inspect the current input and the current action, but tool and memory poisoning are time-shifted attacks: the payload lands on turn 3, the damage surfaces on turn 20, and by then the malicious content looks like the agent’s own trusted context. Integrity of the accumulated state, not just the live message, is the property that has been missing.

Treating tool descriptors and memory as a security-critical state with a verifiable digest reframes the problem in familiar terms — this is integrity protection and tamper-evidence, applied to a surface that agent frameworks currently leave unprotected. It pairs naturally with least-privilege tool scoping: continuity checking tells you the state changed without authorization, while scoping limits what a compromised state can reach. The main cost is the trust assumption — the approach leans on replicated trusted hardware and a ledger, which is a heavier deployment than a prompt-level filter.

Defenses

Treat this as a design pattern to evaluate, not just a paper to read.

Give your agent’s memory and tool registry an integrity boundary. The lesson that generalizes beyond any single implementation: the tools an agent trusts and the memory it reads back are security-critical state, and unauthorized changes to them should be detectable. Even a hash-chained audit log of memory writes and tool-descriptor changes moves you from blind trust toward tamper-evidence.

Separate authorized transitions from ambient writes. Poisoning succeeds because any write to memory is treated as legitimate. Require that state-changing operations go through a controlled path you can log and, ideally, verify, so an out-of-band modification stands out.

Keep an audit trail that supports rollback. Historical traceability is only useful if you can act on it. Retain enough provenance on memory and tool state to identify a poisoned entry and restore a known-good version, rather than discovering the compromise with no way to unwind it.

Do not retire runtime controls. Continuity verification catches out-of-band tampering; it does not by itself judge whether an authorized-but-malicious instruction should run. Keep it alongside input provenance, tool-selection constraints, and runtime authority checks rather than treating any one layer as sufficient.

Status

Item	Detail
Disclosure	Academic preprint, arXiv, July 2, 2026
Class	Defensive protocol against contextual-state (tool/memory) poisoning
Core idea	Recompute and verify a digest of tool state + memory before each query
Mechanisms	Linearizable ledger of authorized transitions; historical traceability for post-hoc audit/recovery
Trust assumption	Replicated trusted hardware maintaining the authorized-state ledger
Caveat	Detects out-of-band tampering; in-band semantic abuse still needs runtime authority controls