Every major AI agent platform now ships some version of hooks – lifecycle interceptors that fire before or after tool calls.
Cursor has hooks.json. Claude Code has .claude/settings.json. Gemini CLI has settings.json with BeforeTool and AfterTool events. The OpenAI Agents SDK has InputGuardrail, OutputGuardrail, and ToolGuardrail. LangChain has callback handlers wired to on_tool_start.
The platforms built hooks for legitimate developer purposes, including workflow automation, context injection, and observability.
But security vendors and enterprise teams risk overstating that role when they present hooks as a substitute for access controls. Hooks alone do not provide a complete identity and access enforcement layer, and treating them as though they do creates a false sense of coverage.
What Hooks Actually Are
Hooks are middleware — scripts or functions that intercept an agent’s tool calls at specific lifecycle points. A pre-tool hook runs before the agent invokes a tool. A post-tool hook runs after. The hook can inspect arguments, block execution, log the event, or modify the output. The implementations differ across platforms, but the pattern is the same everywhere:
Cursor uses hooks.json files at three levels: project (.cursor/hooks.json), user (~/.cursor/hooks.json), and enterprise (system-level, deployed via MDM). Hooks are shell commands that receive a JSON payload on stdin and return JSON on stdout. Lifecycle events include beforeShellExecution, afterShellExecution, beforeMCPExecution, afterMCPExecution, plus events for tool use, file access, subagents, and session start/stop.
Claude Code uses .claude/settings.json at four scopes: user, project, project-local, and managed policy (enterprise, admin-controlled). Hooks fire synchronously — the agent pauses while the hook runs, then continues based on whether it returns allow or deny. Enterprise admins can enforce allowManagedHooksOnly to lock out developer-configured hooks.
OpenAI Agents SDK uses Python or TypeScript classes rather than config files. InputGuardrail validates user input before the first agent runs. OutputGuardrail validates the final agent’s output. ToolGuardrail (input and output variants) wraps individual tool calls with pre- and post-execution checks. A needsApproval flag on tools pauses execution for human review. These are SDK-level constructs — they exist in the application code, not in a config file the platform reads.
LangChain / LangGraph uses callback handlers — AsyncCallbackHandler subclasses that fire on events like on_tool_start and on_tool_end. LangGraph adds interrupt() for human-in-the-loop approval. Third-party wrappers from vendors like Arcjet, Noma, and AgentGuard bolt onto these callbacks to add policy enforcement.
Gemini CLI uses settings.json hooks with BeforeTool and AfterTool events. Hooks are shell scripts that execute with the user’s full privileges. Exit code 0 means allow, exit code 2 means deny. Google also offers a separate Python callback system in the ADK (BeforeToolCallback, AfterToolCallback) for developers building agents programmatically.
Gemini CLI hooks come closest to acknowledging the boundary between hooks and identity. Google layers hooks on top of its own IAM and Application Default Credentials – the hooks handle behavioral checks while Google’s identity layer handles access.
But even Google Cloud’s architecture has limits. It works well when you’re wholly contained within their cloud. It breaks down as soon as agents need to cross trust domains – accessing another cloud provider, calling a third-party SaaS API, or reaching on-prem resources. Those cross-boundary connections still require credentials that Google Cloud IAM doesn’t manage, and the hooks can’t bridge that gap. Every other platform doesn’t even get this far – they leave the identity layer entirely as an exercise for the implementer.
Seven Things Hooks Structurally Cannot Do
1) Be required. No platform mandates hooks. Cursor, Claude Code, Gemini CLI, the OpenAI Agents SDK, LangChain – every one of them treats hooks as opt-in. There is no enforcement mechanism that prevents an agent from running without hooks configured. A developer can skip them entirely – and most do. Your entire security posture depends on every developer, on every project, choosing to configure hooks correctly. That is the definition of a suggestion. Infrastructure-layer identity is the opposite: The agent cannot access a resource unless the identity platform issues a credential. Unlike hooks, there is no opt-out. Access enforcement should be the default, not a configuration choice.
2) Issue or eliminate credentials. Every hook implementation operates downstream of credential provisioning. The agent already possesses an API key, OAuth token, or service account credential. The hook tries to govern how that credential is used. It cannot change whether the credential exists, how long it lives, or how broadly it is scoped.
3) Keep credentials out of agents’ hands. Even the best integration – 1Password brokering secrets to Cursor via hooks – still involves a stored secret that the agent holds at runtime. If the agent is compromised, the credential is in memory. Hooks can scan for secrets in output, but the secret is already inside the agent’s process. Secretless access eliminates this entirely: The agent authenticates via workload identity, a short-lived token is brokered for a single action, and the agent never possesses a reusable credential. There is nothing to steal.
4) Survive their own exploitation. CVE-2025-59536 (CVSS 8.7) turned Claude Code’s hook configuration into a remote code execution vector – malicious hooks injected into .claude/settings.json ran shell commands before the trust dialog appeared on screen. CVE-2026-21852 enabled API key exfiltration via environment variables. A separate attack chain demonstrated persistent OAuth token theft through npm postinstall hooks that silently rewrote MCP server URLs. The AgentAuditKit project catalogs 12 distinct Hook Injection patterns. When the enforcement mechanism becomes the attack vector, you have a design problem.
5) Provide organizational governance. Hooks are configured per-project, per-user, or per-machine, without a shared registry or policy engine to enforce consistent configurations across an enterprise. Research has found roughly 3,000 MCP server deployments in a typical 10,000-person organization, most running with no hooks, monitoring, or connection to enterprise identity infrastructure. Each additional platform compounds the problem. A team running Cursor, Claude Code, and Gemini CLI has three hook architectures, config formats, log schemas, and sets of security assumptions, with no shared policy model. A credential blocked by one platform’s hook may still work through another platform’s unhooked path. Centralized access governance requires enforcement that spans those platforms.
And that’s only counting the platforms that support hooks at all. Custom agents running on Kubernetes have no hook layer – they’re containers calling APIs. SaaS-embedded agents (inside CRM, ITSM, or ERP platforms) operate within the vendor’s runtime, where the enterprise has no ability to inject hooks even if they wanted to. The hook model assumes every agent runs inside a supported IDE or CLI. In practice, the fastest-growing category of agents – autonomous backend workloads – runs in environments where hooks simply don’t exist. Infrastructure-layer identity works everywhere a workload runs, regardless of whether the runtime supports hooks.
6) Detect goal hijacking. Prompt injection and goal hijacking manipulate the agent’s intent upstream of where hooks fire. A hijacked agent uses its legitimate credentials and normal API patterns while pursuing attacker-directed objectives. A hook that checks whether a tool call is allowed cannot detect whether the tool call is serving the right purpose. The arguments look normal. The credential is valid. The behavior is malicious.
7) Manage credential lifecycle. Hooks cannot rotate secrets, scope permissions to a single task, expire access after a session ends, or revoke credentials across downstream systems. They are stateless – they see one tool call at a time and have no model of what came before or what should come after.
The Operational Cost
Beyond the architectural gaps, hooks create three day-to-day problems that compound with every new agent deployment.
Developers become accidental access policy designers. Hook configuration is developer-owned by default. The security team doesn’t write hooks.json files or .claude/settings.json scripts. The developer decides which tools to gate, which arguments to scan, and which operations to block.
This is access policy work assigned to people who aren’t trained for it and aren’t incentivized to prioritize it. The predictable result: most developers either skip hook configuration entirely or accept the defaults. Reports show more than 80% of technical teams already run agents while only about 14% have formal security approval.
Security teams lose centralized control. When access governance is distributed across per-project config files on individual developer machines, the security team cannot enforce policy –they can only hope developers configured it correctly. There is no central place to define who can access what, revoke a credential across all agents, or push a policy change that takes effect immediately across the organization.
Visibility matters too – security teams can’t see which agents exist, what credentials they hold, or what tool calls are being made – but the deeper problem is that even if they could see everything, they’d have no mechanism to act on it from a single control point.
Each platform has its own hook format, its own logging model, and its own (or no) audit trail. Cursor hooks log differently than Claude Code hooks, which log differently than Gemini CLI hooks – if they log at all. Infrastructure-layer identity provides the centralized control plane. Every agent identity, every credential issuance, every access decision, and every policy enforcement flows through a single system – regardless of which AI platform the developer uses. The security team defines policy once. It applies everywhere.
Incident response becomes bespoke per platform, possibly per agent. When a credential leaks, the investigation path depends on which platform was involved. A Claude Code incident requires examining .claude/settings.json configs, MCP connections, and Anthropic API logs. A Cursor incident requires examining hooks.json, vault access patterns, and Cursor telemetry.
A LangChain incident requires tracing which callback handlers were wired in and which tools were wrapped. Each platform has different log formats, different config schemas, different attack surfaces, and different remediation steps. There is no shared forensic model. Credential revocation means editing config files on individual developer machines – not a single centralized action.
What Hooks Are Good For
Hooks were built for developers, and they do that job well:
- Context injection: Pull git history, Jira tickets, or project metadata into the agent’s session automatically
- Coding standards: Enforce linting rules, formatting conventions, and style guides on generated code
- Observability: Log every tool call, LLM invocation, and agent handoff to a SIEM or tracing system
- Cost control: Meter API usage, enforce token budgets, and block runaway agent loops before they spike bills
- Workflow automation: Chain pre- and post-action steps that would otherwise require manual configuration
These are practical, useful capabilities that make agents easier to operate. They are what hooks were designed for.
You can also try to use hooks for security actions. They can block dangerous tool arguments at runtime – catching a DROP TABLE before it executes. They can scan output for leaked credentials or PII. They can pause an operation and require human approval. They can produce per-tool-call audit records. They can scan for prompt injection patterns. These are behavioral checks, and behavioral checks have a place in a security architecture.
The problem is that none of these capabilities address the seven structural gaps above. They require your developer to actually implement them (gap 1). They can scan for secrets in output, but they can’t eliminate the credential from the agent’s runtime memory (gap 3). They can log tool calls, but they can’t provide centralized policy or governance across platforms (gap 5). They can block one suspicious action, but they can’t detect a hijacked agent using valid credentials for the wrong purpose (gap 6). Behavioral checks are the finish on a security architecture – they are not the foundation.
What Access Enforcement Actually Looks Like
The alternative to hooks-as-IAM is an identity-first architecture where access decisions happen at the infrastructure layer – before the agent’s code runs, before any hook fires, and independent of which AI platform the developer chose.
1) Cryptographic, first-class agent identity. Each agent has a verifiable identity – a cryptographic assertion of what this agent is, not just what project directory it lives in. The identity is issued at invocation time and bound to policy before the agent touches anything.
2) Secretless credential brokering with zero standing privileges. When the agent needs to access a resource, it doesn’t retrieve a stored secret from a vault. The identity platform verifies the agent, evaluates policy, and brokers a short-lived credential scoped to that specific action. The credential is born, used, and expires – often within seconds. There is nothing to steal.
3) Centralized policy. The security team defines access rules in one place. Those rules apply regardless of whether the developer uses K8s on AWS, Cursor, Claude Code, Gemini CLI, or a custom LangChain agent. Adding a new AI platform requires zero work from the developer.
4) Eliminated credential exposure. Sixty-four percent of leaked secrets from 2022 remain exploitable today. Attackers reach exposed AWS credentials within an average of 17 minutes. Secretless access removes the target. A hook that scans for secrets in output is a safety net. Removing the secret entirely is structural.
5) Centralized incident response. Revoke one identity and every downstream system loses access simultaneously. The investigation starts and ends in one audit log, across all platforms, with full attribution of which agent accessed which resource, when, and under what policy.
Build the Foundation Before the Guardrail
The right architecture uses both layers. Identity at the infrastructure level determines whether an agent can access a resource at all – through cryptographic verification, centralized policy, and short-lived credentials. Hooks at the runtime level determine whether a specific tool call within that authorized session looks safe – checking arguments, scanning output, gating destructive operations.
Identity is the foundation. Hooks are the guardrail on top. A guardrail on top of a foundation is defense in depth. A guardrail with nothing underneath it is a suggestion.
The companies that figure this out before their first agent-related incident will have a significant advantage over those who figure it out after.
