Policy controls for Claude Code agents need central enforcement

At a glance

What this is: This is a Cerbos analysis of how Claude Code hooks can be routed through central policy enforcement to govern agent tool calls, with the key finding that local-only controls leave a major audit and governance gap.

Why it matters: It matters because IAM, IGA, and PAM teams need a way to evaluate AI agent actions at the level of individual tool calls, not just at account or session level, across NHI, autonomous, and human identity programmes.

By the numbers:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems.

👉 Read Cerbos's analysis of Claude Code hook enforcement and AI agent governance

Context

Claude Code now sits inside a broader identity problem rather than just a developer productivity story. The issue is not whether agents can act, but whether those actions can be governed, logged, and reviewed at the level of each tool call. In practice, existing access management and PAM controls were designed for identities with stable, reviewable privilege, not for fast sequences of agent-driven file reads, command execution, and writes.

Cerbos frames the gap as a control plane problem for AI agent activity. Local hooks can intercept actions, but without central policy enforcement and auditability, teams cannot prove what the agent accessed or why a decision was made. That leaves security, compliance, and platform teams trying to reconstruct behaviour after the fact from scattered developer machines, which is not a defensible operating model.

Key questions

Q: How should security teams govern AI agent tool calls in development environments?

A: Treat each tool call as an authorisation event, not a generic automation step. Map the agent principal, tool action, and request context into policy, then log every allow, deny, and no-match decision centrally. That gives IAM, security, and audit teams a defensible record of what the agent did and why it was permitted.

Q: What breaks when Claude Code hooks are left as local developer settings?

A: Governance becomes optional and uneven. Local hooks can be removed, skipped, or never deployed, which means the organisation cannot prove that every agent action was subject to the same policy. That creates a coverage gap across laptops, teams, and workloads, and it weakens both auditability and security assurance.

Q: How do you know if AI agent access controls are actually working?

A: Look for complete decision logs, central policy distribution, and consistent enforcement across every managed device. If you only discover agent behaviour by grepping local logs after the fact, the control is not working as a governance system. Effective controls produce searchable evidence before an auditor or incident responder asks for it.

Q: What should teams do when an AI agent tries to access sensitive files or destructive commands?

A: Deny the action at the policy layer and return a clear reason that can be logged and reviewed. Then use the denial data to refine the policy set around file paths, command patterns, and role scope. The goal is to stop risky execution before it happens and preserve a traceable record.

Technical breakdown

Claude Code hooks as a policy decision point

Claude Code hooks are interception points that fire before or after a tool action such as read, write, or command execution. In Cerbos Synapse, each hook event is mapped into a policy request: the event name becomes the resource kind, the tool name becomes the action, the hook headers identify the principal, and the full payload becomes resource attributes. That structure turns an agent action into a standard authorisation decision, with allow, deny, or no-match outcomes that can be logged centrally.

Practical implication: Treat every agent tool call as an authorisation event, not a developer convenience feature.

Server-managed settings versus local hook drift

The real control failure is not the hook itself, but local-only enforcement. If every developer stores the hook in a personal config file, coverage becomes optional, revocable, and uneven across the fleet. Server-managed settings delivered through MDM or managed config files remove that variability by pushing the hook configuration centrally and preventing local overrides. That matters because governance only works when the control is enforced everywhere the agent runs, not just where developers opted in.

Practical implication: Use centrally managed settings so agent policy cannot be bypassed by local configuration drift.

Audit logs and policy-as-code for AI agents

Central audit logging changes the governance model from detective guesswork to searchable evidence. Every decision can be stored in a hub, linked to the user and role, and used to support compliance reporting or policy review. Policy-as-code adds another layer by letting teams version, test, and distribute rules the same way they handle other controlled changes. The key architecture point is that the policy boundary sits outside the agent, so runtime behaviour can be constrained independently of the developer environment.

Practical implication: Build an external audit trail and policy lifecycle around agent actions, not just around developer endpoints.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Central policy enforcement is now the missing control plane for agent tool use. Claude Code can already chain reads, writes, and shell execution in ways that create real security decisions at runtime. Local hooks provide interception, but they do not create a governing boundary unless policy is applied centrally and consistently. The implication is that identity teams must stop treating agent tools as developer ergonomics and start treating them as policy-enforced execution points.

Access management for AI agents fails when it is evaluated only at account level. Traditional IAM, IGA, and PAM all assume the meaningful decision is who has the account or session. This article shows why that assumption breaks down once the interesting event is an individual tool call, a file path, or a command string. Practitioner implication: the governance model has to move from coarse entitlements to per-action authorisation evidence.

Observe-then-enforce is the right control pattern for early agent governance. The article correctly starts with audit-only deployment before introducing deny rules, because most teams do not yet know what their agents actually do. That sequence matters more than the specific policy examples, since premature blocking without behavioural evidence will create blind spots and workarounds. Practitioner implication: instrument first, then tighten policy from actual usage data.

Developer machine controls are not enough for enterprise-grade AI governance. When hooks live only on local endpoints, a missed config push, an opt-out, or an unmanaged laptop creates an immediate governance exception. This is not just a tooling issue, it is a lifecycle issue for agent permissions. The practitioner implication is to align AI agent controls with managed identity operations, not with personal workstation habits.

Policy-as-code gives agent governance a reviewable operating model. The article shows a path where rules are versioned, tested, and promoted through change control like any other security policy. That is the right direction for organisations that need defensible decisions for audit and compliance. Practitioner implication: if the policy cannot be reviewed, tested, and rolled out centrally, it is not yet a governance control.

From our research:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to The 2026 Infrastructure Identity Survey.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems.
• For a governance model that addresses lifecycle, rotation, and offboarding across non-human identities, see NHI Lifecycle Management Guide.

What this signals

Policy enforcement for agentic development will move from endpoint convenience to central identity governance. Teams that keep hook logic in local developer configs will keep inheriting coverage gaps, while organisations that push policy through managed settings will get a clearer operating boundary for agent actions. With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, the governance problem is already larger than any single tool integration.

Claude Code-style controls point to a broader runtime authorisation layer for AI work. That layer will sit between developer intent and machine execution, which means IAM teams will have to think in terms of command-level evidence, not just account provisioning. For the architectural model behind that shift, the OWASP Agentic AI Top 10 is the right external lens, especially where tool misuse and permission boundaries converge.

For practitioners

• Map agent tool calls to policy decisions Classify every Claude Code action that can read, write, or execute as an authorisation request with a principal, resource, and action. Log the full payload so security teams can reconstruct the decision context later.
• Enforce hooks through managed settings Push hook configuration through MDM or managed config so developers cannot remove or bypass the policy check locally. Treat local-only hook files as an incomplete control and remove them from your trust model.
• Start with an observe-only rollout Collect allow, deny, and no-match telemetry before writing enforcement rules. Use the first week of data to identify which tool calls, file paths, and commands actually need restrictions.
• Block sensitive paths and destructive commands first Write initial deny rules for secrets, credentials, .env files, recursive delete patterns, force pushes, and command pipelines that fetch and execute remote code. Keep the allow baseline narrow until the audit trail shows normal behaviour.
• Separate role policy from command policy Give different groups different tool permissions, then add command-level inspection for trusted roles that still need guardrails. That lets engineers keep productive access while reducing the chance of destructive shell execution.

Key takeaways

• Claude Code agents create a governance problem at the tool-call level, where local hooks alone do not provide enforceable enterprise control.
• The evidence gap is operational, not theoretical, because organisations need central logs and policy decisions to prove what an agent accessed and why.
• The practical response is to move from local config to managed policy, starting with observation and then tightening rules around secrets, commands, and role scope.

Key terms

• Policy Decision Point: A policy decision point is the service that evaluates a request and returns allow, deny, or no-match. In agent governance, it must sit outside the tool runner so the decision can be applied consistently, logged centrally, and reviewed independently of the developer machine.
• Server-Managed Settings: Server-managed settings are centrally delivered configuration values that cannot be overridden locally by the end user. For AI agent governance, they prevent hook drift by ensuring policy enforcement is pushed to every managed device and cannot be bypassed by personal config changes.
• Tool-Call Authorisation: Tool-call authorisation is the practice of making each agent action request a distinct security decision. Instead of granting broad access to the agent process, the system evaluates the specific tool, inputs, role, and context before execution, which creates a reviewable control boundary.

Deepen your knowledge

Claude Code governance, tool-call policy, and central auditability are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is building controls for agentic development from a similar starting point, it is worth exploring.

This post draws on content published by Cerbos: Claude Code hooks, policy enforcement, and AI agent governance. Read the original.