Policy controls for Claude Code agents need central enforcement

At a glance

What this is: This is a Cerbos analysis of why Claude Code hooks alone do not give organisations central policy enforcement, auditability, or runtime control over AI agent tool use.

Why it matters: It matters because IAM teams need provable, centrally managed controls for AI agent actions before those agents are allowed to touch sensitive files, commands, or production workflows.

Context

Claude Code agent governance is the problem space here: developer-facing AI agents can trigger file reads, shell commands, and write operations at runtime, but local hooks do not create a centrally enforced decision point. That leaves security, IAM, and audit teams with a policy gap between what an agent can do and what the organisation can prove it allowed.

The article argues that existing IAM, IGA, and PAM models were not designed to evaluate individual tool calls in real time. In practice, that means access decisions for AI coding agents need to move from developer-managed local settings to centrally governed policy enforcement if teams want consistent control and auditability.

Key questions

Q: Where does Claude Code governance fail when hooks are only local?

A: It fails at consistency and enforceability. Local hooks depend on each developer's machine state, so the organisation cannot prove that the same policy applied to every agent action. A centrally managed policy boundary is needed when you want repeatable decisions, searchable logs, and controls that cannot be bypassed by removing a local config file.

Q: Why do AI coding agents need central audit trails for tool calls?

A: Because the risk is in the action stream, not just the login. AI agents can read files, run commands, and write output many times in one session, so the relevant evidence is each decision event. Central audit trails let security and compliance teams reconstruct what happened without relying on scattered local logs.

Q: What do security teams get wrong about Claude Code hooks?

A: They often treat hooks as if they are governance by themselves. In reality, a hook only intercepts an event unless the policy, identity context, and logging are centrally enforced. Without that, the organisation has observation without control and no reliable way to prevent sensitive access at scale.

Q: How should teams govern AI agents that can reach APIs, events, and memory?

A: Teams should govern those agents as runtime identities, not as isolated integrations. That means enforcing policy at execution time, logging every tool and data access, and binding actions back to a clear initiating workflow or identity. If the control plane cannot show who acted, what they reached, and why, the programme does not have usable governance.

Technical breakdown

Why local Claude Code hooks do not create enforceable governance

Claude Code hooks let organisations intercept tool calls before and after they occur, but a hook on a single machine is not a control plane. If the configuration lives in per-developer settings, the policy is only as strong as that developer's setup, persistence, and discipline. That creates uneven enforcement, especially when agents can read files, run Bash, and chain actions quickly. The governance issue is not whether hooks exist, but whether every decision is evaluated against the same central policy and logged in a way that IAM and security teams can review.

Practical implication: Treat hooks as an interception point, not as governance, unless policy and logging are centrally enforced.

How server-managed settings change the control model

Server-managed settings shift Claude Code from optional local configuration to centrally distributed configuration that users cannot easily override. That matters because the security boundary is no longer developer preference but managed policy. When hooks, headers, and routing are pushed through MDM or managed config, the organisation can bind agent activity to a principal, assign roles, and preserve a consistent enforcement path. The control value comes from removing the local opt-in problem and making policy part of the managed identity workflow rather than a personal workstation setting.

Practical implication: Use centrally managed configuration when the organisation needs the same agent policy on every endpoint.

What audit logging looks like for AI agent tool calls

The article describes every allow, deny, and no-match decision being logged centrally, with the payload available for search, filtering, and compliance reporting. That is important because runtime agent decisions do not fit traditional access review cycles. A tool call can happen, be denied, and disappear unless the system records it with the user identity, role context, and reason. For AI agents, the real governance object is the decision event itself, not just the account behind it. That is the layer security teams must be able to inspect after the fact.

Practical implication: Make the decision log the primary evidence source for agent governance and compliance review.

NHI Mgmt Group analysis

Claude Code governance breaks when runtime policy is left local: the assumption behind access review is that the identity and its permissions are stable long enough to be reviewed. That assumption fails when an AI agent makes tool-use decisions at runtime and the only control is a per-developer hook config. The implication is that the governance object is no longer the developer endpoint but the centrally enforced decision boundary.

Policy enforcement must move from workstation configuration to managed authorisation: local hooks can observe, but they cannot guarantee consistent organisational enforcement. When each developer can control whether the hook is present, enabled, or redirected, security has no reliable control plane for agent behaviour. Practitioners should view this as an authorisation architecture problem, not a developer productivity feature.

AI agents turn tool calls into a high-frequency authorisation stream: one user action can trigger many file, shell, and write decisions in a short period of time. That creates a governance pattern closer to machine identity decisioning than to human session management. The result is that IAM, IGA, and PAM all need to be evaluated at the per-tool decision layer, not just at login or role assignment.

Central auditability becomes a prerequisite for agent adoption, not a reporting extra: without a searchable record of what the agent did, organisations cannot answer basic control questions about sensitive file access or destructive command execution. Runtime tool-call governance: the key design shift is to treat every agent action as an authorisation event with policy, context, and evidence attached. Practitioners should reframe AI coding agent rollout around that control boundary.

The Claude Code pattern signals where agent governance is heading: policy must be distributed, consistent, and tied to identity context rather than left to individual developers. That aligns more closely with centralised authorisation and lifecycle governance than with ad hoc endpoint configuration. For IAM teams, the practical conclusion is that agent control will increasingly sit inside the same governance model used for privileged and machine access.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• 7% of security leaders admit they do not know how often their AI systems are making autonomous changes to infrastructure, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Coding Agents Security Guide

What this signals

Runtime tool-call governance: Claude Code shows why AI agent control cannot stop at login, role assignment, or endpoint configuration. The decision boundary has to move to the individual tool call, because that is where sensitive file access and command execution actually happen.

A centrally enforced hook path gives IAM and security teams something local settings never can: a consistent, searchable record of what the agent was allowed to do, what it was blocked from doing, and why. That is the minimum evidence model for governing code-assistant agents in production environments.

For practitioners

• Deploy central policy enforcement for agent tool calls Route Claude Code tool events through a centrally managed policy decision point so every read, write, and shell invocation is evaluated against the same rules.
• Move hooks out of local developer config Use server-managed settings or managed device configuration so hook enforcement cannot be removed, redirected, or skipped by individual users.
• Log every allow, deny, and no-match event Capture decision logs with principal identity, roles, resource attributes, and the tool context so auditors can reconstruct what the agent did.
• Start with observe mode before enforcement Run the hook path in logging-only mode first, review real tool-call patterns, then introduce deny rules for sensitive files and destructive commands.
• Bind agent actions to role context Populate role and user headers from your identity source so policies can distinguish engineers from other users without relying on local machine state.

Key takeaways

• Claude Code agents expand the governance surface from user login to per-tool authorisation decisions, which local hooks alone cannot control consistently.
• The core evidence gap is auditability, because scattered workstation logs do not give security teams a reliable record of what agents accessed or attempted.
• Central policy enforcement, managed configuration, and decision logging are the controls that make AI coding agent governance defensible in practice.

Key terms

• Tool Call Governance: Tool call governance is the control of model-initiated actions that reach external systems, data sources, or workflows. It matters because the model is no longer only generating content. It is making a request that can change state, so policy checks must happen before execution continues.
• 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.
• Decision Log: A decision log is the audit record that explains why a privileged action was allowed or denied. For identity governance, it should capture the subject, tenant, purpose, policy version, and expiry so responders can reconstruct accountability quickly after an incident.
• Policy decision point: A policy decision point evaluates contextual rules and returns an access decision that enforcement points can act on. It separates authorization logic from application code, which helps teams manage tenant rules, resource ownership, and risk signals consistently.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.