Claude Code needs external authorization, not prompt-level trust

At a glance

What this is: Claude Code exposure is really an authorization problem: tool-using agents can exceed intended file and command boundaries when enforcement stays inside the agent loop.

Why it matters: IAM, PAM, and IGA teams need to treat AI coding assistants as runtime subjects whose access must be policy-checked externally, because human review and local prompts do not scale to agent tool chaining.

By the numbers:

• Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027 due to escalating costs, unclear value, or inadequate risk controls.
• By 2028, Gartner expects 25% of enterprise breaches will be traced back to AI agent abuse.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Cerbos' analysis of Claude Code security and runtime authorization

Context

Claude Code is being used here as a tool-using AI assistant that can read files, write files, and run commands during developer workflows. The identity question is not whether it is useful, but whether current authorization models can reliably constrain what it can do at runtime.

The problem is the enforcement model. Prompt instructions, local configuration files, and user vigilance do not provide external control over tool calls, so an agent that misreads its own boundaries can still act outside the intended scope. For IAM and NHI governance, that is a policy enforcement gap rather than a tooling preference.

The article’s core claim is that enterprise controls must sit outside the agent’s process and be managed centrally. That is typical of the broader NHI problem space, where runtime access decisions matter more than the intent expressed by the tool or the person operating it.

Key questions

Q: How should security teams control AI coding agents that can read files and run commands?

A: Security teams should treat AI coding agents as runtime subjects and enforce access outside the agent process. Every tool call should be intercepted, policy-checked, and logged before execution. That keeps permissions under organisational control instead of inside prompt text, local config, or the model’s own interpretation of its boundaries.

Q: Why do AI coding assistants create a new authorization risk for IAM teams?

A: They turn access into a rapid chain of file reads, writes, and shell commands that can exceed the assumptions of human-paced review. IAM teams have historically governed who can log in or open a system, but agentic workflows require decisions at each tool invocation, not just at session start.

Q: What breaks when agent permissions are enforced only through prompts or local files?

A: What breaks is the enforcement boundary. Prompts and local files can influence behaviour, but they do not stop an agent from misreading or ignoring scope when the tool path is available. That leaves file access, command execution, and secret exposure governed by suggestion rather than policy.

Q: Who should own governance for AI coding agents in an enterprise?

A: The platform or security team should own it, because the controls need to apply consistently across users and devices. Governance must cover role-based access, file-path restrictions, command policy, and central audit logging so that individual developers cannot quietly widen agent permissions.

Technical breakdown

External authorization for agent tool calls

Claude Code-style assistants become a control problem when each file read, file write, or shell command is executed from inside the same process that is supposed to respect the boundary. In that model, the agent interprets its own permissions and can make assumptions that are not enforceable. External authorization moves the decision point outside the agent, so a policy engine evaluates each tool call before execution. That is the same architectural shift IAM teams already use for sensitive systems: the subject can request, but it cannot self-authorise.

Practical implication: route every agent tool call through an external policy decision point before execution.

Central policy management versus local agent config

Local instruction files and per-developer settings are guidance, not governance. They can shape behaviour, but they do not create org-wide, testable, versioned access control. Central policy management changes the operating model by making access rules consistent across users, devices, and sessions. For agentic workflows, this matters because a single person can trigger hundreds of tool calls in minutes, and the policy must follow the workload rather than the workstation.

Practical implication: keep agent permissions in centrally managed policy, not in developer-owned config files.

Audit logging for autonomous tool use

Agent activity creates a volume and speed of decisions that manual review cannot cover. The useful audit trail is not just a local command log, but a tamper-resistant record of what was requested, allowed, denied, and why. That distinction matters for IGA, PAM, and compliance because the review target is no longer a person clicking a button, but a tool chain making repeated runtime decisions across files, secrets, and commands.

Practical implication: capture every tool decision in central audit logs that compliance teams can query later.

Threat narrative

Attacker objective: The objective is to obtain unintended read, write, or execution access through the agent’s trust boundary and use it to reach secrets, code, or deployment paths.

1. Entry begins when a tool-using AI assistant receives broad file, shell, or directory access during normal developer work.
2. Credential or boundary abuse occurs when the assistant writes outside its intended scope, reads unintended files, or follows poisoned instructions embedded in repository content.
3. Impact follows when those same tool paths touch secrets, source code, or deployment triggers, creating the possibility of exfiltration or unintended production changes.

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

Prompt-level permission is not a governance model: This article shows that an AI coding assistant can reinterpret or bypass the very boundaries it is supposed to respect. That is not a usability issue; it is a control-plane failure. Access review, local instructions, and user vigilance assume the subject will remain inside declared scope. Practitioners should treat agent tool use as externally governed runtime access, not self-enforced etiquette.

External enforcement is the real control boundary for tool-using agents: The enforcement point must sit outside the agent’s process, because anything inside the agent loop is vulnerable to assumption drift and self-interpretation. This is an OWASP-NHI problem with ZT-NIST-207 implications: the tool caller is not trusted to decide its own access. The implication is that governance must move from intent management to runtime policy enforcement.

Least privilege becomes operational, not declarative, when an agent can chain actions: A single user can trigger many tool calls in sequence, which means privilege is exercised as a workflow rather than a static permission set. That breaks the old assumption that access can be reviewed comfortably after the fact. For IAM teams, the control question shifts from who had access to what happened at each step of the chain.

Runtime authorization for coding agents creates a new identity blast radius: Once an assistant can read code, inspect environment files, and trigger builds, the blast radius is determined by tool scope rather than user role alone. That makes role design necessary but insufficient. Practitioners should re-evaluate where file-path policy, command policy, and audit policy live in the stack.

Access controls designed for humans do not scale to agent-paced decisions: Human review cycles are too slow for tool calls that happen in rapid bursts. The article’s core warning is that organizations will not close this gap by asking people to watch output more closely. The implication is that identity governance for coding agents must be machine-enforced, centrally managed, and continuously logged.

From our research:

• By 2028, Gartner expects 25% of enterprise breaches will be traced back to AI agent abuse, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• Across our secrets research, the average estimated time to remediate a leaked secret is 27 days, even though 75% of organisations express strong confidence in their secrets management capabilities.
• That gap between confidence and control is why the next step is not more trust in the agent, but tighter runtime enforcement, which is explored in Analysis of Claude Code Security.

What this signals

Agentic coding tools will push IAM teams toward policy enforcement that sits outside the execution environment. The practical shift is from asking whether an assistant is helpful to asking whether every file read, shell command, and write operation can be independently authorised. The organisations that prepare now will be the ones that can absorb AI-assisted development without turning local convenience into enterprise risk.

Runtime authorisation for agents creates a distinct control class: it is not classical PAM, not standard developer access, and not purely secrets management. That is why the governance model needs to span policy, audit, and delegation together, with external controls such as the NIST AI Risk Management Framework providing the broader governance context.

The concept to watch is identity blast radius: the real exposure is no longer just who has access, but how many chained actions the identity can execute before any human notices. As agent adoption expands, teams should expect this blast radius to become a board-level question rather than a developer convenience issue.

For practitioners

• Move agent authorization outside the agent process Intercept every file, shell, and network-related tool call before execution, and evaluate it in an external policy engine that the agent cannot modify or bypass.
• Centralise policy for all agent sessions Remove permission logic from per-developer config files and keep it in versioned, testable policy managed by the platform team across the organisation.
• Audit every tool decision centrally Store allow and deny decisions with request context, timestamps, and outcome in a searchable audit log that compliance and security teams can review later.
• Restrict high-risk paths and secrets by default Block access to .env files, system folders, and deployment-triggering commands unless an explicit policy allows them for that role and workflow.
• Start in observe mode before enforcement Run the hooks in logging-only mode first so you can see what agents actually try to do across teams before turning on denies.

Key takeaways

• Claude Code-style assistants expose a runtime authorization problem, because prompt-level trust cannot reliably contain file, shell, and write actions.
• The evidence points to a control gap that IAM, PAM, and IGA teams already recognise: a subject can chain too many actions too quickly for human review to be the control.
• The practical response is external enforcement, central policy, and tamper-resistant audit logging for every agent tool call.

Key terms

• Agentic coding assistant: A software assistant that can choose actions and call tools during development work. In this context, it is governed like a non-human identity because its file access, command execution, and write behaviour can affect systems directly, even when a human provided the original request.
• External authorization: A control model where access decisions are made outside the subject that is requesting the action. For AI coding tools, that means an independent policy engine decides whether a file read, shell command, or write is allowed before the action runs.
• Identity blast radius: The practical spread of damage an identity can cause across files, commands, secrets, and deployments. For tool-using agents, blast radius is shaped less by the user’s title and more by how many chained actions the agent can execute before a human or policy boundary intervenes.
• Observe mode: A deployment mode where tool calls are logged and evaluated without blocking so teams can learn actual agent behaviour before enforcing denies. It is useful when the organisation needs evidence about real access patterns before turning on stricter controls.

Deepen your knowledge

Claude Code and runtime authorization for AI assistants are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to govern tool-using agents inside developer workflows, the course gives you the identity foundations to do it with discipline.

This post draws on content published by Cerbos: Claude Code security and runtime authorization for AI coding agents. Read the original.