All Hooks, No Anchor: AI Agent Assurance Needs an Independent Boundary

For centuries, mariners plotted their position using nothing but the ship itself. A skilled navigator could get a heading from the compass, track the speed from the log line, and measure time from an hourglass. With basic arithmetic from those three factors, sailors reckoned where they must be. This is dead reckoning, and it carried ships to the furthest reaches of the globe. It is real navigation, still practiced by seasoned professionals, but it is never used as a primary method in modern times.

There is one thing dead reckoning cannot account for. It cannot see the state of the current, which direction the water is moving, or at what speed. Every instrument reporting the position is bolted onto the vessel, so when the sea pushes the ship off course, nothing on board can report the drift. Correcting the position takes a reference outside the hull, either by visually mapping a coastline or fixing on a star or other body outside the ship. Sailors call this celestial navigation.

AI agent hooks are dead reckoning for coding agents. They are real security controls, and their design and capabilities are improving quickly. They block dangerous commands, change tool arguments, filter results, and enforce rules across a session, making them a key component security teams rely on to safeguard their infrastructure.

But hooks alone cannot provide AI Agent Assurance, for the same reason we cannot rely on dead reckoning alone. The agent invokes the hook, supplies its context, and interprets its answer, so the control moves with the agent being governed, the same way the compass moves with the ship.

Assurance needs a reference the ship does not currently carry, a control and a record outside the thing being audited. Certiv addresses that architectural gap with Scout, an endpoint agent that operates outside the coding agent’s privilege. Security leaders evaluating coding agent governance should be asking these questions. Do enforcement and evidence still hold when the agent changes, the hook fails, or the developer launches something the hooks never saw?

Give hooks credit for what they can do

Hooks have come a long way in the last nine months. Our September 2026 comparison charted a number of substantial extension surfaces. Claude Code has 33 hook events, OpenAI Codex CLI has 12, OpenCode has 21 plugin hook properties, Grok Build has 15, and Cursor has 21 (“the five”). We also briefly surveyed 56 other agents, for a total of 61 in the wild, which is not exhaustive.

We held those five for a deep comparison. The pattern behind them was checked against the wider market of 56 coding agents surveyed. Most of the field of 56 has copied Claude Code’s hook format (PreToolUse/PostToolUse, JSON on stdin, exit-2 to block), and it has become a de facto standard in the long tail of agents. But the more consequential finding is administrative. Of those 56, only eight expose an admin-owned hook tier a developer cannot easily edit or switch off. Everywhere else, the agent being governed can remove the control. Sixty-one agents at sixty-one different capability levels also means a governance program built on hooks is pinned to the weakest shared baseline, because a rule is only portable across harnesses if every one of them supports it. The alternative is very complex software with a lot of exceptions, all running on your endpoint and needing to be updated as the agents change.

Of the five agents we surveyed in detail, each one can block a dangerous tool call, just as every one can implement a stateful “session taint” rule, where after the session reads a sensitive Model Context Protocol (MCP) source, it prohibits outbound email or HTTP. You write the rule and maintain its state, but the capability exists. Just make sure the agent cannot touch that state, because agents are very creative when problem solving, and your block is a problem to be solved. Read Never Corner an Optimizer for more.

All five can rewrite tool arguments before execution. Grok Build is one example, where the documentation bundled with its shipping build, ahead of the out-of-date public docs, describes both argument rewriting and tool-result replacement. All five can also replace or rewrite tool results before the model sees them, with two limits. Codex can only replace a result wholesale, and Cursor limits result rewriting to MCP results.

OpenCode goes especially deep. Its in-process plugin can read and rewrite the system prompt and message array. Cursor uniquely exposes the model’s thinking text through a hook among these five, which provides useful context for observation. These are all useful features, but the differences make it difficult to establish a common feature set that spans all five.

Claude Code offers the strongest native approval dialog in this comparison, including approvals that carry an edit, and it can lock hooks through a root-owned, MDM-controlled /etc/claude-code/managed-settings.json, much like Codex’s requirements.toml. Codex has the strongest native enforcement story, with its root-owned requirements.toml, mobile device management (MDM), trust pinned to hook-definition hashes, and networking disabled by default in its sandbox. Those are meaningful administrative controls (see Codex security for more).

A credible AI runtime security evaluation starts by looking at strengths. The evaluation is not done until it figures out where authority ends, and that is where the structural gaps begin.

Six structural gaps remain

1. Entry points leave gaps at the send boundary

A hook can catch a secret when someone pastes it or when a tool result arrives. That does not establish what leaves in the assembled model request.

Most of these hooks do not expose the assembled request. A credential already in conversation history, CLAUDE.md, an @-file, or the system prompt can therefore escape an entry-point check. OpenCode’s access is an interesting exception, as it exposes the system prompt and message array.

Consider a session that begins with an instruction file containing a credential. A perfect scanner attached to newly submitted prompts still misses it if that instruction file never crosses the scanner’s event. The decisive inspection point is after assembly and before transmission, which, of the five, only OpenCode provides.

2. The native approver is the person at the keyboard

Every native dialog, and every hook “ask”, puts the question to the developer running the agent. That is the right person for developer consent. It is the wrong person when policy requires someone else, a production owner, a security reviewer, a designated approver, or an external system that attests a human decided. Agents are smart, and if you provide a local means of approval, they can figure out how to self-approve if sufficiently motivated.

Routing an action to another person or app means building an approval service and a hook that holds the call while it polls. None of the five harnesses has an approval primitive for this. The hook is the approval, so its wait is bounded by the hook timeout, the approver’s identity is whatever the hook chose to record, and if the hook dies while waiting the call proceeds. A dialog can be excellent and still be asking the wrong person, and a local dialog can be answered by an agent if it is sufficiently motivated.

3. The process under audit writes the record

Each harness keeps a transcript in a developer-owned location and has ways to disable or delete recording. A sufficiently motivated or confused agent can delete its own transcript. Those transcripts are valuable for debugging and reconstruction, but they are not independent evidence.

Exporting hook events improves retention, but it does not change who produced the account, and some harnesses export only metadata rather than the full record. Hooks record what the harness reports about itself, while a proxy on the wire records what the agent actually sent and received. That distinction is what an investigator needs when evaluating a suspected disclosure or reconstructing a disputed action.

4. Each hook governs its own agent

A Claude Code hook governs Claude Code. It cannot discover an engineer running another coding agent on a personal API key (a policy some of our customers enforce with rigor). That same scope boundary applies to all five on our list above. An unsanctioned agent can sit outside the hook deployment entirely, regardless of how sophisticated the approved agent’s policy is.

For example, DeepSeek Harness (dsh), launched August 2026, currently ships no hook configuration, instead using plugins similar to (but not the same as) OpenCode, yet does most things Claude Code and Codex do, and needs governance.

There are places where it will be very hard to put any governance. Fully cloud-hosted agents (like Jules, Replit Agent, Ona, Lovable, Bolt) expose no local surface at all, neither a hook to set nor a process on the endpoint to observe. Governing those is a separate problem from the one this piece addresses.

Coding agent governance must follow the process actually making the request. A policy installed in one approved application cannot establish that coverage.

5. Configuration remains specific to each harness

Claude Code, Codex, Grok Build, and Cursor support administrative locking through managed settings or MDM. OpenCode cannot centrally remove a plugin added by a repository, and a checkout’s plugin directory can execute on open without a trust prompt.

Repository hooks also create a supply-chain surface. For instance, Cursor ships with workspace trust off. Grok Build reads .claude and .cursor hook files along with its own, although its documentation requires trust for project hooks. Compatibility expands the configuration surface administrators must inspect. A common pattern among the 61 agents is reading Claude Code’s hook file straight out of a checked-out repository, automatically. A repository can therefore carry hook code that executes against a developer who never opted into it.

6. Protecting against agent tampering and agent bugs

Without endpoint security protecting the deployment, a hook-only setup remains vulnerable to the agent or user undoing the hooks. Managed configuration helps, but its protection and coverage vary by harness. Put plainly, a hook without endpoint security behind it is not a product, it is a suggestion, and the agent is happy to ‘un-suggest’ it just as easily as it ignores your CLAUDE.md.

A bug in a hook harness that makes it bypassable would unravel the security for that agent. We identified one such bug in our evaluation. Agents are perfectly capable of doing this for themselves if sufficiently motivated, and being blocked is strong motivation.

The security of the hook frameworks depends on a lack of bugs in that framework from that vendor. There are 61 agents we surveyed, and they update their code daily without your knowledge or gate.

Compare outcomes, not event counts

Our scorecard reflects the capability comparison we analyzed, including native administrative controls. In the chart below, “Yes” means the outcome can be implemented (and does not imply secure defaults). “Mostly” means substantial entry-point coverage with assembled-request gaps. “Partial” means useful support without the complete independent outcome.

Governance outcome	Claude Code	Codex CLI	OpenCode	Grok Build	Cursor	Certiv
Block a dangerous tool call before it runs	Yes	Yes	Yes	Yes	Yes	Yes
Stop a secret leaving in a model request	Mostly	Mostly	Yes	Mostly	Mostly	Yes
Route a high-impact action to an approver who is not the user	Partial	Partial	No	Partial	Partial	Yes
Find and govern an unsanctioned agent	No	No	No	No	No	Yes
Reconstruct a session from a record the developer cannot edit	Partial	Partial	Partial	Partial	Partial	Yes
Forbid dangerous launch flags org-wide	Yes	Yes	No	Yes	Yes	Yes

Put enforcement and evidence outside the agent

So how does Certiv measure up? Scout runs on the endpoint, outside the agent’s trust boundary. It sees the whole assembled request and the whole response on the wire for any agent process, extending coverage beyond a single harness. Scout is that wire-level control running on the endpoint, where it terminates the actual traffic locally rather than trusting the agent to report itself. It is one control point, not a separate proxy and endpoint agent.

That position enables pre-execution policy enforcement on the model’s tool call before the harness executes it. Scout applies four verdicts: allow, block, steer, or pause for a human approver who need not be the user.

Shell egress, subagent spawns, and file actions are governed as ordinary tool calls. The policy decision happens before the harness turns the model’s requested action into execution.

Scout also redacts secrets from the assembled request before it reaches the provider. That inspection includes the content being sent, rather than relying solely on earlier events to have exposed every sensitive value.

Each call is attributed to an OS-verified process identity. Scout enables an independent record the developer or agent cannot edit, and exports alerts to the SIEM. Some emerging standards are calling for fail-closed, and fail-closed is available from Certiv.

These capabilities place authority and evidence outside the agent while preserving the coding workflow.

Hook as an actuator, Certiv as the authority

Hooks remain useful in this architecture. A managed hook can supply more context about a workflow and present a native user experience, and it can explain a decision where the developer is already working. The wire needs to remain the enforcement floor.

That division gives platform engineers a practical integration pattern. They can use hooks for context and interaction, with independent enforcement for the request and response crossing the boundary.

For an agent hooks security evaluation, consider testing both halves. Confirm that the hook provides the expected context and dialog. Then confirm that governance still holds when the handler times out or a different agent makes the request. More hook events can improve the experience without becoming the foundation of trust.

Watch endpoint security paired with hooks

Hooks without endpoint security are a suggestion that an agent would trivially undo with a file change, the type of action it takes hundreds of times per day. So any solution you look at needs endpoint security. It needs to support MDM install, and it needs to block modifying any configuration, script, or application file involved in the hooks. Some of these hooks live in the user’s home directory rather than a system directory, which makes managing them more complicated.

Even so, endpoint security paired with hooks still does not, by itself, provide the assembled request, the full response, coverage of agents that have no hooks, or a record the harness did not write.

How often do you want to update your client software?

Adding support for a new harness through hooks means tracking that harness’s own software and its reading of the hook format. Many vendors ship updates daily, so there will be daily interoperability testing and an update to the endpoint software if something breaks. You have to do this with the five most popular agents, plus the tail of 56 that you may or may not want to support.

Adding support for a new agent by capturing the wire traffic on the endpoint usually means learning one more application-layer framing (NDJSON, SSE, gRPC), and that set rarely grows because almost nobody invents a new one.

For example, when Grok Build decided to strictly enforce the OpenAI wire spec (unlike Codex, which is more forgiving), Scout needed no change. All the changes were made in Certiv Sage, the cloud backend that defines whether Scout intercepts LLM traffic, because Scout only needs to understand the framing.

Another example was OpenCode and Kimi K3 on Baseten. No Scout changes were required to support this combination. The wire protocol and interception points were all defined in Certiv Sage. Scout is data-driven, and picked up the new combination with zero code changes.

The work that framing-level coverage requires tends to be future-proof in a way that per-harness plumbing is not.

Conclusion

Dead reckoning got ships across oceans, and hooks will keep getting better at what they do. But no navigator can place unquestioned trust in an instrument bolted to the hull. That took a fix from something the ship did not carry. Even centuries later, we are still learning where the current runs strongest. If you are running coding agents today and want to know what is actually crossing the wire, which process sent it, and whether your policy holds when the hook does not, reach out here and we will show you what Scout sees.

FAQ

Are AI agent hooks security controls? Yes. AI agent hooks can block tool calls, modify arguments, and enforce stateful session rules. Their effectiveness depends on event coverage, failure behavior, and protection of the hook deployment.

Are Claude Code hooks enough for coding agent governance? Claude Code hooks alone do not provide governance across agents or independent evidence. They offer valuable controls within Claude Code, including tool-call blocking and approval flows.

Can hooks stop secrets from reaching a model provider? Hooks can stop secrets they inspect, but entry-point checks do not guarantee coverage of the assembled model request. OpenCode exposes the system prompt and message array; independent inspection at the send boundary addresses the broader architectural requirement.

How does Certiv work with hooks? Certiv provides independent authority by finding the actual truth of what is happening, intercepting the network traffic and monitoring processes on the endpoint. Scout inspects assembled requests and responses, governs model tool calls before execution, and keeps an independent record. Fail-closed is available. Hooks can supply context and native interaction, and we use them as customer needs dictate.