Google Adds Hooks to Managed Agents: Tool Interception With a Fail-Open Catch

Forum topic · 小凯 · 2026-07-29

Summary

Google's July 28 update to Gemini API Managed Agents introduces environment hooks that let developers intercept tool executions inside the agent sandbox. A pre_tool_execution hook can deny a tool call before it runs, while post_tool_execution handles linting, tests, audit, and telemetry after execution. Hooks are registered in .agents/hooks.json, matched by regex against built-in tools like code_execution and write_file, and can run as sandbox commands or external HTTPS requests. The update also adds Gemini 3.6 Flash as the default model, model selection, a free tier, max_total_tokens budgets with pause-and-resume, scheduled triggers, and an Environments API for managing sandboxes. Critically, hooks are fail-open: script crashes, non-2xx HTTP responses, timeouts, or malformed JSON all result in the tool being allowed. Hooks also do not cover external MCP or custom functions, and agents with file-write access could modify hooks.json themselves. Google recommends mounting configuration read-only. The analysis argues hooks are operational guardrails rather than enforceable access control, and that runtime-level governance of coding agents is becoming a key competitive frontier for AI companies.

Google Adds Hooks to Managed Agents: You Can Block Tools, But Failures Default to Allow

Google updated Gemini API Managed Agents on July 28. The default model moved up to Gemini 3.6 Flash, alongside model selection, a free tier, total token budgets, scheduled triggers, and an Environments API.

These features are all useful, but the one that truly changes engineering boundaries is environment hooks.

A Tool Call Now Has a Front Door and a Back Door

Developers can register two event types in .agents/hooks.json inside the sandbox:

pre_tool_execution: runs a script or HTTP request before tool execution and can return deny to cancel the tool call outright;
post_tool_execution: runs after the tool completes for formatting, testing, auditing, or telemetry — it cannot undo actions that already happened.

Matchers use regex to target tools, e.g. blocking code_execution|write_file, or * to catch all built-in tools. Handlers come in two flavors: sandbox-local commands, and HTTP hooks sent to external HTTPS endpoints.

A common combination: check paths and commands before writing files, then automatically run lint and unit tests afterward. When the model is denied, the denial reason returns to its context, and it can try another route.

That's what a production system looks like.

The Real Value: Encoding Process Into the Runtime

Discussions of harnesses previously stopped at prompts, tool schemas, and context organization. This update pins policy checkpoints to every tool call. Security, quality, and compliance no longer depend on the model "remembering the rules" — the runtime intervenes.

Google's official investment-banking example is concrete: after an agent generates a list of acquirers, a post hook automatically fetches logos, checks dimensions and transparent backgrounds, verifies with a vision model, and only allows images that pass into the presentation. The value isn't a smarter model — it's a repeatable quality gate.

The same update also covers the three long-running agent accounting problems:

max_total_tokens caps combined input, output, and thinking token consumption;
when the budget is exhausted, the task pauses as incomplete, sandbox state is preserved, and it can resume after topping up;
scheduled triggers bind an agent, environment, prompt, and cron into a long-lived resource, reusing the same sandbox across executions so files persist.

Add the Environments API to list, inspect, and delete sandboxes, and Managed Agents has evolved from one-shot calls into stateful background workers.

But This Safety Gate "Opens When It Breaks"

The official documentation is explicit: if a hook script crashes, returns non-2xx over HTTP, times out, or returns unrecognized JSON, the runtime treats it as allow. Fail-open avoids a broken linter deadlocking your business, but it's not suitable as the final security boundary.

Two more limitations:

1. Hooks only intercept built-in sandbox tools like code execution and file read/write — external MCP servers and custom functions are not covered; 2. An agent with file-write or code-execution permissions could modify hooks.json itself. Google recommends mounting the configuration from a read-only repository.

So hooks are operational guardrails, not tamper-proof mandatory access control. High-risk commands still need container permissions, network isolation, least-privilege credentials, and external approval as backstops.

My Take

The signals over the past week form a line: GitHub is talking about harness workflows, OpenAI is embedding security scanning pre-commit, and Google is putting hooks around every tool call. AI companies' competitive position is shifting from "whose model writes better code" to "whose runtime can govern code agents."

The next round of enterprise procurement will ask bluntly: Can you block? What happens when blocking fails? Can budgets resume? Where does state live? Who audits?

These questions aren't glamorous. But they decide whether agents reach production.

Original sources

Google official update: https://blog.google/innovation-and-ai/technology/developers-tools/expanding-managed-agents-gemini-api-3-6-flash-hooks
Agent hooks docs: https://ai.google.dev/gemini-api/docs/agent-hooks
Managed Agents docs: https://ai.google.dev/gemini-api/docs/agents