Why sandboxing, network isolation, and credential boundaries matter when AI agents execute real-world actions.
The Moment an Agent Crosses the Line
An AI agent becomes fundamentally different from a conventional chatbot when it can act on the world around it. It can execute commands, read files, modify repositories, access APIs, and interact with websites. These capabilities make agents useful, but they also introduce a security problem that cannot be solved by improving the model’s answers alone.
Consider an agent instructed to analyze a software project without modifying anything outside its working directory. The instruction explains what the agent should do, but it does not determine what the operating system will actually allow. If the process has broad filesystem permissions or unrestricted network access, a mistake in its decisions can quickly become a real security incident.
This distinction matters as AI systems move from generating recommendations to executing multi-step tasks. In October 2026, Anthropic described unintended model actions observed during evaluations and internal use, including cases involving software flaws, real website submissions, and attempts to get around restrictions. These examples show why an agent’s intended behavior and its actual capabilities must be treated separately. [1]
The problem is not simply that a model might produce an incorrect answer. An agent connected to real tools can turn an incorrect decision into an external action. Once it has access to a filesystem, network connection, or credential, the consequences depend partly on the boundaries surrounding that access.
Security therefore requires a different question. Instead of asking only whether an agent will follow its instructions, engineers must ask what the system will permit if it does not.
Why Instructions Are Not Security Controls
An instruction is a behavioral constraint. A security boundary is an enforcement mechanism. The two work best together, but they are not interchangeable.
A model can be told not to access a sensitive directory, send information to an external server, or execute a destructive command. Such instructions can reduce unwanted behavior, but they do not automatically remove operating-system permissions, close network connections, or revoke credentials already available to the execution environment.
This becomes especially important when an agent processes untrusted content. A webpage, repository file, issue description, or document may contain instructions that conflict with the user’s original request. This is one form of prompt injection. The content may influence the model’s decisions, but the consequences depend on which resources the agent can reach and what restrictions are enforced. [3]
A useful way to understand the problem is to separate intent, authorization, and enforcement. Intent describes what the agent is trying to accomplish. Authorization defines which actions it is permitted to perform. Enforcement ensures that actions outside those permissions are actually prevented.
These layers address different failure modes. An agent may understand a request correctly but choose an unsafe implementation. An application may approve an action without checking whether its target is permitted. An execution environment may restrict file writes while leaving outbound network connections open.
Unauthorized actions executedUnauthorized actions attempted
Measures the proportion of attempted unauthorized actions that succeed.
The equation will help quantify how often attempted unauthorized actions actually succeed. Its value depends on defining the denominator carefully and distinguishing attempted violations from completed ones.
Consider a coding agent that needs to run tests, install dependencies, and inspect source files. It may need write access to a project directory, but that does not automatically justify access to SSH keys, browser profiles, unrelated repositories, or system configuration. Similarly, permission to read a file does not imply permission to upload its contents to an external service.
The principle is straightforward. Give the agent the capabilities required for its task, not every capability available to the user running it.
Inside a Secure Agent Runtime
A secure agent runtime is the environment in which an agent’s requested operations are executed under defined restrictions. Depending on the implementation, it may use operating-system isolation, containers, virtual machines, restricted process identities, filesystem permissions, network policies, and controlled credential access.[2]
The purpose is not to make an agent incapable of useful work. It is to make the scope of its actions explicit and enforceable. A development agent should still be able to edit permitted files and run tests, but those operations should not automatically grant access to unrelated resources on the host machine.
Filesystem isolation is one of the first boundaries to establish. The runtime should define which directories can be read, which can be modified, and which must remain inaccessible. Read-only mounts and narrowly defined writable directories can reduce the consequences of unexpected commands, although their effectiveness depends on the underlying operating system and configuration.
Process isolation addresses another risk. An agent may launch a shell, interpreter, package manager, or helper program to complete a task. Restrictions must remain effective across the spawned process tree, rather than applying only to the initial process. Otherwise, a child process may inherit capabilities that the original security design intended to limit.
Check runtime security policies
Figure 1. A policy-enforced execution path for AI agent actions.
The flowchart should show an agent requesting an action, the policy layer checking its permissions, and the request either proceeding within the sandbox or being blocked. Sensitive actions may require approval, but approval should never override mandatory security restrictions.
Network isolation is equally important. Even when filesystem access is restricted, a process that can read sensitive information and make arbitrary outbound connections may be able to transmit that information elsewhere. Network controls should define which destinations are permitted and which connections must be blocked.
There is a difference between discouraging network access and enforcing its absence. Environment variables that point traffic toward a disabled proxy may stop some ordinary tools, but a program can ignore those variables or use another networking mechanism. Stronger designs enforce restrictions through mechanisms such as firewall rules or other operating-system controls.
Credential boundaries complete this picture. Agents often need tokens or API access to perform legitimate tasks, but credentials should not become unrestricted resources available to every process the agent launches. Scoped credentials, separate execution identities, or trusted services that supply secrets only to approved requests can reduce exposure.
The strongest architecture combines these controls rather than treating any one of them as sufficient. Filesystem restrictions limit what an agent can read or modify. Network controls limit where it can communicate. Process isolation constrains execution, while credential separation limits what misdirected code can do with authenticated access.
The Hidden Risk in Network Access and Credentials
Network access creates a difficult security trade-off because it is both a common requirement and a potential route for data exfiltration. An agent may need to download packages, retrieve documentation, query an API, or access a remote development service. Blocking every connection can make these workflows unusable, while allowing unrestricted outbound traffic can expose sensitive information.
A practical design begins by identifying the destinations the workload actually requires. Approved endpoints can be allowed while unnecessary outbound connections are denied. Where possible, the policy should be enforced outside the agent-generated code so that a process cannot bypass it simply by choosing a different HTTP client or opening a socket directly.
Destination restrictions also need careful design. A broad domain allowlist may permit more access than intended, particularly when a trusted service hosts user-controlled content or redirects requests elsewhere. The security policy should account for the actual connection path instead of assuming that every request to an approved service is harmless.
Credentials introduce another boundary problem. An agent that can read a secret may include it in generated output, command arguments, files, or network requests. Even if the model never receives the credential directly in its conversational context, code executed within the same environment may still be able to access it.
Keeping credentials outside the agent’s direct execution environment can help. A trusted application or credential broker can authenticate an approved request without exposing a long-lived secret to the process making it. The broker can also restrict which destinations or operations are allowed to use the credential. [4]
Pi Ii
Estimates potential loss by combining the probability and impact of individual threat scenarios.
This equation provides a simplified way to prioritize threats by considering their probability and potential impact. It is a risk-estimation model rather than a guarantee of actual loss.
No single control eliminates every risk. A sandbox may restrict direct network access but still permit an approved service that returns sensitive information. A credential broker may protect a long-lived token but still authorize an operation that exposes data. A firewall may block unauthorized destinations without preventing misuse of an approved endpoint.
The objective is to reduce the number of paths through which an unintended action can become a consequential one. Every capability granted to an agent should have a clear purpose, a defined scope, and an enforcement mechanism appropriate to the risk.
Comparing Security Controls in Practice
Different controls protect different parts of the execution environment. Instruction-level restrictions can guide behavior, application-level permissions can govern tool calls, and operating-system mechanisms can constrain what a running process can access. Their effectiveness depends on the threat model and implementation.
| Security control | What it protects | Main limitation |
|---|---|---|
| Tool permissions | Limits which tools and actions an agent can invoke. | An exposed tool may still have broader permissions than necessary. |
| Filesystem isolation | Restricts which files and directories the agent can read or modify. | Exposed mounts or incorrect permissions can leave sensitive files accessible. |
| Network restrictions | Controls outbound connections to external services and destinations. | Broad allowlists may still permit unwanted data transfers. |
| Credential isolation | Limits direct access to API keys, tokens, and other secrets. | Secrets may still be exposed through authorized operations or permitted channels. |
| Human approval | Adds oversight before sensitive or irreversible actions. | Inconsistent approval checks cannot replace technical restrictions. |
Table 1. Security Controls and Their Limitations
The table should compare each control, what it protects, and its main limitation. This will make it easier to see why a single safeguard cannot cover every possible failure.
The most important distinction is between a policy that depends on a process voluntarily following a rule and one enforced by an independent mechanism. Instructions may discourage an agent from accessing an unrelated directory, but filesystem permissions can prevent the operation even when the agent attempts it.
This does not mean that every workload requires a full virtual machine or that application-level checks are useless. The appropriate level of isolation depends on the sensitivity of the data, the capabilities available to the agent, and the consequences of a violation. A narrowly scoped internal tool may require a different design from an agent that executes arbitrary code or handles confidential customer records.
The controls should also be evaluated as a system. A restricted filesystem combined with unrestricted networking may leave a path for information to escape. A network-isolated process with broad access to local secrets may still cause damage within its environment. Layered security works because different controls address different paths, not because the same check is repeated everywhere.
| Security approach | Enforcement boundary | Trade-off |
|---|---|---|
| Instruction-only restrictions | Model behavior and generated decisions. | Easy to configure, but instructions alone cannot enforce operating-system or network restrictions. |
| Application-level permission checks | Tool calls and application-defined actions. | Provides explicit authorization, but depends on complete and correctly implemented checks. |
| OS-level sandboxing | Processes, filesystem access, and other operating-system resources. | Limits the impact of a compromised process, but does not automatically control every network destination or secret. |
| Layered runtime controls | Combines tool authorization, sandboxing, network policy, and credential isolation. | Offers broader defense in depth, but requires careful configuration and ongoing testing. |
Table 2. Comparing Security Architectures for AI Agents
A well-designed runtime should make its security assumptions explicit. Engineers should know which processes are isolated, which resources are shared, which destinations are reachable, where credentials are stored, and which actions require additional authorization. Without that clarity, a sandbox can create a false sense of security while leaving critical capabilities exposed.
Measuring Whether the Boundary Holds
Security claims should be evaluated against defined threats rather than inferred from a successful demonstration. An agent completing a legitimate task shows that the system can perform useful work. It does not establish that the same system can prevent unauthorized access under adversarial conditions.
A meaningful evaluation should define the resources that must remain protected and the actions that are forbidden. Test cases might include attempts to modify files outside an approved directory, access a restricted credential, connect to a prohibited destination, or pass sensitive data through an unapproved channel. These tests should run in a controlled environment with synthetic data and explicit authorization.
Successful violationsViolation attempts
Measures the proportion of violation attempts that do not result in a successful breach.
The formula should measure how often attempted violations are prevented. The evaluation must clearly define a successful violation and distinguish it from an attempted action that was blocked before it caused harm.
Security testing should also examine the range of paths an agent can use. A restriction that blocks one command but allows the same operation through another tool may provide less protection than expected. Testing should account for child processes, alternative execution paths, and changes in the runtime configuration.
Security must also be considered alongside usability. If a configuration blocks nearly every operation, it may appear restrictive without being practical for real work. Legitimate-task completion and false-block rate can help reveal this trade-off, provided both are measured against clearly defined test cases.
The graph should use comparable published data or results from a clearly described controlled experiment. If no defensible dataset exists, we should not invent numbers to fill the chart. We can instead use a sourced comparison or run a small, reproducible experiment and clearly label the results.
The goal is not to produce one universal security score. It is to identify which boundaries hold under which conditions, what legitimate capabilities are lost, and where additional enforcement is needed. That evidence can inform deployment decisions more reliably than a general claim that an agent is safe.
Security Must Exist Outside the Model
AI agents are becoming more capable of interacting with real systems, but greater capability does not remove the need for conventional security engineering. The more resources an agent can access, the more important it becomes to define and enforce the limits of that access.
The most reliable approach is to treat the model as one component inside a larger security architecture. Instructions communicate intent, application policies authorize actions, and the execution environment enforces restrictions independently of the model’s decisions. Network controls and credential isolation can further reduce the consequences of an unexpected action.
This approach does not eliminate every possible failure. Isolation can be misconfigured, approved services can be misused, and legitimate permissions can still be broader than necessary. Security boundaries must therefore be designed around realistic threats, tested against prohibited actions, and reviewed as the agent’s capabilities and dependencies change.
An AI agent may make decisions, interpret instructions, and initiate complex actions, but it should never define the limits of its own authority. Those limits must be enforced by the systems around it, from filesystem and network restrictions to narrowly scoped credentials. Even when an agent behaves unexpectedly, the surrounding infrastructure should prevent that behavior from becoming an unauthorized operation. This is the foundation of a security boundary that can be tested and trusted.
The central engineering lesson is that an agent should not receive unrestricted capabilities simply because it has been instructed to behave responsibly. Its environment should determine what it can access, which actions it can perform, and where its authority ends.
As AI systems move deeper into software development, enterprise workflows, and other environments containing valuable data, that distinction will become increasingly important. The objective is not to prevent agents from acting. It is to ensure that when they act, the consequences remain within the boundaries the system was designed to enforce.
References
[1] Anthropic.
Investigating unintended model actions in our evaluations and internal use, 2026.
Read source
[2] OpenAI.
Building a safe, effective sandbox to enable Codex on Windows, 2026.
Read source
[3] OWASP GenAI Security Project.
LLM06:2025 Excessive Agency.
Read source
[4] NIST.
Zero Trust Architecture, SP 800-207.
Read source
