The boundary between data and action breaks first. A model that can turn an external input into a command inherits privileges it should not have, which means a harmless-looking prompt or event can become code execution, credential exposure, or system modification. The fix is not better language understanding. It is strict separation between interpretation, authorization, and execution.
Why This Matters for Security Teams
When AI tools can execute local code through delegated access, the risk shifts from content misuse to action misuse. A prompt, file, ticket, or webhook can become a command path if the tool is allowed to launch processes, write files, or call internal APIs. That is why OWASP Non-Human Identity Top 10 treats delegated authority as a core control problem, not just a prompt-injection problem.
The practical issue is that these tools often operate under a human user’s context or a service account that was never designed for autonomous action. Once local execution is possible, the tool can chain permissions, reach secrets, and alter state faster than a human reviewer can intervene. The same pattern appears in NHIMG research on Gemini CLI Breach — Silent Code Execution, where execution capability created a silent trust boundary failure. In practice, many security teams discover this only after a tool has already run a destructive command or exposed credentials, rather than through intentional testing.
How It Works in Practice
The safest design separates three steps: interpretation, authorization, and execution. The model may interpret the request, but it should not directly possess broad rights to modify the host, reach secrets, or spawn arbitrary commands. Instead, every action should pass through a policy layer that evaluates what the agent is trying to do, in what context, and with which workload identity. That aligns with current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls and the identity-centric posture promoted in the Ultimate Guide to NHI.
In practice, that usually means:
- Giving the tool an identity that proves what it is, not a standing human-like login.
- Issuing just-in-time, task-scoped credentials that expire automatically after the action completes.
- Restricting local execution to a narrow allowlist of commands, paths, and files.
- Separating read access to data from write access to system state.
- Logging every requested action, policy decision, and execution result for review.
This is especially important when secrets are present on the same workstation or in adjacent CI/CD systems. NHIMG research on the DeepSeek breach shows how exposed credentials and sensitive records can compound the blast radius once a tool can execute code locally. The control objective is not to make the model “safer” in the abstract, but to make sure it cannot transform a low-trust input into a high-trust system action. These controls tend to break down when agents run inside developer laptops or shared build runners because local trust, cached credentials, and ad hoc scripts collapse the policy boundary.
Common Variations and Edge Cases
Tighter execution controls often increase operational overhead, so organisations have to balance developer speed against the risk of delegated authority. That tradeoff is real, especially when teams want agents to edit code, run tests, or fix incidents without waiting on manual approvals. Current guidance suggests that this should be done with constrained tool scopes, not blanket shell access, but there is no universal standard for exactly how granular the policy should be.
Edge cases matter. A read-only assistant becomes dangerous if it can invoke a local plugin that writes to disk. A “safe” sandbox still creates exposure if it inherits mounted secrets, SSH agents, or cloud credentials. Multi-step workflows are another weak point because a harmless first action can set up a later privileged action. That is why the 52 NHI Breaches Analysis is useful: it shows how identity abuse often begins with overbroad access that looked acceptable at design time. For teams building autonomous workflows, the lesson is to treat local execution as a privilege escalation surface, not a convenience feature.
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, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A-04 | Covers tool abuse and unsafe agent actions through delegated execution. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Delegated code execution depends on overprivileged non-human identities. |
| CSA MAESTRO | TRUST-03 | Addresses trust boundaries for autonomous agent actions and tool use. |
| NIST AI RMF | Supports governance for unpredictable AI behavior and runtime risk decisions. | |
| NIST CSF 2.0 | PR.AC-4 | Least privilege is central when AI tools can execute code locally. |
Constrain agent tools to explicit allowlists and inspect every action before execution.
Related resources from NHI Mgmt Group
- What breaks when MCP tools are treated as harmless local utilities?
- What breaks when malicious package installs are allowed to execute code by default?
- Which control matters most when AI tools have access to developer and cloud credentials?
- What breaks when repository task files are allowed to auto-execute in developer tools?
