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. Two categories of control — identity/authorization and gateways — sit at the outer edges of that sequence, where the agent crosses into something that exists independent of it. Hooks are what reaches into the middle.

Figure 1 · The agent lifecycle

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 — every documented case above was mitigated once the right control was enabled, and 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.

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.