Notifications
Clear all
Topic starter
27/06/2026 1:35 pm
TL;DR: Coding agents can refuse harmful requests in chat while still issuing risky tool calls, so text safety alone does not prevent data leakage or state-changing side effects, according to PermitIO. The control gap is structural: authorization must happen at execution time, not after the model has already planned the action.
NHIMG editorial — based on content published by PermitIO: Tool-Call Safety Is Not Text Safety: Why Coding Agents Need Action-Time Authorization
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Move authorization to the tool boundary Require every agent tool invocation to pass a centralized allow or deny decision before execution.
- 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.
- Separate attempted calls from executed calls in audit logs Record blocked attempts, approved calls, and executed side effects as distinct events.
What's in the full article
PermitIO's full blog post covers the operational detail this post intentionally leaves for the source:
- PreToolUse hook examples and permission-mode configuration patterns for coding agents
- MCP tool scoping and allowlist design details for limiting exposed actions
- Central policy enforcement flows for allow, deny, and allow-with-approval decisions
- Audit design guidance for captured attempted calls, executed calls, and side-effect metadata
👉 Read PermitIO's analysis of action-time authorization for coding agents →
Coding agents and action-time authorization: are your controls keeping up?
Explore further
27/06/2026 2:58 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Action-time authorization is the missing control for coding agents
