Because risk often appears only when permitted actions are combined. A file read plus a network request, or a shell command plus a tool result, can become exfiltration or privilege abuse even if each step seems harmless alone. Security teams need to govern the whole action chain, not just the individual permission.
Why single tool calls are the wrong unit of analysis
Coding agents raise enterprise risk because the real security boundary is the full action chain, not the individual tool invocation. A read, write, query, or shell step can look benign on its own, yet still become harmful when the agent is allowed to combine steps, retain context, and choose the next action without a fresh human decision.
That is why a permission model built around isolated actions misses the main exposure. The risky event is often the sequence itself: collecting data, shaping it with local context, then using another tool to move, publish, execute, or exfiltrate it.
For this pattern, the relevant control question is not “Was this call safe?” but “What can this agent do by chaining safe calls together?” That shift is what turns a collection of low-risk permissions into a potentially high-risk operational path.
How safe-looking steps become unsafe outcomes
The common failure mode is privilege amplification through composition. A file read can reveal a secret, a network request can send it out, and a shell command can package or execute the result. Each step may fit policy in isolation, but the combination crosses a boundary that no single approval screen necessarily sees.
Tool output makes this worse because agents treat returned content as instruction material, not just data. Once an agent can ingest untrusted text, it may convert that text into a subsequent action, which is how prompt injection, tool poisoning, and indirect instruction abuse can turn ordinary connectivity into a control problem.
At enterprise scale, this matters because the blast radius is determined by what the agent can reach, not by whether any one permission looks excessive. A narrowly scoped tool set can still produce broad impact when the agent is allowed to chain access across files, tokens, APIs, and execution environments.
What enterprises need to govern instead
Enterprises need to govern the action graph: the allowed transitions between steps, the trust assumptions between tools, and the conditions under which one action may trigger another. That means treating the agent as an actor with effective delegated authority, not as a passive script with independent one-off permissions.
In practice, controls should focus on per-action authorisation, bounded context, explicit approval for sensitive transitions, and strong logging of the sequence, not just the call. A useful control is one that can answer, after the fact, why this step was allowed to lead to that next step.
The same principle applies to sandboxing and environment separation. If an agent can read production data, reach external services, or invoke shell execution from the same workflow, the enterprise has already collapsed multiple trust boundaries into one operational path.
Risk and Threat Considerations
Risk rises when autonomous or semi-autonomous tooling can combine benign permissions into a covert workflow for exfiltration, unauthorized execution, or privilege abuse. The danger is rarely the first action, it is the second or third action that becomes possible because the first one succeeded.
Failure mechanism: An attacker or malicious prompt influences one tool step, then relies on the agent to chain that result into a later step that escapes the intended boundary, such as sending secrets outward, invoking commands, or abusing a trusted session.
Impact: The enterprise can lose confidentiality, integrity, or execution control even when each individual tool call appears policy-compliant, and detection is harder because the activity can look like ordinary agent progress until the chain is complete.
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 | Coding agents can chain permissions into unauthorized action paths. |
| ASI02 — Tool Misuse | The question centers on safe tools becoming harmful when combined by an agent. | |
| ASI09 — Human-Agent Trust Exploitation | Agents can be steered by untrusted inputs into unsafe chained actions. | |
| Recommendation — Require per-action authorization for sensitive agent transitions and privilege escalation. Constrain tool invocation paths and validate each high-impact tool use. Insert approval checkpoints where trusted execution could be redirected by content. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Enterprise risk grows when individually safe calls combine into excess effective privilege. |
| AU-2 — Event Logging | Chained agent actions need sequence-level visibility for investigation and review. | |
| Recommendation — Limit agent access so chained actions cannot exceed intended authority. Log agent action sequences, not just individual tool calls. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The answer depends on verifying each step across trust boundaries, not assuming safe composition. |
| Recommendation — Treat every agent action transition as a trust decision that must be verified. | ||
Practitioner Guidance
What to prioritise: Review agent permissions as sequences, not as isolated entitlements. The highest-risk paths are usually read to send, read to execute, or read to transform into an external request.
What to verify: Confirm that sensitive actions require a fresh policy decision or human checkpoint when the agent crosses a trust boundary, especially where production data, credentials, or external connectivity are involved.
Common mistake: Treating “least privilege” as a static list of allowed tools instead of a dynamic control over what those tools can be combined into during a session.
Practitioner takeaway: If you can only review the individual call, you are not governing the real risk. The control objective is to bound and observe the chain of actions that turns harmless steps into a harmful outcome.