Runtime Agent Security Monitoring Signals and Detection Logic

AI agents no longer just advise, producing a suggestion for a human to review before anything happens. A flawed model can be caught before it ships, and a post-incident review can explain what happened after the fact, but only the runtime moment sits between an attacker's intent and its consequence. The 2026 Singapore Consensus on Global AI Safety Research Priorities places three of its four operational monitoring principles for deployed agents squarely at this moment: runtime assurance (Principle 7), interruptibility (Principle 8), and legibility (Principle 9), alongside human oversight. That grouping reflects where the research consensus believes the control surface actually sits.

The practical consequence for anyone building or securing these systems is that a threat list is not enough. What's needed is a signal map: a catalogue of the specific behavioral patterns an agent emits when it is under attack, paired with detection logic precise enough to act on those patterns without halting every legitimate workflow in the process. Agents act at machine speed, often with no human reviewing each decision, so the gap between compromise and damage is measured in tool calls, not hours. The rest of this piece builds that map: which signals actually indicate an attack in progress, and what detection logic should do when it sees them.

The behavioral signal space for agents versus traditional telemetry

Traditional software telemetry assumes a deterministic baseline. AI agents break that assumption by design. A sudden change in what an agent does is not automatically evidence of compromise. It might just be the agent doing its job in a slightly different context than it encountered yesterday.

The difficulty runs deeper than variable behavior. Behavioral monitoring has to compensate for a self-diagnosis the model is incapable of performing on its own.

Attacks also have to be understood as sequences rather than events, which compounds the problem. If monitoring inspects single actions in isolation, it misses this pattern by construction. If you profile an agent once at deployment and treat that profile as fixed, the baseline goes stale.

None of this argues against monitoring. It argues against treating the signal space as a single anomaly score. The honest difficulty here is that tool calls, memory writes, privilege changes, and multi-turn conversation state are different kinds of signal, generated at different points in the execution pipeline, with different failure modes. You need detection logic for each category, not one shared, generic threshold.

Tool calls as the primary signal surface: what the invocation record reveals

Tool calls give you the richest and most structured evidence of the four signal categories. A tool invocation record shows which tool was called, with what arguments, in what sequence, under which identity, and toward which downstream system. That structure is what detection logic needs: an observable, parseable artifact rather than an attempt to read intent out of free-text model output.

Several patterns in that record carry real weight. Sequence matters too. Volume and rate anomalies round out the picture: an agent calling the same tool repeatedly inside a short window, or firing off a burst of calls to multiple tools inconsistent with its task type, can signal an attempt to run up costs on a connected service or an attempt to exfiltrate data before anyone notices.

The EchoLeak case, tracked as CVE-2025-32711 against Microsoft 365 Copilot with a CVSS score of 9.3, illustrates what this kind of enforcement is built to catch. The aggregate pattern across the sequence of invocations was the signal, not any individual call in isolation. Exabeam's 2026 analysis names tool call and API interaction visibility, logging and analyzing how an agent interacts with tools, APIs, and external services, as one of the core capabilities to evaluate in any enterprise AI agent security monitoring platform, and the EchoLeak case shows that this visibility must span the sequence.

The protocol layer has widened this surface further. CVE-2025-49596 affected the Anthropic MCP Inspector in versions below 0.14.1, exposing a CSRF and DNS-rebinding vulnerability that enabled remote code execution through the Inspector UI, classified under CWE-306. Both exploited the same invocation pathway that legitimate tool calls use, so tool-call monitoring has to be the first and most actionable layer of defense.

Memory writes and context manipulation as a slower but harder-to-reverse signal class

Tool calls are fast and transactional: a single call either happens or it doesn't, and a monitoring system can block or roll it back in the moment. Memory operates on a different clock. A poisoned memory entry does not need to trigger a new alert every time it causes damage. It sits in storage, and from that point on it quietly shapes every retrieval and tool selection the agent makes. That persistence is why memory integrity is a runtime concern, not something you resolve once at deployment.

A few categories of memory signal matter most. And cross-session persistence of entries that weren't present in the prior session's approved context is a delta that should trigger provenance review before the new session is allowed to execute anything built on top of it.

The 2026 Singapore Consensus treats this as a design-level obligation, not an optional feature. The PoisonedRAG technique, presented at USENIX Security 2025, demonstrated that inserting a small number of crafted documents into a retrieval corpus is sufficient to make a system reliably return attacker-chosen answers for specific queries. Detecting this requires more than logging what got written into memory. You need to log where each entry came from and whether that source was checked and trusted before it can shape the agent's next decision. Agentic web security research treats this as a necessary condition for any multi-agent system to remain controllable.

Privilege escalation patterns: how agents accumulate authority they were never granted

Tool calls describe what an agent does. Memory describes what it knows. Privilege describes what it's permitted to do, and that boundary is where agents become genuinely attractive targets, because they hold credentials and operate with elevated access that a human user would never grant to an unsupervised script. It builds through a series of individually authorized steps that, taken together, exceed what the agent was ever meant to be capable of doing. That is why checking authorization at each step in isolation is not enough as the only control.

You need to watch several signals at the identity and access layer closely. An agent reading from System A, writing to System B, and triggering a workflow in System C within a single task may have a combined permission footprint that exceeds anything individually granted, even if each individual access was technically authorized, so cross-system access chains deserve scrutiny as an aggregate.

EchoLeak shows this pattern again, but this time it looks like privilege escalation, not tool-call abuse. The attack bypassed Microsoft's XPIA classifier, evaded link redaction, exploited auto-fetched image rendering, and abused a Teams proxy, in sequence. Each individual step fell within policy. The chain as a whole did not.

Least privilege, the first principle of the 2026 Singapore Consensus Companion Report on Agentic Risk Management, and traceable identity, its second principle, describe the design intentions meant to prevent this kind of accumulation. The monitoring signal is what catches the moment those design intentions get violated at execution time, when design and runtime behavior diverge. Tigera's 2026 analysis of AI agent security providers finds that least-privilege enforcement and real-time anomaly detection, specifically for agents that exceed their intended scope or attempt escalation, are core IAM capabilities for this class of system. Much of the time, the escalation itself is downstream of something that happened earlier in the conversation: a successful prompt injection that redirected the agent's goal before it ever touched a credential it shouldn't have.

Multi-turn drift: detecting goal hijack across a conversation or task sequence

Multi-turn drift is the signal category most distinctive to agentic systems, and the one most monitoring platforms handle worst. It's the mechanism through which indirect prompt injection achieves its most serious outcomes, because the attack doesn't need to succeed in a single turn. It steers the agent incrementally, turn by turn, until the agent's active goal has quietly been replaced by the attacker's goal, with no single turn ever looking dramatic enough to trip a per-turn inspection.

Several signals surface specifically at this layer, visible only to a monitor that inspects more than one turn at a time. The pattern also appears as abnormal session length or branching, when a task that should finish in a predictable number of turns stretches out far longer, or splits into sub-tasks the original request never implied.

Research on secure agentic web systems argues that monitoring needs to track entire delegation chains end to end and support interventions, blocking, rollback, quarantine, aimed at the specific agent responsible within a chain rather than shutting down an entire workflow over one bad actor. Partnership on AI's research makes a related argument from a different angle: failure detection should operate as layered controls positioned at different stages of execution, before an action is taken, during execution, and across the multi-step sequences where individual failures compound into something larger. That framing maps directly onto multi-turn drift as a signal that spans stages, living across the sequence as a whole.

Two research directions give this problem a more tractable shape. Enforcement has to follow from detection here: when a multi-turn drift signal fires, it needs to trigger session review or rollback, not sit quietly in a log file waiting for someone to notice it days later.

Translating signal categories into enforceable detection logic

Tool call invocations, memory writes, privilege escalation, and multi-turn drift each appear at a different point in the execution pipeline. That fact alone determines the architecture: enforcement has to be layered across those points rather than centralized at one chokepoint that tries to catch everything at once.

A few architectural principles follow directly from the signal map. For tool calls, pre-action authorization should be the primary enforcement gate: check each proposed call against evidence in the agent's context before it executes, not after. The enforcement model ProvenanceGuard, developed by She, Liang, and Kang in 2026, formalizes this as determining whether a proposed tool call is backed by traceable evidence in the agent's context, an explicit test applied before execution. Multi-turn drift requires stateful comparison: a running representation of the agent's goal and instruction sources across turns, checked turn by turn against its prior state, without relying on the agent to self-report that anything has changed.

Detection logic that only alerts is incomplete. It has to be able to produce an enforcement decision. Four actions cover most of what's needed. Alerting with full context surfaces the enforcement event to a human reviewer along with the complete execution trace rather than just the triggering signal, since the reviewer needs to see the whole chain to judge it, not only its last link.

The 2026 Singapore Consensus makes the stakes of this explicit through its eighth principle, interruptibility, which requires that deployed agents can be paused, redirected, stopped, and have their actions reversed by human operators at any point, and that the agent itself cannot tamper with those mechanisms. If detection logic cannot produce a halt signal, it fails that principle. A monitoring layer that only watches the agent's main traffic path misses side channels, memory writes arriving through retrieved content, and credential use happening through delegated identities, and a monitoring layer that only samples traffic misses the low-frequency, high-severity events that matter most. Both gaps need to be documented as known limitations of whatever system is deployed.

Verifying detection logic against approved workflows before shipping

Detection logic built to catch malicious signals will also fire on edge cases inside legitimate workflows, and the cost of that false positive is not a missed alert. It can mean a blocked business process, a failed tool call mid-task, or a quarantined session that was carrying out perfectly valid work. That asymmetry is what makes verification mandatory.

Every rule, provenance check, and multi-turn comparison added to the enforcement layer has to be run against the full set of approved workflows to confirm nothing breaks, and that verification needs to happen before the safeguard reaches production, not after. The practical discipline looks like this: each new detection rule should be proven against a real instance of the target attack in an isolated environment, not just a synthetic example constructed to make the rule look good. Each enforcement action should be re-run across every approved workflow under the new rule to confirm that blocking, rollback, or quarantine logic doesn't trigger on legitimate behavior it was never meant to touch. Each change should leave behind a reproducible record of what was tested, what was confirmed, and what was approved, so the decision to ship rests on evidence rather than on a reviewer's confidence that the logic looks sound on paper.

A minimal-safeguard principle governs this tradeoff: the best detection rule is the smallest one that stops the attack without disrupting approved workflows, and broader rules that catch a wider range of signals also break a wider range of legitimate behavior along the way. That tradeoff becomes visible once it's tested against real workflows. Human approval sits at the end of this process as the final gate. Detection logic should be signed off by a reviewer capable of reproducing the test, not merged silently by an automated pipeline that nobody checked by hand. The 2026 Singapore Consensus holds this as a matter of design, not preference: Principle 10, human oversight, and Principle 3, auditability, both require that security changes stay traceable and remain under human control, from the signal that triggers detection through the enforcement decision that follows it.