Action-time authorization is the missing control for coding agents

At a glance

What this is: NHI Mgmt Group's analysis, drawing on PermitIO's blog post: Coding agents need action-time authorization because refusal in text and permission to act are different control planes.

Why it matters: IAM, PAM, and NHI teams need to govern agent tool use at runtime, or they will keep mistaking safe conversation for safe execution.

Context

Coding agents create a governance problem that text-only safety checks cannot solve. A model can refuse a request in natural language and still produce a tool call with side effects, so the security question is not what the agent says but whether the action is authorised before execution.

For IAM and NHI programmes, that means the control boundary shifts from prompt hygiene to runtime decisioning. The article frames this as an authorization problem, not a model-quality problem, because the same session can contain both a safe refusal and an unsafe command.

This is a classic action-time control gap in agentic systems: the tool layer is where business impact happens, and the governance model has to inspect the action tuple, not only the conversation transcript.

Key questions

Q: What breaks when coding agents only have text safety controls?

A: Text-only controls break because they judge what the agent says, not what it does. A coding agent can refuse in chat and still issue a tool call that reads files, changes state, or reaches external systems. The missing control is execution-time authorization, which must decide whether the action is allowed before the runtime carries it out.

Q: Why do coding agents need runtime authorization instead of prompt guardrails alone?

A: Prompt guardrails shape model behaviour, but they do not decide whether a specific action is legitimate for a given identity, resource, and task. Runtime authorization is needed because tool use is where side effects happen. Without it, the system can appear safe in conversation while still creating real operational risk.

Q: How can security teams tell whether action-time authorization is actually working?

A: Look for a clear separation between attempted and executed actions. A working control should show blocked calls for risky operations, consistent policy decisions across tools, and approval records where human review is required. If blocked attempts are invisible or execution logs show unauthorised side effects, the control is not effective.

Q: Should teams treat hooks, sandboxes, and approvals as the same security control?

A: No. Hooks intercept calls, sandboxes limit blast radius, and approvals add human review, but none of them replaces a final authorization decision. They are enforcement layers with different jobs. Teams should combine them only when a centralized policy engine remains the last decision point before execution.

Technical breakdown

Why refusal is not authorization in coding agents

A refusal is model output, but authorization is a runtime decision. In a coding agent, those two outcomes can diverge because the planner may generate a denial in text while the tool layer still forms a call to the filesystem, shell, database, or MCP server. That separation creates a blind spot when teams only evaluate prompt responses or user-facing safety messages. The real control point is the execution gate, where the system must decide whether the requested action is allowed for this identity, resource, and context.

Practical implication: inspect and block tool calls independently of chat responses.

What action-time authorization evaluates at the moment of execution

Action-time authorization normalises a tool invocation into principal, action, resource, and context. That gives policy enough information to decide whether a call is legitimate now, for this agent, on this target, under this risk state. The article’s framing matters because the same function can be harmless in one context and dangerous in another, so static allowlists are insufficient on their own. Runtime policy has to account for identity, delegation chain, risk signals, and approval requirements before the call is executed.

Practical implication: require identity-aware policy checks for every high-impact tool invocation.

Why hooks, sandboxes, and approvals are not the same control

Hooks, sandboxes, and approvals each solve a different problem. Hooks intercept calls, sandboxes contain blast radius, and approvals add human review, but none of them automatically answer the core authorization question. A hook that logs but does not block is advisory. A sandbox can still permit an unauthorized but contained action. An approval flow can be over-accepted or mis-scoped. The architectural mistake is treating these enforcement points as interchangeable instead of composing them under a final decision service.

Practical implication: make runtime authorization the final allow or deny decision, not a side effect of other controls.

Breaches seen in the wild

• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Action-time authorization is the control plane that coding agents require. Text safety evaluates language, but agents create value by invoking tools, and that is where governance has to operate. When the execution layer is not separately authorised, a system can look compliant in chat while still producing risky side effects in runtime. The practitioner takeaway is that agent governance must move from conversation review to decision control.

The permission model for coding agents must be context-sensitive, not static. Tool name alone does not describe risk, because the same action can be acceptable in one task and destructive in another. The meaningful policy inputs are identity, target resource, task context, risk state, and delegation chain. That makes the control problem closer to runtime entitlement decisions than to prompt moderation.

Action safety exposes a wider gap in agentic IAM design. Traditional IAM assumes a subject asks for access and a system decides before action. Coding agents collapse that sequence by generating intent, selecting tools, and acting within one flow, so the governance model has to keep pace with runtime behaviour. This is where NHI governance and agentic authorisation meet: the control must be evaluated at the same speed as the action.

Logging attempted calls is as important as logging executed calls. The article correctly separates intent from impact, and that distinction matters for governance evidence. Blocked calls reveal pressure, retry patterns, and unsafe incentives even when the final action is denied. Practitioners should treat the delta between attempted and executed calls as a control effectiveness signal, not an audit afterthought.

Action-time authorization creates a distinct named gap: the runtime decision gap. Refusal in text, approval in chat, and authorisation at execution are not the same state. The runtime decision gap exists when the policy engine is not the final arbiter of tool use, so the agent can still cross from safe language into unsafe action. Teams should recognise that this is an architectural failure mode, not a tuning issue.

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.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: Authorisation Models Guide

What this signals

Runtime decisioning is the real boundary for agent safety. Coding agents make text and action diverge, so programmes that stop at prompt moderation will miss the control point that actually governs side effects. The governance question becomes whether the policy engine can deny an action before execution, not whether the model can sound safe.

Action-time authorization belongs in the same design conversation as NHI lifecycle and PAM. Agent identities are non-human identities with delegated power, and delegated power needs an explicit issuance and revocation model. That makes tool scoping, approval state, and execution logging part of identity governance rather than adjunct application security.

Tool-affordance safety gap: the useful phrase here is that agents can be conversation-safe and still execution-unsafe. In practice, that means security teams should align policy evaluation with the moment of tool use, because attempted and executed calls are not the same risk signal.

For practitioners

• Implement runtime allow or deny checks for every tool call Route each high-impact tool invocation through a policy decision service that evaluates identity, resource, task context, and current risk before execution.
• Separate chat safety from execution safety Treat refusal text as user-facing output only, and enforce a distinct policy gate for filesystem, shell, database, and MCP actions.
• Scope exposed tools to the minimum viable set Limit each agent to only the tools required for its current workflow, and remove broad access to destructive or state-changing commands.
• Log attempted and executed calls separately Capture blocked attempts, allowed calls, arguments, approval state, and side-effect metadata so reviewers can measure the gap between intent and impact.

Key takeaways

• Coding agents expose a control gap between safe-looking conversation and unsafe execution, so chat moderation alone is not enough.
• The decisive control is runtime authorization, because the agent’s tool call is where data loss and state change occur.
• Teams should separate refusal, approval, and execution evidence so they can measure whether policy actually blocks risky actions.

Key terms

• Action-time Authorization: Action-time authorization means checking whether a specific operation is allowed at the exact moment it is invoked, using the current identity, context, and policy. For AI and NHI systems, this matters because possession of a key or session should not automatically permit every downstream action.
• Tool affordance: The set of actions, systems, and data sources an agent can reach through its tools. More affordance means more operational power, but it also increases the blast radius of misalignment, prompt injection, or policy drift. In practice, tool affordance is a privilege boundary that needs governance.
• Completion Gate: A completion gate is a runtime check that prevents an agent from ending a workflow while tasks remain unresolved. It converts completion from a model preference into a system rule, which reduces false finish states and improves operational reliability.
• Attempted versus executed calls: A logging distinction that separates what an agent tried to do from what actually ran. Attempted calls reveal intent, pressure, and blocked misuse, while executed calls reveal realized impact and compliance exposure. Together they form the control effectiveness signal for runtime governance.

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 building or maturing an IAM programme, it is worth exploring.