The AI Agent Security Problem Sandboxes Cannot Solve

The same pattern appears in developer workflows. A coding agent reads an issue containing hostile instructions, opens a credential file, and sends data to an unfamiliar host. Or it installs a package named in untrusted content. Or it force-pushes a protected branch because the task context made that look like the fastest fix.
This is where static permission models start to strain. NIST has been highlighting the identity and authorization problem around agentic AI, including the risks created by long-lived credentials, broad API access, and autonomous software acting across multiple systems. The issue is not that identity stops mattering. It is that identity answers only part of the question.
That is why agent security needs a control point between deciding and doing.
None of these controls replaces the others. A sandbox does not replace identity. Identity does not replace authorization. Monitoring does not replace enforcement. Human approval does not replace good defaults.
Useful agents are full of intentional openings. We mount working directories. We provide network access. We inject credentials. We connect SaaS applications. We let agents call browsers, databases, Git repositories, cloud APIs, ticketing systems, and internal services.
The security decision therefore needs more context than identity alone.

The failure happens outside the box

Identity tells you who or what is acting. Policy still has to decide whether this action is allowed.
A support agent may be authorized to issue refunds. A coding agent may be allowed to push branches. An operations agent may have permission to change cloud configuration. An assistant may be connected to email, documents, calendars, or a CRM.
git push --force origin main is not the same decision.
The policy does not have to be enormous. A practical system can begin with a few questions:
OWASP’s AI Agent Security Cheat Sheet calls out this class of risk directly: tool abuse, privilege escalation, prompt injection, data exfiltration, and high-impact actions that need independent validation before execution. Its guidance also separates decision-making from execution for destructive or externally visible operations.
That difference matters during incident response. It is much easier to reconstruct a failure when the system records both the attempted effect and the authorization decision that preceded it.
For a sensitive action, useful policy inputs include the actor, tool, target resource, normalized parameters, destination, task, data sensitivity, reversibility, and whether the operation changes external state. The same command or API may be low risk in one context and unacceptable in another.

Authorization needs action context

Safe actions should continue without unnecessary friction. Obviously dangerous actions should stop. Ambiguous actions should request review. The user should not need to become a security engineer just to use an AI assistant.
A service account can often be scoped around a narrow, predictable job. An agent may legitimately have several permissions and combine them differently from one task to the next. The individual grants can all be reasonable while the sequence is not.
Prompt injection makes the circularity obvious. If untrusted content has influenced the model into proposing a dangerous action, asking the same reasoning process to approve itself does not create an independent security boundary.
The point is not to remove autonomy. It is to stop treating autonomy as unlimited authority.

Those connections are not mistakes. They are the reason the agent can accomplish anything outside a demo.
The most useful mental model is to treat consequential agent actions like transactions.

The model should not approve itself

That distinction is important. Sandboxing is about containing execution. Authorization is about deciding whether a particular use of authority is appropriate now.
Should this exact action be allowed to happen?
For high-impact agent systems, that decision should be explicit, contextual, independently enforced, and made before the tool call.
The control plane should be boring.
Reading a project README is routine.

• Is the action read-only or state-changing?
• Is the target local, remote, sensitive, or production?
• Is the destination expected?
• Does the action match the task the user actually assigned?
• Is the operation reversible?
• Does it cross a threshold that requires human approval?
• What happens if policy evaluation is unavailable?

For consequential operations, the final decision needs to be enforced by something outside the model’s free-form reasoning.

Treat effects as transactions

Traditional least privilege remains necessary. It is not sufficient for an agent that chooses actions dynamically.
git push is routine.
A sandbox can constrain where code executes. It can limit filesystem access, network access, processes, and resource consumption. Those controls matter, especially when an agent is compiling unknown code or running an untrusted workload.
The industry spent the first phase of AI security focused heavily on what models say. Agentic systems force us to care just as much about what models can cause.
A raw tool log tells you what command or API call occurred. A decision record can tell you why it was allowed, which policy applied, what context was considered, whether a person approved it, and what would have happened if the check failed.
Issuing a refund to the account tied to the current ticket is different from sending ,000 to a new destination.

What a practical control plane looks like

A sandbox can reduce the blast radius of execution. Strong identity can reduce credential abuse. Monitoring can make behavior visible. But when an agent is about to modify production, move money, send private data, install software, or change a shared system, the final question is still the same:
This also improves auditability.
That can be a useful signal. It should not be the final control for a destructive, financial, administrative, or externally visible action.

• Use sandboxes when the risk is untrusted execution.
• Use scoped, short-lived credentials where the agent needs access to external systems.
• Keep tool contracts narrow and explicit.
• Evaluate consequential actions before they execute.
• Require human approval for operations where business impact, data sensitivity, or irreversibility crosses a defined threshold.
• Record the decision in a structured form that can be audited later.

Once a model is connected to tools with real authority, the critical security event is no longer the output token. It is the transition from a proposed action to an external effect.
None of those permissions are inherently wrong. The failure happens when untrusted context convinces the agent to use a valid permission for the wrong purpose.

The security boundary moves with the action

But the moment an agent is useful enough to act on real systems, the hard question changes. The risk is no longer only whether the agent can escape its environment. It is whether a legitimate tool call should be allowed to create a real-world effect.
The most practical architecture is usually layered.
The architecture works when those boundaries reinforce each other.
Consider a support agent that can read tickets and call a billing API. A customer message contains an indirect prompt injection telling the agent to refund a different account. The agent does not need to break out of a container. It only needs to misuse two tools it was intentionally given.
OWASP now recommends this kind of action-bound approval for high-impact agent operations. The pattern is familiar from other security domains because it works: separate the party proposing an action from the mechanism that authorizes and executes it.
One tempting design is to ask the model whether its own proposed action is safe.