Detecting Agent State Attacks: A Cross-Surface Telemetry and Signal Model

Detecting an agent state attack means recognizing that context, memory, goals, plans, tool state, or shared state changed through an adversarial path rather than a legitimate one, early enough to act before the changed state drives an authorized action. This page is the Detection pillar's cross-surface entry. It does not repeat the surface-specific "observable signs" sections already published for compromised summaries, shared state poisoning, persistent memory injection, instruction file poisoning, MCP tool poisoning, and slopsquatting. Instead, it names the signal families those sections all draw from, and the telemetry decisions that determine whether any of them are observable at all.

What it is

The defining object is detection capability itself: the logging, diffing, and alerting infrastructure that turns a state change into an observable event before or shortly after it influences a decision. The defining cause of a detection gap is architectural, not adversarial. Most agent frameworks log errors and exceptions, not state transitions, so a state attack that produces no error and no exception leaves no trace in the logs a team already has. The defining consequence of closing that gap is dwell-time reduction: the interval between an adversarial write and its discovery, which is also the interval during which the compromised state can keep influencing decisions.

Because this article spans every state surface rather than one entry path, its classification fields read `Multiple`, consistent with agent state attack and the OWASP and MITRE ATLAS crosswalk.

What it is not

A replacement for the surface-specific detection sections already published on this site. Those sections list the concrete signals for one entry path; this page organizes the signal families those lists have in common.
A product recommendation or vendor comparison for a specific SIEM, observability platform, or guardrail tool.
A claim that any detection model here has been measured against production adversarial traffic. The signal families are SSA editorial synthesis over documented cases and cited research, not a benchmarked detector.
A substitute for the authorization and least-privilege controls that limit what a compromised state can do even if it is never detected. Detection shortens dwell time; it does not remove the underlying trust gap.

In scope

The reasons ordinary application monitoring is structurally blind to most agent state attacks.
Four recurring signal families that generalize across context, durable memory, goals and instructions, plans and artifacts, tool and environment state, and shared and multi-agent state.
The telemetry an agent or platform needs to capture before an incident, since none of the four families are observable retroactively without it.
Common failure modes that cause a detection program to exist on paper but miss the events it was built for.
Defensive guidance for turning a signal into a contained, recoverable response.

Why ordinary application monitoring misses state attacks

Conventional application observability is built around a working assumption: bad input produces a bad output, an exception, or a failed request, and all three are visible in existing logs. Agent state attacks routinely violate that assumption. A poisoned memory record, a rewritten instruction file, or a manipulated tool description does not usually throw an error. The agent runs successfully, calls the tools it is authorized to call, and produces output that looks coherent, because the model is doing exactly what its now-corrupted state tells it to do. The failure is in what the agent believed going in, not in how it executed once it believed it.

This is why the recurring finding across the documented cases on this site is not "the agent crashed" but "the agent did something a reviewer would not have approved, using state nobody remembers approving." Real-time failure detection research reinforces the same point from the reliability side: LLM agents can loop, drift from their original goal, fabricate results, or silently absorb corrupted content mid-episode without producing an exception a conventional monitor would catch, which is why recent work builds lightweight monitors trained specifically on healthy-run behavior rather than relying on error signals that never fire (arXiv 2608.02464, *Real-Time Detection and Repair of LLM Agent Failures*). That paper is framed as a reliability contribution, not a security one, but the behavioral fingerprint it targets, drift from established patterns with no accompanying error, is the same fingerprint a state attack leaves.

A second reason ordinary monitoring misses these events is scope. Application logs are usually scoped to one session or one request. A durable memory write, an instruction file edit, or a shared blackboard entry is deliberately built to outlive the session that created it and to be read by sessions that have no logging relationship to the one that wrote it. A monitor that only watches within a session cannot see the propagation that defines the attack's actual impact.

A four-signal detection model

Across the surface-specific articles published so far, the concrete signals fall into four recurring families. None of them require inventing surface-specific tooling from scratch; each is a specialization of a general pattern.

Provenance-mismatch signals

These signals compare the source of an input against the trust level the system extends to the state it produced. A memory write triggered by a document the agent merely read, rather than by direct user instruction, is a provenance mismatch. A tool description that changed between the version a human approved and the version a server now serves is a provenance mismatch at the definition level. The common test is: does the state's origin match the origin the system assumed when it decided to trust that state automatically? Provenance-mismatch signals require tagging input source at ingestion, before the agent acts on it, because the distinction between user-typed and ingested content is usually lost by the time a downstream tool call fires.

State-diff and integrity signals

These signals compare a state object's current content against a known-good baseline: the previous version of an instruction file, the last confirmed-clean memory record, the tool definition captured at approval time. A diff that introduces a directive, a destination, or a permission change where the baseline had none is a state-integrity signal, independent of how the change happened. This family is the only one of the four that does not depend on knowing an attacker's method in advance, which makes it useful against entry paths not yet documented. It requires storing the baseline somewhere the attacker's write path cannot also reach, since a diff against a baseline the same compromise can overwrite proves nothing.

Behavioral-consequence signals

These signals watch what the agent does after a state change rather than the state change itself: a new destination in an outbound call, a tool invoked that the same task has never invoked before, an install step naming a package with no prior appearance in the project. Behavioral-consequence signals catch attacks whose entry path was never instrumented, at the cost of firing after some influence has already occurred rather than before. They are the natural complement to provenance and integrity signals, which fire earlier but only for entry paths someone thought to watch.

Cross-session and cross-agent propagation signals

These signals answer a question the first three families cannot: has the compromised state already reached other sessions, other agents, or other artifacts? A repeated claim appearing in unrelated sessions after one contaminated write, a shared blackboard record read by more agents than expected, or a poisoned dependency name appearing in more than one generated manifest are all propagation signals. This family requires a join key connecting the originating write to every later read, which most systems do not retain by default because within-session logging has no reason to track cross-session reads.

Mapping signal families to the six state surfaces

| State surface | Where each family concentrates | Article with the surface-specific list | | --- | --- | --- | | Context and durable memory (compaction path) | State-diff signals on what a summary kept or dropped; propagation signals across sessions that inherit a compacted summary | Compromised summaries and context compaction | | Durable memory (memory-write tool path) | Provenance mismatch between ingested content and a memory-write call; propagation across every session that re-reads the record | Persistent memory injection | | Goals and instructions (configuration file path) | State-diff signals against the last reviewed version of the file; propagation to every clone and contributor session that loads it | Instruction file poisoning | | Tool and environment state | State-diff signals between an approved tool definition and what a server now serves; behavioral-consequence signals on tool arguments and destinations | MCP tool poisoning | | Plans and artifacts | Behavioral-consequence signals on install steps naming packages absent from any prior, verified manifest | Slopsquatting | | Shared and multi-agent state | Propagation signals across every reader of a blackboard, handoff payload, or shared memory record | Shared state poisoning in multi-agent systems |

No surface depends on only one family. The table records where each family's strongest signal concentrates for that surface, not an exclusive assignment; a thorough detection program runs all four families against every surface it can instrument.

Building the telemetry baseline before an incident

None of the four signal families are observable after the fact if the underlying telemetry was never captured. Four categories of logging make the difference between a detectable state attack and an invisible one.

Input provenance tagging records, for every piece of content the agent processes, whether it came from direct user text, an ingested document or page, a tool result, or another agent's output, and attaches that tag to anything the content later causes the agent to write. Without this tag, a provenance-mismatch signal cannot exist, because there is nothing to compare a downstream write against.

Full tool-call argument logging captures the complete arguments of every tool call, not a truncated summary, including memory-write calls, file-write calls, and outbound network calls. Summarized or sampled logs are the most common reason a behavioral-consequence signal is unavailable during an actual incident review: the one call that mattered was the one that got truncated.

State snapshot and diff retention keeps a versioned, append-only history of configuration files, tool definitions, and durable memory records, stored somewhere the same compromise path cannot also modify. A diff is only as trustworthy as the baseline it diffs against; a baseline stored in the same mutable location as the state it protects gives an attacker a single write that defeats both the state and the detector.

Cross-session and cross-agent join keys connect a state write to every later read of that same object, across session boundaries and agent boundaries. This is the piece most systems omit by default, because within-session logging has no natural reason to track who reads a record after the session ends. Without it, propagation signals cannot be computed even when everything else is logged correctly.

The NIST AI Risk Management Framework's Generative AI Profile places this kind of continuous measurement inside its Measure function, treating monitoring as an ongoing activity rather than a one-time evaluation, because model behavior, usage patterns, and the state an agent accumulates all change after deployment (NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, 2024-07-26; NIST AI Risk Management Framework overview).

Common failure modes in detection programs

Treating detection as a one-time content moderation scan on inputs rather than a continuous property of state over its full lifetime. A memory record or configuration file can pass every check at write time and still become the site of an attack discovered only through a later diff.
Sampling or truncating tool-call logs to save storage, which silently disables behavioral-consequence signals for exactly the calls an incident review will need in full.
Storing baselines and diffs in the same location the state itself lives, so a single compromise can rewrite both the state and the record a detector would have compared it against.
Building provenance tagging that stops at the first hop. Content re-processed, summarized, or relayed through an intermediate tool call loses its original tag unless the tag is deliberately propagated through every transformation.
Confusing accidental degradation with adversarial compromise. A dropped constraint or a stale record with no evidence of adversarial cause belongs to reliability engineering, not to this pillar; conflating the two either over-escalates ordinary defects or under-investigates real incidents by assuming a good-faith explanation before checking for one.
Alert fatigue from confirmation prompts that fire on routine, benign activity as often as on suspicious activity, which trains reviewers to approve without reading well before an actual attack arrives.

Defenses: from signal to response

The table below is SSA editorial guidance, not a benchmarked control set.

| Stage | What it does | Applies best when | | --- | --- | --- | | Provenance-aware alerting | Flags a state-write tool call whose triggering input carries an ingested-content tag rather than a direct-user tag | The agent processes untrusted documents, pages, or tool output in the same session as write-capable tools | | Baseline diffing on a write-protected store | Flags any state change that introduces a directive, destination, or permission absent from the last confirmed-clean version | Configuration files, tool definitions, and durable memory records that change infrequently relative to session volume | | Behavioral anomaly monitoring | Flags a tool call, destination, or generated artifact that departs from the pattern established for that task or project | Entry paths not yet instrumented with provenance or diff signals, as a catch-all rather than a first line | | Propagation tracing on confirmed findings | Enumerates every session, agent, or artifact that read a confirmed-compromised state object | Any finding from the first three stages, before deciding the incident is contained | | Quarantine before deletion | Freezes a suspect object's influence on new sessions while preserving it for forensic review, rather than deleting it immediately | Any confirmed or highly suspected finding, so evidence is not destroyed before the propagation trace is complete |

Containment should freeze a suspect object's influence before removing it, since deletion alone does not undo actions already taken while the object was live. Recovery should revalidate every action taken by a session that read the compromised object, not only the session that wrote it, and restore from the last version confirmed clean by the diff trail rather than assuming the most recent version predating discovery is safe.

Mapping to standards and research

| Source | Source-owned term or item | Relationship to this article | | --- | --- | --- | | OWASP Top 10 for Agentic Applications 2026 | `ASI06 Memory & Context Poisoning`; `ASI10 Rogue Agents` | Risk categories this detection model provides cross-surface signal families for, without replacing OWASP's own risk descriptions. | | MITRE ATLAS v2026.06 | `AML.T0080 AI Agent Context Poisoning` and its sub-techniques | Attacker-behavior classification; this page's signal families are a defender-side complement, not an ATLAS-owned mitigation set. | | NIST AI 600-1 (2024-07-26) | Generative AI Profile, Measure function | Standards-level basis for treating monitoring as continuous rather than a one-time gate. | | arXiv 2608.02464 (v1, 2026-08-03) | *Real-Time Detection and Repair of LLM Agent Failures* | Reliability-side research demonstrating that mid-episode drift and silent absorption of corrupted content require monitors trained on healthy-run behavior, since they produce no exception a conventional monitor would catch. | | Agent State Attack | Four-signal detection model | SSA editorial synthesis, not attributed to the sources above. |

Related terms

Agent state attack: the umbrella definition this page's Detection pillar entry sits under.
OWASP and MITRE ATLAS crosswalk: the broader framework mapping, including the state-transition boundaries this page's signals are meant to make observable.
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 signal families from.

FAQ

Do I need all four signal families to detect anything?

No. A program with only state-diff signals against a write-protected baseline still catches a meaningful share of incidents, since that family requires no advance knowledge of the attacker's method. The other three families close gaps that diffing alone leaves: mismatched provenance before a write completes, downstream behavior when no diff was possible, and propagation once a compromise is confirmed. Add families in the order your telemetry actually supports, rather than deferring detection until all four exist.

Is behavioral-consequence monitoring the same as ordinary anomaly detection?

It uses similar techniques, but the object being modeled differs. Ordinary application anomaly detection usually models request volume, latency, or error rate. Behavioral-consequence signals model the agent's tool calls, destinations, and generated artifacts against the pattern established for a specific task or project, which is a narrower and more task-specific baseline than most general-purpose anomaly tooling assumes out of the box.

How is this different from just reading the surface-specific detection sections?

Those sections list the concrete signals for one entry path each and are the right place to start an instrumentation effort for that surface. This page exists for the question those sections do not each answer on their own: which telemetry investment pays off across every surface at once, and which failure modes recur regardless of which surface an incident eventually turns out to involve.

Can detection alone stop an agent state attack?

No. Detection shortens the interval between a compromise and its discovery; it does not remove the trust gap that let the compromise happen, and it does not undo an action already taken before discovery. Pair detection with the authorization, least-privilege, and containment controls described on each surface-specific article, and treat a fast, confirmed detection as the trigger for those controls rather than as the end of the response.

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); arXiv 2608.02464, v1 (2026-08-03).

Last verified: 2026-08-25. The OWASP and MITRE identifiers were reused from this site's previously verified crosswalk entry. The NIST publication date and the arXiv title, author, and version date were read from the sources' own pages on this date.

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

Working-term label: **Mixed provenance.** `ASI06`, `ASI10`, and `AML.T0080` are Standard Terms owned by OWASP and MITRE. NIST AI 600-1 and its Measure function are a Standard Term owned by NIST. The four-signal detection model, the surface-mapping table, and the listed failure modes are SSA editorial synthesis, not a standard or a benchmarked result.