Google's Agent Anomaly Detection audits agent traces against four OWASP agentic risks

The enrollment rules decide what gets watched. Google says agents that do not meet the requirements are not discovered ^[14]. Discovery needs OpenTelemetry tracing and logging through the ADK, logging and observability buckets in the same US multi-region, and `enable_tracing` not explicitly set to false ^[10]. Miss one and the agent never appears in the monitored list, so the console shows a fleet with no gaps in it ^[23]. Discovered agents then sit inert until someone enables them: no analysis, no cost ^[13].

Detection runs in passes. A lightweight layer scans all traffic for statistical anomalies and flags unusual sessions, then an LLM reasoning layer reads the flagged sessions in depth ^[15]. A third layer, used where a case needs closer examination, goes down to individual tool executions, execution states and parameter histories inside the conversation trace ^[16].

Google's worked example is an Inventory Agent with a `list_inventory` tool. A user asks for 100 items at a time and the agent repeatedly calls the tool with different offsets until it has the whole catalog, producing no errors and no explicit policy violation ^[17]. The first layer flags the session on call volume and repetition. The second identifies the large-batch, offset-jumping pattern as systematic scraping ^[17]. The output is a Resource exhaustion finding, Critical severity, 95% probability, with recommended actions: rate-limit or block `list_inventory` for that user, and restrict bulk inventory access through authorization checks ^[18].

Those actions are recommendations in a triage queue ^[3]. The layer names the fix; the rate limit is applied by whoever picks up the finding ^[22]. In the scraping case, the tool calls continue until someone acts.

Coverage is four categories from a ten-item list, which leaves six OWASP agentic categories without a named detector ^[21]. Inside the four, the sub-risks are specific enough to write into a requirement: indirect prompt injection, unsafe tool chaining and parameter manipulation under tool misuse ^[5]; confused-deputy vulnerabilities, persona forgery, memory escalation and dynamic trust delegation under identity and privilege abuse ^[6]; infinite execution loops, oscillating retries and feedback-loop amplification under cascading failures ^[7]; and agents that abandon declared roles, bypass guardrails or deviate from system instructions ^[8]. Resource exhaustion and escalating token usage are handled as operational risks ^[9].

Business-specific rules are not in the preview. "We are actively working on the ability for users to define what anomalies mean in the context of their business," said Achuth Narayan Rajagopal, a senior software engineer at Google ^[19]. He said users will be able to write flexible anomaly detectors in natural language together with deterministic rules, and validate the accuracy of that logic on past traffic ^[20].