Defending Agent State: A Cross-Surface Control Model for Prevention, Containment, and Recovery

Defending agent state means treating context, durable memory, goals and instructions, plans and artifacts, tool and environment state, and shared or multi-agent state as objects with their own lifecycle, provenance, and blast radius, rather than as a side effect of a single request that ends when the response is sent. This page is the Defenses pillar's cross-surface entry. It does not repeat the surface-specific defense tables already published for compromised summaries, persistent memory injection, instruction file poisoning, MCP tool poisoning, slopsquatting, and shared state poisoning. Instead, it names the control patterns those tables all draw from, and the sequencing decisions that determine whether a control actually interrupts an attack or only documents one after the fact.

What it is

The defining object is a control model: a small set of interventions, applied at specific points in a state object's lifecycle, that either stop an untrusted write from becoming trusted state, limit what that state can do once it exists, or undo its effects after discovery. The defining property that separates this pillar from Detection is action rather than observation. A detection signal tells a defender that state changed through a path it should not have. A control in this pillar is what a defender does with that signal, or does in advance so the write never lands with unwarranted trust in the first place.

The defining consequence of applying these controls correctly is a smaller blast radius and a shorter window of unauthorized influence, not a guarantee that no adversarial write ever occurs. Every control pattern below has a documented residual risk, listed alongside it, because no single intervention closes the underlying trust gap between "the agent produced this state" and "a human intended it."

What it is not

A replacement for the surface-specific defense tables already published on this site. Those tables list the concrete controls for one entry path; this page organizes the patterns those tables have in common.
A product recommendation or vendor comparison for a specific guardrail, DLP, or policy-enforcement platform.
A claim that any control here has been benchmarked against production adversarial traffic at this site. The patterns are SSA editorial synthesis over the surface-specific articles' own sourced defense tables, not an independently measured control set.
A substitute for the Detection pillar. Controls that fire only after a human notices something wrong depend on detection already having happened; this page assumes detection exists and focuses on what a defender does before, during, and after a confirmed or suspected write.

In scope

The reason perimeter and input-filtering controls, the default posture in most application security programs, under-protect a durable state object.
Three recurring control stages, Prevent, Contain, and Recover, that generalize across all six state surfaces documented on this site.
A mapping from each stage's concrete controls to the six surfaces, with links to the surface-specific article that sources each row.
Common failure modes that let a defense program pass an audit on paper while missing the incidents it exists to stop.
The standards and research this model draws its vocabulary and evidence from.

Why perimeter controls under-protect a durable object

Most application security programs are built around a request-response boundary: validate input at the edge, authorize the action, log the response, and consider the transaction closed. That model works when the object at risk does not outlive the request. It fails against agent state attacks because the object at risk, by definition, is designed to outlive the request that created it. A memory record written in one session is read automatically in every later session. A configuration file edited once is loaded by every future clone and contributor. A tool definition approved on first use is trusted on every subsequent call unless something re-checks it. None of these objects pass back through the perimeter that validated the request that produced them.

This is the same structural gap the Detection pillar names from the observability side: ordinary monitoring is scoped to one session or one request, while the state that matters is deliberately scoped to survive across sessions. The defensive consequence is that a control applied only at the moment of the original write, no matter how strict, cannot protect the object during every later read that draws on it. A defense program has to decide, for each state surface, where in the object's lifecycle a control actually intervenes, not only whether a control exists somewhere in the pipeline.

A three-stage control model: Prevent, Contain, Recover

Across the surface-specific articles published so far, the concrete controls fall into three stages, matching the lifecycle of a state object from the moment it is proposed to the moment its effects are fully resolved. None of the three replaces the others; a defense program missing any one stage has a gap that the other two cannot close on their own.

Prevent: stopping an untrusted write from becoming trusted state

Prevention controls act at the write itself, before the candidate state is promoted to something the agent treats as fact or instruction on future turns. The recurring pattern is evidence-based promotion: a write is accepted as trusted state only when there is positive evidence the change reflects human intent, not merely that a tool call fired successfully. Concrete instances documented on this site include explicit write-time confirmation before a memory record is stored, source-aware tool gating that distinguishes a memory write triggered by ingested content from one triggered by direct user text, and human review gates on changes to project configuration files before they are merged into a branch other sessions will load.

Prevention is strongest against entry paths a defender already anticipated and weakest against novel ones, because a confirmation prompt or a gating rule has to know what to check for. Its most common failure mode, confirmation fatigue from prompts that fire on routine activity as often as on suspicious activity, trains reviewers to approve without reading well before an actual attack arrives, which is why prevention alone is never sufficient.

Contain: bounding what compromised state can do before it is found

Containment controls act after a write has already happened, on the assumption that some fraction of adversarial writes will get past prevention. The recurring pattern is blast-radius limitation: even if a piece of state is compromised, the actions it can drive are scoped narrowly enough that the compromise cannot reach its most damaging possible outcome unassisted. Concrete instances documented on this site include least-privilege scoping of what a memory record or a tool definition is allowed to influence, quarantine-before-deletion that freezes a suspect object's influence on new sessions without destroying it as evidence, pinned and signature-verified tool definitions that limit how far a server-side change to a tool's behavior can silently propagate, and session or handoff isolation that stops one compromised agent's output from being read as ground truth by every other agent in a multi-agent system.

Containment is the stage most often under-built, because it requires deciding in advance how much authority any single piece of state should be allowed to carry, which is a design question that has to be answered before an incident, not during one. A system where a single memory record or configuration line can authorize an arbitrary destination or an arbitrary install has no containment stage at all, regardless of how good its prevention controls are.

Recover: undoing effects and restoring a known-good baseline

Recovery controls act once a compromise is confirmed, and they are the stage most consistently under-specified across the surface-specific articles reviewed for this page. The recurring pattern is that deletion alone does not undo consequences already produced while the compromised state was live. Concrete instances documented on this site include propagation tracing that enumerates every session, agent, or artifact that read a confirmed-compromised object before deciding an incident is closed, revalidating any action a session took while relying on that object, and restoring from the last version of a configuration file, memory store, or tool definition that a diff trail confirms was clean, rather than assuming the version immediately predating discovery is safe.

Recovery depends on the state-diff and provenance telemetry the Detection pillar covers in more depth; a defense program cannot restore a known-good baseline it never captured, and cannot trace propagation through sessions it never logged as having read the object. This is the clearest point of overlap between the two pillars: Detection produces the trail, Recovery consumes it.

Mapping controls to the six state surfaces

| State surface | Where Prevent concentrates | Where Contain concentrates | Where Recover concentrates | Surface-specific article | | --- | --- | --- | --- | --- | | Context (compaction path) | Confirming a compactor kept load-bearing constraints before a summary replaces raw history | Bounding how much authority a compacted summary can carry into a new session unverified | Restoring from pre-compaction transcript when a summary is found to have dropped or altered a constraint | Compromised summaries and context compaction | | Durable memory (memory-write tool path) | Write-time confirmation and source-aware gating before a memory-write tool call is promoted to durable state | Least-privilege scoping of what a memory record can influence; quarantine before deletion | Propagation tracing across every session that read the record; restoring from the last confirmed-clean memory snapshot | Persistent memory injection | | Goals and instructions (configuration file path) | Human review and version control on configuration file changes before merge | Scoping what a configuration file is permitted to instruct without a separate authorization step | Reverting to the last reviewed version; auditing every clone and contributor session that loaded the poisoned version | Instruction file poisoning | | Tool and environment state | Pinning and signature-verifying tool definitions at approval time | Sandboxing tool execution and limiting a single tool's reachable actions | Re-fetching and diffing a tool's live definition against the approved baseline; revalidating calls made under a changed definition | MCP tool poisoning | | Plans and artifacts | Verifying a generated dependency name against a real package index before it reaches an install step | Running installs in an isolated environment before any artifact reaches a shared or production dependency set | Auditing every manifest a hallucinated package name reached before the install step was caught | Slopsquatting | | Shared and multi-agent state | Validating a handoff payload's claimed origin before another agent treats it as ground truth | Isolating sessions and scoping what one agent's output can write into another agent's context | Tracing every agent or session that consumed a poisoned blackboard entry or handoff before declaring an incident closed | Shared state poisoning in multi-agent systems |

No surface is covered by only one stage. The table records where each stage's most-cited control concentrates for that surface, not an exclusive assignment; a defense program that only builds one stage per surface has, at best, a third of the coverage the surface-specific article recommends.

Common failure modes in defense programs

Building prevention and stopping there, on the assumption that a confirmation prompt or a review gate removes the risk entirely, when the surface-specific evidence on this site shows every documented case eventually needed containment or recovery as well.
Scoping containment around what a legitimate user is expected to do rather than around what the state object is technically capable of authorizing, which leaves a compromised record or configuration line free to drive an action no legitimate user would have requested but that the system never explicitly disallowed.
Deleting a suspect state object immediately on discovery, which destroys the evidence a propagation trace needs and can leave actions taken under the compromised object unrevalidated because no one confirmed how far its influence had already spread.
Restoring from the most recent backup or version without checking, through the diff trail, whether that version was itself already compromised, which reintroduces the same defect the recovery step was meant to remove.
Treating a control as permanent once implemented, when a tool definition, a configuration file, or a memory record can pass every check at write time and still become the site of a later attack that a one-time gate never re-examines.
Building containment and recovery for the surface an incident happened to expose, then leaving the other five surfaces on this site's list uncovered until each one has its own incident.

Boundaries with similar concepts

This pillar and the Detection pillar are frequently conflated because both respond to the same six state surfaces. Detection answers whether a state change happened through an adversarial path; Defenses answers what happens next, whether that "next" is stopping the write before it lands, bounding its effect, or undoing its consequences. A program can have strong logging and alerting and still have no containment or recovery plan, which is a Defenses gap that a Detection audit alone will not surface.

This pillar is also not the same as general application security hardening. Input sanitization, authentication, and network segmentation remain necessary, but they are boundary controls for a single request, and the state surfaces this site documents are specifically the objects that persist past that boundary. A defense program that only hardens the request boundary has not yet addressed the object that outlives it.

Mapping to standards and research

The table below is SSA editorial synthesis connecting this control model to publicly maintained frameworks. It does not assert that any of these frameworks endorses this site's three-stage grouping.

| Source | Source-owned term or item | Relationship to this article | | --- | --- | --- | | OWASP Top 10 for Agentic Applications 2026 | `ASI06 Memory & Context Poisoning`; `ASI02 Tool Misuse and Exploitation`; `ASI03 Identity and Privilege Abuse`; `ASI04 Agentic Supply Chain Vulnerabilities`; `ASI10 Rogue Agents` | Risk categories this control model provides cross-surface Prevent, Contain, and Recover treatments for, without replacing OWASP's own mitigation guidance for each risk. | | MITRE ATLAS v2026.06 | `AML.T0080 AI Agent Context Poisoning` and its sub-techniques | Attacker-behavior classification; this page's control stages are a defender-side complement, describing what interrupts the behavior rather than reclassifying it. | | NIST AI 600-1 (2024-07-26) | Generative AI Profile, Manage function | Standards-level basis for treating risk response, including containment and recovery after a confirmed issue, as a distinct function from continuous measurement, which the Detection pillar already covers under Measure. | | Anthropic, How We Contain Claude | Blast-radius and containment design principles for agentic systems | Industry precedent for scoping what a single compromised component can do, cited here as the general containment pattern this page's Contain stage generalizes across all six state surfaces. | | Agent State Attack | Three-stage control model (Prevent, Contain, Recover) | SSA editorial synthesis, not attributed to the sources above. |

Related terms

Agent state attack: the umbrella definition this page's Defenses pillar entry sits under.
Detecting agent state attacks: the companion cross-surface page for the signals that trigger the controls documented here.
OWASP and MITRE ATLAS crosswalk: the broader framework mapping, including the state-transition boundaries these controls are meant to interrupt.
Compromised summaries and context compaction, persistent memory injection, instruction file poisoning, MCP tool poisoning, slopsquatting, and shared state poisoning: the surface-specific articles this cross-surface model draws its control patterns from.

FAQ

Do I need all three stages before a defense program counts as adequate?

No single stage is optional in principle, but a program can add them incrementally. Prevention alone stops the entry paths a defender already anticipated and leaves everything else exposed. Adding containment bounds the damage from paths prevention missed. Adding recovery closes the loop by undoing consequences and restoring a known-good baseline once a compromise is confirmed. Build in that order if starting from nothing, since each stage assumes less advance knowledge of the attacker's method than the one before it.

Is containment the same as sandboxing?

Sandboxing is one containment technique, most visible on the tool and environment state surface, where an untrusted tool call is executed somewhere its effects cannot reach production data or credentials. The broader containment pattern also includes least-privilege scoping of what a piece of state is permitted to authorize and quarantine-before-deletion for a suspect record, neither of which requires a sandbox in the execution sense.

Why does recovery need a diff trail instead of just restoring the last backup?

Because the last backup or the version immediately predating discovery is not guaranteed to be clean. A compromise can persist undetected across several backup cycles, and restoring from a compromised backup reintroduces the same defect the recovery step exists to remove. A diff trail against a write-protected baseline, the same telemetry the Detection pillar describes, is what lets a recovery step confirm which specific version was last known-clean rather than merely most recent.

How is this different from just reading the surface-specific defense tables?

Those tables list the concrete controls for one entry path each and are the right place to start hardening that specific surface. This page exists for the question those tables do not each answer on their own: which control investment generalizes across every surface at once, in what order to build Prevent, Contain, and Recover if starting from limited resources, and which failure modes recur regardless of which surface an incident eventually turns out to involve.

Sources

Verification and change history

Standards and versions referenced: OWASP Top 10 for Agentic Applications, Version 2026 (December 2025); MITRE ATLAS, data release v2026.06 (2026-06-30); NIST AI 600-1 (2024-07-26).

Last verified: 2026-08-28. The OWASP and MITRE identifiers, the NIST AI 600-1 publication date, and the Anthropic containment article were reused from this site's previously verified crosswalk and surface-specific entries. The three-stage grouping, the surface-mapping table, and the listed failure modes are SSA editorial synthesis over this site's own previously published, sourced defense tables, not a new independently benchmarked result.

Change history: 2026-08-28, initial defensive draft. Not scheduled for publication.

Working-term label: **Mixed provenance.** `ASI02`, `ASI03`, `ASI04`, `ASI06`, and `ASI10` are Standard Terms owned by OWASP. `AML.T0080` and its sub-techniques are Standard Terms owned by MITRE. NIST AI 600-1 and its Manage function are a Standard Term owned by NIST. The three-stage control model (Prevent, Contain, Recover), the surface-mapping table, and the listed failure modes are SSA editorial synthesis, not a standard or a benchmarked result.