Google tests agent audits after harmful actions Google tests agent audits after harmful actions

Read the result as an audit

Google reports flagging 87% of executed harmful instructions across five public benchmarks. Its test used Gemini 2.5 Flash in simulated applications. False alarms ranged from 2% to 16% of benign sessions. The denominator is completed harmful behavior, not every attack attempt. That makes the result relevant to incident review, while leaving prevention as a separate engineering problem.

An older preview gains new evidence

The product entered Private Preview on September 16. Its launch description separates a lightweight pass over traffic from deeper reasoning about unusual sessions. The first stage identifies statistical outliers. Later analysis examines the session and, when needed, reconstructs individual tool interactions. Findings carry severity, an explanation and suggested next steps. They also appear in Security Command Center, where an operator can handle them alongside other security findings. The launch post describes an API for customer callbacks that can stop subsequent tool calls or a later turn. A finding can therefore influence what happens next without becoming a guarantee about what already happened. The audit reads existing logs and OpenTelemetry traces away from the live request path. Google presents that separation as a way to avoid adding latency to responses.

Monitoring can cross a hosting boundary

The overview documentation records another change on November 12: support for agents running outside Google Cloud, including AWS and Azure. Those agents require ADK for Python 2.12.0 or later and send traces and logs to a Google Cloud project. Authentication uses Workload Identity Federation. The prerequisites include capturing prompt inputs and response outputs, active tracing and reader access for the scanners. Being discovered as an agent is separate from enabling analysis. Monitoring must be enabled automatically through enrollment or explicitly for the agent. This makes the telemetry destination part of the architecture even when execution remains with another cloud provider.

A gate occupies a different point

Google’s separate Semantic Governance preview evaluates a proposed tool call before it runs. The policy engine considers the user’s request, conversation history and configured natural-language constraints. A rejected call is removed from the model response through the gateway. This control addresses permission to proceed, whereas an audit reconstructs behavior from recorded activity. The documentation places semantic policies alongside existing access controls, rate limits and network protections. It also distinguishes tool permission from whether a particular action fits the user’s request. An application can therefore keep a narrow tool identity and still evaluate individual actions at the moment they are proposed.