Action-time authorization is the missing control for coding agents

At a glance

What this is: PermitIO argues that coding agents need action-time authorization because text safety and runtime safety are different control planes.

Why it matters: IAM, PAM, and NHI teams need to treat agent tool calls like governed actions, or they will miss unauthorized execution even when the conversation looks safe.

👉 Read PermitIO's analysis of action-time authorization for coding agents

Context

Action-time authorization is the point at which an agent’s tool call is allowed or denied before it executes. In coding agents, that matters because the model can produce safe-looking text while a separate runtime path still attempts a risky action. The primary governance problem is not model tone or refusal quality, but whether identity, context, and resource policy are checked at the moment of execution.

For IAM and NHI programmes, this is the same broad pattern seen in other delegated identities: the control that matters is the one closest to side effects. Tool affordance creates a privilege boundary around the agent, and that boundary needs central policy, scoped tools, and auditability. Without that, approvals and guardrails can become advisory instead of enforceable.

Key questions

Q: How should security teams implement action-time authorization for coding agents?

A: Security teams should authorize every tool call at runtime using identity, delegation, resource, and context data. The decision must block execution, not just record it. That means central policy, deterministic deny rules for dangerous actions, and explicit human approval for high-impact branches. Local hooks can help, but they are not the final control.

Q: Why do coding agents need more than text safety controls?

A: Because text safety only evaluates what the model says, while tool safety governs what the system does. A model can refuse in chat and still attempt a harmful action through a separate runtime path. When side effects matter, the control must sit at execution time, not in the conversation layer.

Q: What breaks when agent tool access is governed only by guardrails?

A: Guardrails can shape model behaviour, but they do not reliably deny execution. That creates a false sense of safety, especially when planners, parsers, or local hooks can still emit or pass through risky calls. The result is inconsistent enforcement across tools, sessions, and environments.

Q: Who should be accountable when an agent executes a harmful tool call?

A: Accountability should sit with the team that owns the policy, the tool surface, and the delegated identity. For enterprise use, that usually means IAM, security engineering, and the application owner together. If the runtime policy is advisory only, accountability is already too diffuse to be effective.

Technical breakdown

Why text safety and tool safety diverge in coding agents

Text safety measures the model’s conversational output. Tool safety measures whether a structured action is allowed to run. Those are separate control planes, which is why an agent can refuse a request in natural language and still emit a tool invocation through its planner or runtime layer. The failure usually appears when policy is enforced only on text, or when local hooks inspect the call but do not make the final allow or deny decision. In that design, the system can look compliant while still executing side effects.

Practical implication: enforce authorization on tool execution, not on the text response.

How action-time authorization should evaluate agent tool calls

A tool call should be normalised into an internal action tuple that includes the principal, the action, the resource, and the current context. That decision needs identity, delegation, risk state, and purpose data at call time, not just during initial session setup. In practice, the policy engine should answer whether this agent may perform this action on this resource in this environment, under this trust state, right now. This is the point where prompt injection becomes a policy signal rather than a prompt-quality issue.

Practical implication: bind each tool invocation to centralized identity and context-aware policy.

Why layered controls need a final policy decision

Guardrails, approval flows, MCP allowlists, and hooks all help, but none of them should be treated as sufficient alone. Guardrails shape behaviour, sandboxes reduce blast radius, approvals add human review, and hooks intercept calls locally. The missing piece is the authoritative policy decision that can block execution across tools, environments, and session states. Without that final control, organisations end up with fragmented enforcement and inconsistent risk handling across agents, IDEs, and backend systems.

Practical implication: use layered controls, but make one policy service the enforcement authority.

NHI Mgmt Group analysis

Action-time authorization is the real control plane for coding agents. Text refusal is not a security boundary when the same session can still generate a tool call with side effects. The governance mistake is treating model output as if it were the same thing as runtime authorization. Practitioners should treat every agent action as a governed event, not a conversational artefact.

Tool affordance expands the identity attack surface faster than most IAM programmes are prepared to model. Once an agent can select tools, invoke them, and act on behalf of a user or workspace, least privilege must be expressed at the action level. That makes central policy, delegation awareness, and resource-scoped controls the relevant governance model for coding agents.

Logging only successful actions is not enough to govern agentic behaviour. Blocked calls show what the agent attempted under current incentives, while executed calls show what actually changed. That delta is the most useful signal for policy tuning, incident reconstruction, and control assurance. Practitioners need both streams to understand whether the system is genuinely safe or only apparently safe.

Trust assumptions designed for human-paced approval loops fail when agents can propose and execute within the same session. The assumption that risky activity will be visible in time for review collapses when a model can plan, call tools, and retry before a human sees anything. The implication is that review cadence, not just review coverage, becomes a governance variable.

Action-time authorization belongs in the same conversation as NHI governance. Coding agents are not just application features; they are delegated identities with tool access, context, and side effects. The programme question is no longer whether the model is persuasive, but whether its runtime permissions are bounded, auditable, and revocable at the point of use.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 44% have implemented any policies to govern AI agents, even though 92% agree that governing them is critical to enterprise security.
• For a deeper framework on the control plane, see OWASP NHI Top 10 for agentic application risks and runtime misuse patterns.

What this signals

Action-time authorization will become the default architectural question for agentic software. As more coding environments let models propose and execute actions directly, teams will need to decide which decisions belong in hooks, which belong in a policy engine, and which require human approval. The governance pattern is shifting from conversation review to runtime control, which is a very different operating model for IAM and security engineering.

Identity teams should expect the same control tensions to show up across agents, service accounts, and delegated automation. The practical issue is not whether the actor is intelligent, but whether it can trigger side effects outside the visibility of existing reviews. That is why policy, audit, and revocation need to be designed around execution boundaries rather than interface boundaries.

With 98% of companies planning to deploy even more AI agents within the next 12 months, the pressure on runtime governance will increase faster than most control frameworks can adapt. The teams that are already mapping tool surfaces, approval paths, and executed-versus-attempted calls will be better positioned when agentic access becomes normal rather than exceptional.

For practitioners

• Move authorization to the tool boundary Require every agent tool invocation to pass a centralized allow or deny decision before execution. Treat local hooks and prompt rules as inputs to the decision, not as the decision itself.
• Scope exposed tools to the minimum viable workflow Expose only the tools a task genuinely requires, and keep destructive or high-impact actions behind explicit approval or stronger policy checks. Narrow tool catalogs reduce both accidental misuse and prompt-injection blast radius.
• Separate attempted calls from executed calls in audit logs Record blocked attempts, approved calls, and executed side effects as distinct events. Use the gap between attempted and executed activity to measure control effectiveness and detect persistent unsafe behaviour.

Key takeaways

• Coding agents create a distinct governance problem because text refusal does not prevent tool execution.
• The evidence points to a structural control gap, with agent behaviour already exceeding intended scope in most organisations.
• Practitioners should shift to action-time authorization, scoped tool exposure, and dual audit trails for attempted and executed calls.

Key terms

• Action-time authorization: A runtime decision that allows or denies a tool call at the moment it is about to execute. It is different from prompt filtering or post-hoc logging because it governs side effects directly. In agentic systems, this is the control that determines whether the action happens at all.
• 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.
• Central policy engine: A policy decision point that evaluates identity, context, resource, and risk before an action is executed. It provides consistent allow, deny, or allow-with-approval outcomes across tools and environments. For agentic workflows, it is the authoritative enforcement layer rather than an advisory control.
• 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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by PermitIO: Tool-Call Safety Is Not Text Safety: Why Coding Agents Need Action-Time Authorization. Read the original.