Agent Lifecycle Hooks

Where do hooks sit in the agent lifecycle?

Every agent, regardless of harness, moves through a broadly consistent sequence from instruction to action:

1. Design-time and system prompts: how the agent’s baseline instructions, role, and constraints are set before it ever runs
2. User input: what the agent is asked to do, and by whom
3. Memory and context: what the agent carries forward, retrieves, or is given as working state
4. Tool calls and their context: what the agent invokes, with what arguments, and what it’s told about why
5. Identity and authorization: what the agent is allowed to access, and under whose credentials
6. Runtime decisions: the points where the agent actually chooses its next action
7. User feedback: where a human reviews, corrects, or approves what the agent has done or is about to do
8. Gateways: the network or API boundary where the agent’s traffic exits toward tools, data, or the outside world

Figure 1 · The agent lifecycle

Hooks are the mechanism that reaches into the middle of that sequence, not just its edges. Two categories of control (traffic or tool gateways, and identity and authorization) sit at stages 5 and 8, which are the outer boundaries where an agent crosses into something that exists independent of it. Both are established and well understood, and both address real risk, but neither says much about what happens between those edges, such as what the agent was told to prioritize, what context shaped its decision, or why it selected one tool over another. Hooks are built to close that gap, since a hook that fires on every tool call, every prompt, or every compaction event is present at a stage no boundary control reaches on its own.

What’s the difference between a hook that fires before an action and one that fires after?

This is the single most consequential design choice in how a hook is used. A hook that fires before an action, which Claude Code and the Claude Agent SDK call PreToolUse and which the OpenAI Agents SDK’s on_tool_start and tool guardrails mirror, can still change the outcome by denying it, modifying it, or holding it for approval. A hook that fires after, such as PostToolUse in Claude Code or an audit log in general, can only record what already happened.

Figure 2 · Before vs. after

Anything that must never happen needs to be caught before it executes rather than audited afterward, and although that sounds obvious stated plainly, it’s a common gap in practice, because a team sets up logging on every tool call, sees that as “coverage,” and only later realizes logging tells you what went wrong, not that it stopped it from going wrong. The credible pattern across every platform that documents this well is to treat the before-action hook as the enforcement point, and the after-action hook as evidence, which is useful for audit and forensics but is not a control.

Are hooks themselves a security risk?

They can be, in a specific way, because a hook is code, configured by a team, and it inherits whatever trust boundary that configuration sits inside. Two documented cases make this concrete. A vulnerability tracked as CVE-2025-59536 allowed repo-defined MCP configuration to execute shell commands on tool initialization without explicit consent, which was a trust-boundary gap in when consent was actually enforced relative to when code could run. A related issue, CVE-2026-21852, allowed a malicious repository to redirect API traffic, including leaking API keys, before the trust prompt was even shown. Both were patched, and what makes them useful is the pattern they illustrate, which is that a hook or a permission check is only as trustworthy as the boundary condition around exactly when it fires relative to when the thing it’s meant to gate can actually run.

The other side of this is explicit rather than accidental, since permissive modes that skip hook enforcement entirely are typically documented with a plain warning rather than hidden. Anthropic’s own documentation flags bypassPermissions mode as granting full system access and states it should be used “with extreme caution,” which is a case of a platform stating outright that the safety property depends on the deployment choice a team makes rather than on default behavior.

Can a hook be bypassed by prompt injection?

This is the more structural limitation, and it shows up consistently across platforms rather than being specific to any one of them. A hook that fires based on what the model decided to do is only as trustworthy as the context that produced that decision. Independent security research has demonstrated this pattern in more than one setting. A four-stage attack against a multi-agent supervisor architecture extracted system instructions and tool schemas through inter-agent messaging, and separate research has described techniques aimed specifically at circumventing human-approval checkpoints rather than only at unauthorized data access. One major agent vendor has stated directly, in its own published research, that prompt injection against browser and computer-use agents may not be fully solvable, and has published a concrete internal case where a malicious email with hidden instructions caused an agent asked to draft an out-of-office reply to instead send a resignation letter to the user’s CEO.

None of this is a reason to skip hooks, since the two CVEs were patched, and in the multi-agent case the researchers themselves found that enabling the platform’s prompt-attack guardrail stopped the attack chain they had demonstrated, which means the controls did their job once they were switched on. The browser and computer-use case is the genuinely unresolved one, and it’s worth not smoothing that over. A hook the model can be talked out of triggering is still a meaningfully stronger guarantee than no interception point at all, but the unresolved case is a reason to treat a hook as one layer rather than the whole answer, because a control living entirely inside the model’s own context carries a different kind of risk than one enforced independent of the model’s own reasoning, and a mature posture typically draws on both.

Do hooks replace human approval, or enable it?

The default assumption in most agent governance writing is that a human approval step is the strongest available control, and that hooks exist to create more of them. That assumption is worth questioning, because the evidence on approval capacity is not encouraging.

Anthropic’s own disclosure of GTG-1002, a state-linked actor that jailbroke Claude Code for cyber-espionage against roughly thirty organizations, reported 80 to 90% autonomous operation with human review at only four to six decision points per campaign. The more telling finding is the one reported alongside the autonomy figure, that attack request rates explicitly exceeded human review capacity. Separately, independent research has documented prompt-injection techniques aimed specifically at circumventing human-approval checkpoints rather than at data access, which means the approval step is itself a target.

Taken together, these suggest that a human approval gate is not a control that scales with agent volume, and at enterprise scale it becomes the thing that either bottlenecks operations or gets routed around. What most security teams actually want from a hook is automated enforcement of a policy the organization has already decided on rather than more approval prompts, so the more interesting use of a hook is as the place where that decision gets applied consistently, without a human being summoned into every decision.

This is a directional claim rather than a settled one, and human-agent interaction isn’t going anywhere, since there are actions that should always stop for a person. Even so, human-in-the-loop as the primary governance mechanism looks increasingly like a transitional stage rather than the destination.

How do hooks compare across major platforms?

The specific mechanisms vary in name and maturity, but the shape is consistent, in that every major harness has built real, documented interception points, and in every case they’re opt-in per tool or per action rather than a default posture of reviewing everything before it happens.

• Anthropic documents 31 hook events spanning session lifecycle, per-turn processing, tool execution, subagents, and context compaction, with PreToolUse and the canUseTool callback evaluated first in the permission pipeline, ahead of static allow/deny rules.
• OpenAI’s Agents SDK fires RunHooks/AgentHooks around every model call, tool call, and agent handoff, with a documented approval model that pauses and serializes run state pending human review.
• Amazon Bedrock’s closest equivalent is Return of Control, in which an action group can be configured to return a proposed function and its parameters to the calling application instead of auto-executing, which gives a genuine pre-execution interception point that is opt-in per action group rather than default.
• Microsoft exposes three named custom triggers in Copilot Studio and per-tool approval gating in Azure AI Foundry, each requiring deliberate, per-topic or per-tool configuration rather than a global checkpoint.