A Look At An Emerging Runtime Enforcement Layer For Agents - Hooks
Every major coding agent platform now supports hooks. But the implications go far beyond endpoint agents. Hooks show the industry converging on a architectural pattern for runtime security
Something important is happening across the agentic AI ecosystem that is likely to play a key part in securing agents moving forward.
Over the past several months, every major coding agent platform has independently arrived at the same architectural pattern for runtime security enforcement. They are calling it hooks. See examples for the leading platforms such as Claude Code, Cursor, Windsurf, Cline, GitHub Copilot, and OpenClaw.
The concept isn’t one that just commercial industry is rallying around, but researchers as well, such as in this paper “Trustworthy Agentic AI Requires Deterministic Architectural Boundaries”. The paper lays out the fundamental flaws of Agents and the LLMs at their core, especially with the presence of the now popular concept of the lethal trifecta and they propose deterministic boundaries as a risk mitigation mechanism.
The convergence is not a coincidence. It reflects a growing recognition that the agent loop itself needs a deterministic enforcement point, one that intercepts every action before it executes and evaluates it against policy.
But this pattern is not limited to coding agents. My team at Zenity recently announced general availability of inline runtime security for agents built on Microsoft Foundry, bringing the same interception-and-enforcement model to SaaS and homegrown enterprise agents.
When both the coding agent ecosystem and the enterprise agent security market converge on the same architectural principle, the signal is unmistakable. Inline runtime enforcement is becoming the foundational layer for agentic AI security across every deployment pattern.
I have been writing about the need for hard boundaries and runtime enforcement in agentic AI security for months. In my breakdown of Claude Code’s Auto Mode, I explored the tension between probabilistic AI-based safety classifiers and the deterministic controls that security practitioners trust. Anthropic provided a good visualization below to demonstrate the tradeoffs of the modes they offer, with the recent introduction of auto-mode.
Many are recognizing that architectural controls such as hooks are a strong mitigation method to agentic AI risks, and the industry is converging on them faster than most people realize.
Interested in sponsoring an issue of Resilient Cyber?
This includes reaching over 31,000 subscribers, ranging from Developers, Engineers, Architects, CISO’s/Security Leaders and Business Executives
Reach out below!
What Hooks Actually Are
At the most basic level, a hook is a programmatic interception point in the agent execution loop. When an agent is about to take an action, such as executing a shell command, writing a file, making an API call, or reading sensitive data, the hook fires before that action executes. The hook receives context about what the agent is about to do, evaluates it against a set of rules or policies, and returns a decision. Allow, deny, or modify. If the hook denies the action, the agent cannot proceed. The action is blocked before it ever touches the environment.
This is fundamentally different from the permission prompt model that most agent platforms started with, where the human user is asked to approve or deny each action. As Anthropic’s own data showed, users approve 93% of permission prompts, and experienced users shift to auto-approve over 40% of the time. The human-in-the-loop was not functioning as a meaningful security control, which I discussed in my article “The Human-in-the-Loop Illusion”. Hooks replace that with programmatic enforcement that does not depend on human attention.
The hook pattern typically operates at two critical points in the agent loop. PreToolUse hooks fire before a tool call executes, giving the enforcement layer the ability to block dangerous actions before they happen. PostToolUse hooks fire after a tool call completes, enabling logging, audit trails, and detection of anomalous outcomes.
Some platforms support additional hook points for events like session start, subagent delegation, error handling, and notification triggers. But PreToolUse is the enforcement mechanism that matters most for security, because it is the point where you can prevent harm rather than just detect it after the fact.
Claude Code’s implementation is instructive, and their hooks support three handler types. Command hooks run shell scripts that receive JSON context via stdin and return decisions through exit codes. Prompt hooks send the action context to a Claude model for single-turn evaluation, and agent hooks spawn subagents with access to tools for deeper verification. Critically, Claude Code enforces hooks recursively, meaning if the agent spawns a subagent, the hooks fire for every tool call the subagent makes as well. Without recursive enforcement, a subagent could bypass the safety gates entirely.
Below is an example from Cursor, showing where/how these can be used as well:
GitHub Copilot’s coding agent supports hooks in public preview with events including userPromptSubmitted, preToolUse, postToolUse, and errorOccurred. Windsurf’s Cascade includes hooks as pre- and post-action triggers. Cline provides hooks for treating the agent as another service in your toolchain. The pattern is consistent across all of them as Intercept, Evaluate, and Enforce.
Why Declarative Policy Languages Matter
Hooks provide the interception mechanism, but the question of what policies those hooks enforce is equally important. This is where declarative policy languages like Cedar enter the picture, and why I think they represent a critical evolution in how we think about agent governance.
Cedar is a policy language created by AWS that was designed for fine-grained authorization decisions. It is declarative, meaning you express what is allowed or denied as policy statements rather than writing imperative code that makes those decisions procedurally, and it is a distinction that matters for several reasons.
First, declarative policies are auditable. A Cedar policy that says “forbid action execute when resource.command contains ‘rm -rf’” is readable by security teams, compliance auditors, and governance reviewers without requiring them to understand the underlying code. This is essential for enterprise environments where security policies need to be reviewed, approved, and documented.
The below example is from a blog by Sondera and Matt Maisel titled “Hooking Coding Agents with Cedar Policy Language” and it is one of the best on the topic I’ve seen yet.
Second, declarative policies are portable across agent platforms. Sondera demonstrated this with their reference monitor implementation, which maps agent-specific tool names from Claude, Cursor, Copilot, and Gemini to common types, allowing Cedar rules to work identically across all four agent platforms. This sort of reusability allows for an approach of writing the policy once and enforcing it everywhere. Matt Maisel of Sondera also delivered an excellent talk on this concept titled “Hooking Coding Agents with the Cedar Policy Language” at the [un]prompted conference in March.
Third, declarative policies separate policy from code, which is a foundational principle of good security architecture. When policies live in the application code, changing them requires code changes, testing, and deployment cycles.
When policies are externalized into a declarative language, they can be updated, versioned, and deployed independently of the agent or application code. Phil Windley’s work on the policy-aware agent loop with Cedar and OpenClaw demonstrates this pattern in practice, showing how every tool invocation can be evaluated at runtime by a Cedar-backed policy decision point.
Instead of authorization being a one-time gate at the edge, it becomes a continuous feedback signal that guides replanning and enforces Zero Trust principles throughout the agent’s execution. The below image from Phil’s blog helps demonstrate a policy-aware agent loop and shows how Cedar policy evaluation can sit inside the agent execution loop between action proposal and action execution.
This matters because the alternative is what we have today in most environments. Hard-coded allow lists and deny lists in JSON configuration files, bespoke shell scripts that check for specific patterns, and ad hoc rules that vary across teams and tools. That approach does not scale, it does not provide consistent enforcement and it does not give security leaders the governance and audit capabilities they need.
The Reference Monitor Pattern
The concept of a reference monitor is not new. It originates from classical computer security, where it describes an enforcement mechanism that must meet three criteria. First, it must be always invoked, meaning every action is intercepted without exception. Second, it must be tamper-proof, meaning the subject cannot alter the monitor or its policies. Third, it must be verifiable, meaning the enforcement logic must be simple, deterministic, and auditable.
Recent academic research has formalized how this pattern applies directly to agentic AI. “Policy Compiler for Secure Agentic Systems” (PCAS), which implements a reference monitor that intercepts all agent actions and blocks policy violations before execution. PCAS models agentic system state as dependency graphs, expresses authorization policies in a Datalog-derived language, and compiles agent implementations with policy specifications into instrumented systems that are policy-compliant by construction.
Their results are telling. Across frontier models including Claude Opus 4.5, GPT-5.2, and Gemini 3 Pro, un-instrumented agents achieved only 48% policy compliance. With the reference monitor in place, that jumped to 93%, with zero violations in instrumented runs. The takeaway is straightforward, you cannot rely on the model to follow the rules on its own, you need an external enforcement layer that does not ask the model for permission.
This framing is important because it draws a clear line between hooks as a security enforcement mechanism and the probabilistic AI-based classifiers that some platforms use as safety controls. An AI classifier that evaluates whether an action “looks safe” fails the verifiability criterion. It is non-deterministic by nature. A declarative policy engine that evaluates a structured authorization request against explicit rules meets all three criteria. The reference monitor pattern is what turns hooks from a convenient automation feature into a genuine security boundary building on longstanding cybersecurity principles and concepts.
Microsoft’s recently released Agent Governance Toolkit reinforces this pattern. Their Agent OS component functions as a stateless policy engine that intercepts every agent action before execution with sub-millisecond latency. It hooks into framework-native extension points across LangChain, CrewAI, Google ADK, and Microsoft’s own agent framework, providing consistent governance without requiring agent code rewrites. The toolkit addresses all ten OWASP agentic AI risks and is available across Python, TypeScript, Rust, Go, and .NET.
Were seeing industry leaders such as Microsoft, Anthropic, GitHub, startups and academic researchers are all converging on the same architectural pattern.
Beyond Endpoint Agents - Inline Enforcement for SaaS and Custom Agents
I also want to highlight that the capability extends beyond endpoint coding agents, where most of the industry discussion has been focused. The hook implementations I have described so far are primarily designed for endpoint coding agents.
Claude Code, Cursor, Windsurf, Cline, and GitHub Copilot are all tools that run on developer machines or in CI/CD environments. Hooks in these contexts intercept shell commands, file writes, and tool calls within the development workflow. That is valuable, but it is one-third of the agentic AI security problem in terms of common deployment scenarios for agents.
As I have written about extensively, there are three major agent deployment patterns that enterprises need to secure. Endpoint agents are the first. SaaS/Embedded agents that come bundled inside enterprise SaaS platforms are the second, and Homegrown/Custom agents that organizations build internally are the third, often in cloud hosting environments. The hook pattern needs to extend across all three, and we are starting to see that happen.
Not to self-promote, but my team Zenity recently announced inline runtime security for Microsoft Foundry agents as well. This is an example of what this looks like beyond the coding agent world and covering other agent deployment patterns as well. Zenity integrates natively into the agent execution path within Microsoft Foundry, intercepting agent actions in real time and blocking unsafe behavior before data moves or tools execute.
This is the same PreToolUse enforcement pattern that Claude Code and Cursor implement for coding agents, but applied to enterprise agents that connect to SharePoint, OneDrive, databases, SaaS platforms, and internal APIs.
These are not coding agents running shell commands on a developer laptop. These are business agents built by both professional developers in Microsoft Foundry and citizen developers in Copilot Studio, operating across IT operations, customer support, finance, healthcare, manufacturing, and the public sector.
They make decisions, chain actions, and invoke tools across enterprise environments, and they introduce classes of risk that traditional prompt-level or post-execution controls were never designed to address. Similar to utilizing inline enforcement for coding agents, it can help mitigate risks such as sensitive data leakage, secret exposure, jailbreak attempts and tool misuse and it does so across chained actions not isolated prompts.
For homegrown and custom agents beyond the Microsoft ecosystem, the pattern is equally critical. Organizations building agents using frameworks like LangChain, LangGraph, CrewAI, or the OpenAI Agents SDK need to embed policy enforcement directly into the agent loop.
Microsoft’s Agent Governance Toolkit provides one path, hooking into framework-native extension points to enforce governance without agent code rewrites. Phil Windley’s work on Cedar and OpenClaw provides another, demonstrating how declarative policy evaluation can be inserted into the agent loop as a continuous authorization mechanism.
The OpenClaw project itself now supports pre and post tool use hooks with the ability to pause execution and request human approval for specific actions, blending programmatic enforcement with human oversight where it is genuinely warranted.
The organizations that only think about hooks in the context of endpoint coding agents are making the same mistake as organizations that only thought about cloud security in terms of IaaS.
The agent surface extends across all three deployment patterns, and the enforcement mechanism needs to follow. The coding agent ecosystem has hooks and it is starting to become a key discussion point.
Enterprise platforms like Microsoft Foundry now have inline enforcement as well. We’re starting to see this mechanism as a dominant pattern from those leading in the ecosystem when it comes to securing agentic AI and mitigating risks.
What This Means for Security Leaders
The convergence on hooks and inline enforcement across the agentic AI ecosystem tells security leaders several important things.
First, the industry has collectively recognized that human-in-the-loop approval does not work as a primary safety mechanism, a topic I’ve already written extensively on. Every platform that has implemented hooks did so because the alternative, asking users to approve every action, was failing in practice as HITL became a rubber stamp or sidestepped entirely. Hooks represent the industry’s answer to that failure. They move enforcement from the human to the infrastructure.
Second, declarative policy languages like Cedar (or others such as OPA etc.) provide the governance layer that hooks need to be operationally viable at scale. Hard-coded rules in JSON files work for small teams. They do not work for enterprises with hundreds or thousands of developers, dozens of agent tools, and regulatory requirements for policy documentation and audit trails. The separation of policy from code is not optional at enterprise scale.
Third, the hook pattern maps directly to the AISPM and AIDR capabilities I have been advocating for and that are common among leading Agentic AI security platforms. AISPM defines the policies, trust boundaries, and posture configuration. AIDR enforces those policies at runtime and detects violations. Hooks and inline enforcement are the mechanisms that connect the two. They are the runtime enforcement point where posture becomes protection.
Fourth, this pattern needs to span all three deployment environments. The same enforcement architecture that prevents a coding agent from executing rm -rf on a production server needs to prevent a Custom-built agent from leaking sensitive customer data through a chained tool call, and a SaaS-embedded agent from exceeding its authorized action scope.
We discussed several leading examples across different deployment scenarios. The policy language may differ, but the architectural principle is identical. Intercept every action, evaluate against policy, enforce before execution.
Like Any Other Control, Hooks Are Not Infallible
I want to be direct about something before this piece sounds like hooks are the silver bullet for agentic AI security, they are not. Like any security control, hooks have real limitations, known bypass vectors, and failure modes that practitioners need to understand.
The research is already piling up. In February 2026, Check Point Research disclosed critical vulnerabilities in Claude Code (CVE-2025-59536 and CVE-2026-21852) that turned hooks from a defensive mechanism into an attack vector. By injecting a malicious hook definition into the .claude/settings.json file within a repository, an attacker could gain remote code execution the moment a developer cloned and opened the project.
The hook command ran before the user ever saw a trust dialog. A second finding showed that repository-controlled configuration settings could override safeguards and auto-approve all MCP servers, triggering execution on launch without any user confirmation.
In March 2026, Adversa AI disclosed a separate vulnerability where Claude Code silently ignored all user-configured deny rules when a shell command contained more than 50 subcommands.
The root cause was a hard cap (MAX_SUBCOMMANDS_FOR_SECURITY_CHECK = 50) introduced to avoid UI freezes during security analysis of compound commands. When a command exceeded that threshold, Claude Code skipped all per-subcommand deny rule enforcement entirely and fell back to a generic prompt that could be auto-allowed. The practical attack was straightforward.
A malicious CLAUDE.md file in a public repository could craft a compound command long enough to bypass every deny rule the developer had configured, with SSH keys, cloud credentials, and publishing tokens all at risk. The fix existed in a newer parser in the same codebase. It had simply never been deployed to customers.
These are not theoretical concerns. They are disclosed CVEs, published research, and real bypass vectors that worked against one of the most prominent agentic coding tools on the market.
Beyond implementation bugs, there are architectural limitations worth acknowledging. Hooks operate on the tool calls the agent makes, but they cannot govern what the agent reasons about, plans internally, or decides not to surface.
An agent that has been prompt-injected may never issue the tool call that would trigger the hook. It may instead find alternative paths, decompose a restricted action into individually permissible sub-actions, or simply provide misleading context about what it intends to do. Hooks enforce policy at the action boundary, not at the reasoning boundary, and that gap matters.
Another interesting (and scary) example came from Nathan Sportsman, CEO of OffSec company Praetorian, who demonstrated how his agent, in its own words, “gamed” the hook to bypass the control, directly exploiting a loophole it identified.
Again, hooks are not a silver bullet, and agents are incredibly unpredictable and relentlessly pursue their goals.
There is also the configuration problem. Hooks are only as strong as the policies behind them. A misconfigured rule, an incomplete deny list, or an overly permissive default can create a false sense of security that is arguably worse than having no hooks at all.
Projects like Cupcake from EQTY Lab, built on OPA/Rego with agentic safety research support from Trail of Bits, are working to make policy authoring more rigorous by bringing governance-as-code practices from the DevSecOps world into the agent security context. But policy completeness remains an open challenge.
None of this means hooks are not worth implementing. It means they need to be understood for what they are. One layer in a defense-in-depth strategy for agentic AI security, not the entire strategy.
The reference monitor pattern I discussed earlier provides the architectural foundation. Hooks are the mechanism through which that pattern gets instantiated. But like firewalls, EDR, and every other security control the industry has deployed over the past three decades, they will be bypassed, misconfigured, and attacked.
The goal is not perfection. The goal is raising the cost and complexity of compromise while maintaining the visibility and audit trail needed to detect what gets through. That is what defense in depth has always meant, and agentic AI does not get a special exemption from that reality.
The Bottom Line
Hooks and inline enforcement are not just developer convenience features. They are becoming an architectural foundation of runtime security for agentic AI. The fact that every major coding agent platform, enterprise agent security vendors, and framework-level toolkits have all converged on this pattern tells you it is not a trend.
It is a becoming a structural requirement. Agents that take real-world actions need deterministic, policy-driven enforcement at the point of execution, whether they are writing code on a developer machine, processing customer records in an enterprise application, or executing workflows inside a SaaS platform.
The organizations that build their agentic AI security strategy around this pattern, with declarative policies, cross-platform enforcement, and coverage across all three deployment types, will be the ones that deploy agents at scale with genuine guardrails.
The ones that rely on permission prompts and hope will eventually find out what happens when an agent acts without oversight in an environment without boundaries. That said, as I pointed out above, hooks are but one part of a broader defense-in-depth strategy for securing agentic AI as well.