What breaks when a coding agent runs without per-action approval?

The control that breaks is not code safety but runtime authorisation. Every tool call inherits the local user’s privilege, so file edits, shell commands, and plugin or MCP actions can proceed without the pause that normally creates human review. That makes the blast radius depend on endpoint permissions, not just prompt quality or model behaviour.

What actually breaks when the agent is allowed to act on the local session

The failure is at the authorisation boundary, not the model boundary. Once the agent can execute tool calls in the current user context, it can modify files, invoke shells, and use plugins as if the user had typed the commands, so the practical control shifts from “approve each action” to “trust the workstation and its permissions.”

That changes the security question from whether the prompt was safe to whether the endpoint, account, and connected tools are allowed to do harmful things quickly. In other words, the blast radius is determined by the privileges already present on the device and in the linked integrations.

For AI Coding Agents Security Guide, that means the right mental model is sandboxing, token scope, and trust boundaries around the IDE, terminal, and CI path, not just prompt hygiene.

Why per-action approval is a control, not a usability annoyance

Per-action approval interrupts continuous execution and turns the agent into a sequence of discrete decisions. That pause is what gives a reviewer a chance to catch destructive edits, unexpected file access, credential exposure, or a tool call that looks valid in isolation but is wrong in sequence.

Without that checkpoint, the agent can chain ordinary-looking steps into a materially unsafe outcome. A single edit may be harmless, but the combined effect of many unreviewed actions can include code changes, secret access, environment manipulation, or destructive operations before anyone notices.

If the page is about AI agent governance more broadly, AI Agent Authorisation Guide is the practical companion: it frames per-action policy, just-in-time access, and human approval as the mechanism that limits what an agent may do at runtime.

What becomes the real blast-radius driver

Once approval is removed, the limit is no longer the quality of the model output. The decisive factors become the user’s local permissions, the scope of any cloud or SaaS tokens already available, the file system paths the agent can touch, and whether the tools it can reach have destructive side effects.

That is why the same agent can be merely inconvenient in one environment and highly dangerous in another. A developer workstation with broad repo and cloud access gives the agent a much wider action surface than a locked-down environment with narrow scopes, short-lived credentials, and separate approval for high-impact tools.

For runtime detection and containment, AI Agent Observability, Audit and Incident Response Guide is useful because it focuses on tracing agent actions, attributing them, and killing access when behaviour crosses the line.

Risk and Threat Considerations

Removing per-action approval creates a straightforward abuse path: the agent inherits the user’s authority, so any mistaken, manipulated, or overly broad instruction can be executed at machine speed. The risk is greatest where local users already hold powerful file, shell, cloud, or plugin access.

Failure mechanism: The control failure is the collapse of step-by-step human review, which allows a trusted execution context to be used for actions that would normally be paused, questioned, or blocked before completion.

Impact: Destructive file changes, credential exposure, unsafe plugin use, and fast blast-radius expansion become possible before a person can intervene, especially when the workstation already has broad permissions.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	Per-action approval limits agent privilege abuse at runtime.
Recommendation — Enforce per-action authorization to stop agents from using inherited privileges unchecked.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	The runtime risk hinges on credentials and tokens already available to the local session.
	AC-6 — Least Privilege	The blast radius is determined by the permissions the agent inherits from the user context.
	AU-12 — Audit Record Generation	Agent actions need traceable logs for review and incident response.
Recommendation — Rotate and scope credentials so agent sessions cannot reuse overly broad access. Restrict the local session to least privilege before allowing autonomous tool use. Log every tool call and state-changing action for later review and containment.
NIST Zero Trust (SP 800-207)	3.1 — Zero Trust Principles	The subject is a trust-boundary problem: verify each action instead of trusting session context.
Recommendation — Verify each action explicitly and do not trust inherited session authority by default.

Practitioner Guidance

What to verify: Confirm which actions are actually gated, not just which prompts are reviewed. If file writes, shell execution, secrets access, or external tool calls can proceed without a separate decision, you do not have per-action control in practice.

Decision rule: If the action can change state, touch credentials, or reach an external system, keep an explicit approval step or equivalent policy gate. Reserve continuous execution only for low-risk read-only actions that cannot widen the blast radius.

Practitioner takeaway: Treat “no per-action approval” as an authority problem, not an AI quality problem: if the local session can do damage, the agent can too.