AI Agent Security: Scope, Risks, and Control Boundaries
AI agent security is the discipline of protecting systems that acquire context and then act through tools or other resources. The action layer sets the key boundary: an LLM-only or retrieval-augmented generation system does not automatically have the same execution scope as an agentic system. Before comparing risks or controls, teams need to identify where control changes hands across the model, agent harness, sandbox, credentials, network, and host integrations.
What AI agent security covers
AI agent security covers the full path from instruction to action. The execution environment is part of that path, not the whole system. In documented agent architectures, a harness or control plane can own model calls, tool routing, approvals, tracing, recovery, and run state, while a separate sandbox provides files, commands, dependencies, storage, ports, and snapshots.
That scope separates AI agent security from neighboring fields. Model security concerns the model itself. RAG security focuses on retrieved context and the systems that supply it. AI governance addresses organizational oversight, policy, and accountability. Each can matter to an agent deployment, but none replaces analysis of what the agent can execute, which resources it can reach, and which system mediates each action.
The practical unit of analysis is therefore not the product label “agent” or “sandbox.” It is a concrete flow: which entity receives an instruction, which entity selects or invokes a tool, where code runs, which resource the action reaches, and where authorization is enforced.
Define the trust boundary before naming controls
A trust boundary marks a point where different entities are in control. For an AI agent, that boundary may run through several components rather than around a single machine. The required boundary depends on the workload and its threat model: an agent that only edits an isolated test repository presents a different set of paths and impacts from one that can deploy code or call internal services.
Network location and ownership do not create implicit trust. Access should be considered in relation to a specific resource and session, including the authorization that occurs before that session begins. This matters when an apparently local path crosses into a host service, a proxy, an external API, or a control plane.
A microVM or sandbox can enforce a meaningful compute boundary without enclosing the entire agent system. Docker, for example, documents a microVM boundary with its own Linux kernel, but also documents that local stdio MCP servers run on the host and that direct mounts can expose a host working tree. A sandbox claim must therefore state both the mechanism it covers and the paths it leaves outside that mechanism.
So “runs in a VM” is not a complete AI agent security statement. It describes one boundary, but not who routes tools, what leaves the environment, where credentials exist, or which host-side services remain reachable.
Separate risks from security controls
A risk is a function of potential adverse impact and likelihood. A threat, vulnerability, or attack technique can contribute to a risk, but it is not a complete risk statement until the affected asset, plausible impact, and relevant conditions are clear.
A security control is different: it is a means of managing or modifying risk. Calling prompt injection a “control problem,” or sandboxing a “risk,” collapses categories that teams need to keep separate. Instead, ask which threat can produce which impact in this workload, then which control changes that path or its consequences.
Agent hijacking illustrates the distinction. NIST describes it as arising when trusted internal instructions are not clearly separated from untrusted external data, while also noting that risk and impact vary by task. The attack pattern is relevant, but its risk depends on the tools, resources, permissions, and consequences available in the particular agent flow.
Treat execution boundaries as separate controls
Four execution boundaries recur in AI agent security: isolation, egress, credential scope, and host integrations. Although they interact, each makes a different claim.
| Boundary | What it can establish | What it does not establish by itself |
|---|---|---|
| Isolation | Where code executes and what separates it from the host or other sessions | Which network destinations, credentials, or host services remain available |
| Egress | Which outbound destinations and protocols a policy permits | Whether every path uses that policy or what authority a permitted request carries |
| Credential scope | Where a credential value exists and which session or service may use it | Whether the code holding or invoking it is otherwise isolated |
| Host integrations | How calls cross from the agent environment into host-side tools or services | The safety of the compute, network, or credential boundary around those calls |
Isolation. A microVM can provide its own kernel and a hypervisor boundary, but that mechanism does not prove the security of the surrounding architecture. Host services, direct mounts, tool routers, and other API paths may sit outside it. For the technical layers and stated limits of one implementation, see how the microVM isolation boundary is enforced.
Egress. Egress is a policy boundary in its own right. Docker documents an outbound policy in which TCP is blocked unless an explicit destination rule permits it, while its architecture routes outbound TCP through a host proxy that uses host network configuration. The control claim must identify both the policy and the paths subject to it; “sandboxed” alone says nothing about whether internet access is denied, allowed, or routed elsewhere.
Credential scope. Credential handling is not implied by VM isolation. Docker documents several distinct states: a real credential can remain on the host while the sandbox receives a sentinel, an OAuth token can pass through into the sandbox, and a service secret can be global or scoped to one sandbox. Each state creates a different exposure boundary even if the compute boundary remains unchanged.
Host integrations. A tool call that crosses into a host service needs its own authorization and network analysis. MCP security guidance identifies token passthrough as an anti-pattern and warns that proxy-like client behavior can expose internal resources through SSRF or firewall-bypass paths. A locally reachable integration is therefore not automatically inside the sandbox’s isolation claim.
These controls should be assessed together, not merged into one label. A sandbox is not a substitute for secure architecture, because an attacker may use a reachable host service or another API path without first escaping the isolated compute environment. The AI agent sandbox boundary shows how one product describes isolation, network, credentials, event evidence, and explicit roadmap limits as separate concerns.
Distinguish evidence, assumptions, and open questions
A security claim is only as broad as its evidence. Documentation can establish a designed mechanism and its stated scope; an observable result can establish what happened on the surface that was observed. Neither amounts to proof of the whole architecture.
For example, Docker’s monitoring documentation exposes active network policy and sandbox network activity, but states that filesystem mount decisions are not available in the same log. That evidence can support a network observation; it cannot establish how every mount was selected. The unobserved part remains an assumption or an open evidence question.
The same rule applies to labels. gVisor’s security guidance notes that attackers may reach network-accessible host services or other API paths without escalating inside a container, and that a sandbox does not replace secure architecture. Evidence for virtualization or sandboxing is therefore evidence for a specified boundary, not a verdict on every surrounding path.
Teams that need a broader pre-approval perspective can review the security boundary before approval; that ainclave page describes five review dimensions and explicitly does not present the review as a certification. Teams ready to move from orientation to a practical evaluation can use the AI coding agent sandbox security checklist, which covers seven checks across isolation, egress, secrets, control-plane access, persistence, tenancy, and data location.
Evidence and product-documentation status in this article were checked on August 25, 2026. Product architectures and documentation can change, especially at the boundaries between harness and compute, host routing, credential delivery, and monitoring.
Choose the boundary that needs a stronger answer
For a concrete agent architecture, replace “Is it secure?” with a more precise set of questions: which entity controls execution, which paths cross into the host or network, where each credential can be used, and what evidence supports each boundary claim?
Name the unresolved boundary and its evidence state. From there, use the matching technical deep dive for isolation or product architecture, the broader review for approval context, or the evaluation checklist when you are ready to test controls. This keeps AI agent security tied to the actual workload rather than to a product label.