A policy check that disappears during an outage is useful guidance. It is not a security boundary.
Google has added Gemini Managed Agent hooks for inspecting sandbox activity before or after selected tool calls. A pre-tool hook can deny code execution or a file operation before it runs. That sounds like the right place to enforce policy—until you read the failure behavior.
If a hook crashes, times out, returns a nonzero exit code, produces a non-2xx HTTP response, or sends unrecognized JSON, the action is allowed. Google documents this explicitly. Builders should treat the feature as a fast policy layer inside the agent loop, not as the final lock on production data or infrastructure.
The important default is allow
The hook contract accepts a deny decision from a recognized response. Most other outcomes continue the tool call. That choice favors availability: a broken policy service does not halt every managed-agent task. It also creates a predictable bypass condition.
When the check is unavailable, the highest-risk action should not inherit the most permissive result.
The risk is not theoretical. A slow network policy endpoint, malformed response, dependency failure, or exhausted hook process can all turn a rule into an allow. If the tool holds credentials or can publish, delete, deploy, or contact a real person, that is the wrong layer to carry the entire decision.
Pre-tool and post-tool hooks solve different problems
| Hook | Useful for | Hard limit |
|---|---|---|
| Pre-tool | Inspecting and denying a covered action before execution | A hook failure allows the action |
| Post-tool | Logging results, checking output, and producing follow-up context | The original side effect has already happened |
A post-tool check can flag a bad result, but it cannot make an external message unsent or restore a deleted file. Use post-tool hooks for evidence, anomaly detection, and recovery triggers. Put preventive controls before the real side effect.
The current coverage has important gaps
Google’s documentation limits the current hooks to built-in sandbox code execution and file operations. Custom functions and external MCP tools are not covered. A team can therefore build a careful policy around local shell activity while leaving an external deployment, database, messaging, or ticketing tool on a different path.
Inventory every consequential tool instead of assuming the word “hook” means universal interception. Our analysis of Claude inference hooks reaches a similar operational lesson: policy coverage and policy availability both belong in the design review.
Do not let the agent rewrite its own guardrail
Gemini Managed Agent hooks are configured through files and executable scripts. Google warns that an agent with filesystem or shell access may modify them. The practical fix is simple: keep the configuration and hook code outside the writable workspace, mount them read-only, and verify their hashes before a run starts.
- Separate ownership: the deployment pipeline, not the agent, writes policy files.
- Pin dependencies: a surprise package update should not change the decision path.
- Record decisions: log the requested tool, normalized arguments, rule version, result, latency, and failure reason.
- Test failure modes: kill the hook, delay it, return bad JSON, and confirm the outer boundary still holds.
Build a two-layer control plane
Use the hook as the first, fast layer. It can explain a denial to the agent, prevent ordinary mistakes, and attach useful context. Put the non-negotiable layer outside the managed sandbox: scoped credentials, network allowlists, read-only mounts, deployment approvals, transaction limits, and infrastructure policy.
The outer layer should default to deny for high-impact actions when it cannot evaluate the request. That is the control that must survive a hook outage. Our report on AI cyber-test containment incidents shows what happens when written scope and reachable infrastructure disagree.
A rollout test worth running
- Choose one reversible, low-risk sandbox action and one consequential external action.
- Confirm the pre-tool hook blocks the covered sandbox action with a valid deny response.
- Make the hook time out and confirm that the external boundary still blocks the consequential action.
- Attempt to edit the hook configuration from the agent workspace.
- Review the log and verify that an operator can reconstruct both decisions.
If step three fails, the hook has become a single point of policy failure. The permissions framework in our plain-English guide to agentic AI can help separate a model’s instructions from the capabilities the environment truly grants.
My verdict: enable hooks, distrust their availability
Gemini Managed Agent hooks are valuable. They add a clear place to inspect covered tool calls and give teams a programmable policy surface. The feature becomes dangerous only when a fail-open extension is mistaken for a fail-closed boundary.
Keep the hook small, observable, and read-only. Then make credentials, egress, and infrastructure enforce the rule that cannot be skipped. The safest question is not “does the hook deny this?” It is “what happens when the hook is gone?”
Read the primary documentation
- Read Google’s Gemini Managed Agent hooks documentation.
- Review Google’s Managed Agents and hooks announcement.
- Check the Antigravity managed-agent documentation.
Which action in your agent stack still runs when its policy service times out?
Checked August 10, 2026. Hook events, failure behavior, coverage limits, and writable-file warnings come from Google’s current documentation.
