Google published an evaluation of Agent Anomaly Detection, or AAD, against five public benchmarks on November 12, 2026. The company says the system flagged 87% of harmful instructions that an agent actually carried out. This is detection after execution, not prevention. Poisoned memory was a weakness: four detected cases out of 18 executed ones. Google conducted the study using one model and simulated applications; public benchmarks do not make it an independent audit. The product remains in Private Preview.
What the system observes
Official documentation describes asynchronous analysis of logs and traces. It also notes a November 12 extension to agents outside Google Cloud, including AWS and Azure, using ADK for Python 2.12.0 or later. Telemetry is exported to a Google Cloud project with Workload Identity Federation. Capturing input and response content is among the requirements. This is a specific integration with access and data-processing prerequisites, rather than a universal switch covering every agent.
The older AgentDojo research, one of the benchmarks used, provides context. Its original work builds an environment where agents perform tasks with tools while also encountering untrusted external data. This allows evaluation of both legitimate task completion and violations of security conditions. The source explains the testing approach; it does not independently certify AAD's results.
Why the denominator changes the interpretation
Our editorial analysis is that agent defenses need at least two separate questions: what action occurred, and what the operator learned afterward. Monitoring can support investigation and system improvement, but an external effect already produced has its own lifecycle. An alert does not cancel a sent document, automatically undo a change or establish that a recipient never received the data.
A hypothetical invoice-processing agent illustrates the distinction. If an external document contains an instruction to send a copy elsewhere, a useful pre-send control needs to assess whether the user authorized that particular operation. A separate monitoring system may detect unusual behavior later. The mechanisms have different jobs and can complement one another. This is an architectural example, not a reported incident or a test we conducted.
The same distinction matters when accepting a product. A team needs to define harmful outcomes, permitted actions, alert handling and responsibility for corrective steps. Without those definitions, a benchmark percentage can easily become a promise the measurement never made. The team also needs to check whether observation covers the necessary workflow steps, instead of treating an absence of alerts as an absence of problems.
Telemetry has boundaries too
Sending content for analysis requires a decision about which data may be recorded, how long it should be retained and who may read it. For a system handling confidential documents, that belongs in the integration assessment. Merely checking that an entry appears in a dashboard is insufficient. An explicit process for unavailable telemetry or incomplete records is useful as well.
The publication's practical value is an explicit measurement of a bounded defense and its weak points. SIExpo has not run these benchmarks and does not claim the reported percentage will recur in a real organization. Protection choices should depend on an organization's own tasks, permissions and consequences of failure.
Sources: Google - AAD public benchmark results, Google Cloud - Agent Anomaly Detection overview, AgentDojo - original benchmark paper.
The cover is a conceptual AI illustration, not a documentary photograph.
Editorial verification: 2026-11-13T07:35:06.745176+00:00.
