Google Agent Anomaly Detection Needs a Shadow-Mode Gate

Google's Agent Anomaly Detection overview describes a reasoning-based audit layer for agents deployed on Gemini Enterprise Agent Platform. It reads OpenTelemetry logs and traces, identifies statistical outliers, reasons over flagged sessions and can reconstruct individual tool calls, states and parameter histories.

That is useful coverage for a CTO, security engineering lead or agent-platform owner. It is also easy to release badly. A team can enable the preview, route findings into Security Command Center and immediately treat severity or probability as permission to stop production work. That skips three decisions the product cannot make for the business:

1. whether the captured telemetry is complete and appropriate to retain;
2. whether the detector's finding matches the team's own definition of unacceptable behavior;
3. who is authorized to interrupt a later tool call or next turn.

The safer release has five stages: eligible, observed, shadowed, labelled and authorized. Each stage needs evidence before the next one begins.

Start with the temporal boundary

Google says the service analyzes logs and traces asynchronously, outside the live request path. The private-preview announcement says an API can retrieve anomalies for a session, and an ADK callback or plugin can use customer-set severity and probability thresholds to block subsequent tool calls or halt the next turn.

The words subsequent and next define the control boundary.

A finding cannot retroactively prevent an effect that has already occurred. If an agent has already called refund.issue, inventory.export or account.disable, the anomaly service can help explain the session and inform a response. It cannot convert that prior call into a rejected one.

Separate two paths in the operating contract:

Use the anomaly service to deepen the second path. Do not weaken the first one because a later detector exists. The existing DVNC guide to human approval gates covers effect-bound approvals on the live path. The two controls solve different problems.

Stage 1: prove the agent is eligible

The current preview has a narrow technical envelope. Google lists these prerequisites:

• the agent is deployed on Agent Runtime;
• it uses ADK for Python 1.2 or later, with 2.1.0 or later recommended;
• logging and observability buckets use supported US or EU multiregions and align as documented;
• OpenTelemetry tracing and logging are enabled through ADK;
• raw prompt input and response output are captured;
• tracing has not been explicitly disabled;
• the regional scanner service accounts can read the relevant buckets;
• Log Analytics and Observability Analytics are enabled;
• active telemetry is flowing.

There is one bucket detail worth checking explicitly. Google's overview says the _Default logging bucket is global unless the organization changed it. That global location works only with the US multiregion for this service. An EU deployment needs an eu logging bucket, and the logging and observability buckets must be in the same multiregion.

An eligible agent can appear as a monitored agent before active analysis. Google says discovery alone does not run analysis or incur analysis cost. Explicit enablement is a separate step.

Record eligibility as a manifest rather than a console memory:

agent_anomaly_admission:
  preview_access: pending | approved
  runtime: agent-runtime
  adk_python: 2.1.0
  logging_region: us | eu | global
  observability_region: us | eu
  scanner_reader_verified: false
  log_analytics_enabled: false
  observability_analytics_enabled: false
  active_data_observed: false
  owner: agent-platform

The values above are a blank structure, not a statement about a deployed system. Keep the evidence beside the agent revision and update it when the runtime, region or telemetry configuration changes.

Stage 2: treat raw telemetry as a governed dependency

Agent Anomaly Detection needs enough context to reason about behavior. Google's current eligibility criteria include capturing prompt input and response output contents. That requirement is not merely an observability switch. It changes what sensitive material enters logs and which scanner identities may read it.

Before enablement, answer:

• Can prompts or outputs contain customer data, credentials, health information, payment data or internal instructions?
• Which fields can be redacted before export without destroying the detector's useful context?
• How long are logs and traces retained?
• Are logging and observability buckets covered by the intended region, access controls and deletion policy?
• Can a responder inspect the full session, and is that access itself audited?
• Which downstream resource IDs can be recorded instead of copying sensitive payloads into telemetry?

The correct answer is rarely “log everything forever.” It is to preserve the minimum session context required for analysis and reconstruction, with explicit retention and access. A detector that depends on raw content creates an evidence surface and a privacy surface at the same time.

Also test active data flow. The overview says an agent with no telemetry cannot be verified or enrolled. A green configuration screen is not evidence that production traces contain tool names, normalized arguments, execution state and result context. Run a bounded synthetic session and inspect the emitted records before enabling analysis.

Call the stage OBSERVED only when the team can join:

1. the agent revision and declared role;
2. the session and actor context;
3. each tool invocation and a redacted argument shape;
4. the tool response or error;
5. the authoritative downstream result when an effect occurs.

The anomaly service reasons over behavior. It does not replace the authoritative business read-back. If a finding says a payment tool was misused, the incident record still needs the payment system's state, not just the model transcript.

Stage 3: enable analysis without enforcement

Once eligibility and telemetry are proven, enable the agent in shadow mode. Findings can flow to the designated review surface, but they must not automatically block a tool or halt a turn.

This is not passive observation. A useful shadow period has a contract:

shadow_contract:
  agent_revision: required
  start_at: required
  end_condition: labelled-session target defined by owner
  finding_owner: required
  response_sla: defined by impact class
  business_context_recorded: required
  authoritative_outcome_joined: required
  automatic_enforcement: false

The labelled-session target and response times belong to the organization. They are not universal numbers. A high-volume read-only research agent, a low-volume refund agent and an internal administrative agent have different exposure and review capacity.

Google's current default categories include tool misuse, identity privilege abuse, cascading failure, rogue behavior and resource exhaustion. Start by mapping each category to an actual business impact. “Tool misuse” is still too broad to authorize a stop. The relevant distinction might be an unapproved write, a widened target set, a forbidden data source or a sequence that bypasses a required handoff.

For every finding, label at least:

Do not discard false positives as noise. They are calibration evidence. Do not assume an unflagged session is safe either. Sample ordinary sessions and known red-team cases so the review can discover false negatives and telemetry gaps.

Stage 4: calibrate a response policy with your own labels

Google's blog says a customer can set severity and probability thresholds for a programmatic reaction. Those fields are useful inputs. They are not a universal policy.

Severity describes the detector's assessment of the finding. Probability expresses its confidence under the product's model. Neither field knows whether the operation is reversible, whether an owner already approved the effect, whether a downstream system rejected it or whether stopping the next turn creates a larger operational hazard.

Build the response policy from labelled sessions and impact:

response_policy:
  version: required
  applies_to:
    agent_revision: required
    workflow: required
  stop_severities: organization_defined
  minimum_probability: organization_defined
  requires_human_approval: true
  allowed_response_scope: subsequent-only
  reversible_actions:
    - disable_agent_revision
    - revoke_downstream_credential
    - block_specific_tool
    - require_manual_handoff
  forbidden_actions:
    - retry_uncertain_write
    - erase_incident_evidence
    - claim_current_call_was_blocked

The schema is intentionally blank where the organization must decide. Set thresholds only after reviewers can explain their error cost. A false positive on a read-only research task may waste analyst time. A false positive that halts a time-sensitive customer operation may create its own incident. A false negative on a privileged write may be more serious than either.

Track review capacity with variables, not borrowed benchmark numbers:

daily review minutes = findings per day * median review minutes
queue days = open findings / findings reviewed per day
label coverage = labelled findings / total findings
outcome coverage = findings joined to authoritative state / total findings

If the queue grows beyond the owner's capacity, automatic enforcement is not the remedy. Narrow the enrolled agents, improve prevention controls, reduce telemetry ambiguity or staff the review. A detector whose evidence no one can process is not a control plane.

Stage 5: authorize a later response

Only a calibrated policy and an accountable owner can turn a finding into an effect. Keep the response narrow and recoverable.

A programmatic callback should receive a small decision record:

{
  "session_id": "required",
  "finding_id": "required",
  "agent_revision": "required",
  "policy_version": "required",
  "disposition": "approved-stop | approved-handoff | observe",
  "scope": "subsequent-only",
  "authorized_by": "required",
  "expires_at": "required"
}

The callback should then perform one bounded action: block a named tool for the affected session, halt the next turn, force a human handoff, disable one agent revision or revoke one downstream credential. Record the action and verify its state.

Avoid a broad “agent unsafe” flag that silently spreads across versions and workflows. Findings attach to evidence. Responses attach to authority, scope and time.

The same caution applies to Security Command Center. Google's overview says findings surface there and currently names Standard, Premium or Enterprise as supported tiers. The separate Security Command Center tier documentation also says the Enterprise tier is deprecated and scheduled to shut down in 2027. Verify the organization's current tier, finding route, notification path and owner before the pilot. Do not assume that a supported product label means the right responders will see the finding.

A tested admission evaluator

I built a dependency-free evaluator for this article and ran twenty synthetic cases. They cover preview access, runtime, ADK version, region alignment, scanner permissions, analytics, traces, raw-content capture, active data, explicit enablement, calibration policy, open label gaps, triage ownership, threshold handling, human approval and temporal scope. All twenty pass.

The synthetic fixture uses twelve labelled sessions, HIGH and CRITICAL severities, a probability threshold of 0.80 and mandatory human approval solely to exercise the branches. Those values are not recommendations, Google defaults, customer settings, detection results or performance benchmarks.

The core terminal logic is small:

if (!eligible) return "INELIGIBLE";
if (!observable) return "UNOBSERVED";
if (!analysisEnabled) return "READY_TO_ENABLE_SHADOW";
if (!policy || labelsIncomplete) return "NEEDS_LABEL";
if (queueUnowned || approvalMissing) return "REVIEW_REQUIRED";
if (!findingCrossesOrgPolicy) return "SHADOW_ACCEPTED";
if (responseScope !== "subsequent-only") return "REVIEW_REQUIRED";
return "AUTHORIZED_NEXT_TURN_STOP";

The evaluator proves policy ordering, not Google's service, detection quality or operational readiness. In a production implementation, bind every decision to the current agent revision, session, policy version, finding, actor and expiry. Reject stale decisions.

The terminals are deliberately explicit:

• INELIGIBLE: preview access, runtime, version, region, analytics or reader permission is wrong.
• UNOBSERVED: the agent lacks the telemetry required for analysis and reconstruction.
• READY_TO_ENABLE_SHADOW: prerequisites pass, but enforcement remains disabled.
• NEEDS_LABEL: the business does not yet have enough reviewed evidence for its own policy.
• REVIEW_REQUIRED: ownership, queue state, approval or response scope is unresolved.
• SHADOW_ACCEPTED: the session remains observational under the current organization-defined policy.
• AUTHORIZED_NEXT_TURN_STOP: a named owner approved a narrow later response under a versioned policy.

No terminal claims the current tool call was prevented. That is the most important invariant in the model.

Keep preview drift in the release record

This product is currently a private preview governed by Pre-GA terms. Google says approved, signed-in users need an allowlisted email, and its overview links to an access request.

During this research pass on October 18, the overview's linked usage page returned an HTTP 404. The overview itself was live and had been updated on October 16. That may be a temporary documentation move, access boundary or preview inconsistency. It is not evidence that the product is unavailable.

It is evidence that the setup surface is still moving.

Record the exact documentation URLs, access approval, API version, ADK version, region behavior and response integration used by the pilot. Recheck them before each release. Avoid hiding preview assumptions in infrastructure that will be difficult to unwind.

Google's announcement also says custom business logic is coming soon. Treat that as a roadmap statement, not a current control. Keep the business policy outside the detector until the capability is documented, available to the account and tested against retained traffic.

Shadow-mode release checklist

Before enabling analysis:

• Private-preview access is approved for the intended account.
• The agent runs on Agent Runtime with a supported ADK Python version.
• Logging and observability regions match the documented pattern.
• Scanner identities have only the required reader access.
• Log Analytics and Observability Analytics are enabled.
• OpenTelemetry logs and traces contain the required session and tool context.
• Raw prompt and response capture has a documented data classification, retention rule and access owner.
• A bounded synthetic session proves active telemetry flow.
• Application evidence joins to authoritative downstream state.

Before any enforcement:

• Findings have run in shadow mode.
• Reviewers have labelled true positives, acceptable exceptions, false positives and incomplete evidence.
• Known test attacks and ordinary sessions have been sampled for missed findings.
• The organization has written its own threshold and impact policy.
• Security Command Center routing reaches a named owner.
• Review capacity and queue age are visible.
• Each response is scoped to a subsequent tool call, next turn, agent revision or credential.
• Human approval is bound to the finding, policy version and expiry where required.
• The response writes its own receipt and is verified against the authoritative system.
• Rollback and re-enable authority are named.

The honest release decision is narrow: this agent revision is eligible for shadow analysis under this telemetry and review contract. Later, evidence may justify one bounded response. It does not justify replacing inline authorization with an asynchronous detector.

Google Agent Anomaly Detection FAQ