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: the outer boundaries where an agent crosses into something that exists independent of it. Both are established, well-understood, and address real risk. Neither says much about what happens between those edges: what the agent was told to prioritize, what context shaped its decision, why it selected one tool over another. That’s the gap hooks are built to close. 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 — Claude Code and the Claude Agent SDK call this PreToolUse, the OpenAI Agents SDK’s on_tool_start and tool guardrails work the same way — can still change the outcome: deny it, modify it, or hold it for approval. A hook that fires after — 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, not audited after. This sounds obvious stated plainly, but it’s a common gap in practice: 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 — useful for audit and forensics, but not a control.

Are hooks themselves a security risk?

Yes, in a specific and worth-understanding way: 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 — 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 both are useful less as isolated bugs than as an illustration of the pattern: 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: 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” — a case where a platform states outright that the safety property depends on the deployment choice a team makes, not 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; separate research has described techniques aimed specifically at circumventing human-approval checkpoints, not just 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 — publishing 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. 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 — so 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. It’s a reason to treat a hook as one layer, not the whole answer: 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 finding worth sitting with is not the autonomy figure but the one next to it: 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.

Put together, these point somewhere specific. 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 not more approval prompts but automated enforcement of a policy the organization has already decided on. The interesting use of a hook, then, is not as a way to summon a human into every decision, but as the place where a decision the organization already made gets applied consistently without anyone being summoned at all.

This is a directional claim rather than a settled one. Human-agent interaction isn’t going anywhere, and there are actions that should always stop for a person. But 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: 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: an action group can be configured to return a proposed function and its parameters to the calling application instead of auto-executing — a genuine pre-execution interception point, but 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.