Always run AI agents within a sandboxed environment that controls and manages what resources can and cannot be communicated with, both locally and over a network.
a. Decide what your agent can connect to
For high-risk activities, the most robust approach is to run your AI agent within an isolated and disconnected environment, with access to pre-downloaded tools and information.
However, many use cases require the AI agent to communicate with external environments, systems and services including for access to the model. When this is necessary, apply sandbox isolations.
b. Define the boundaries of the sandbox
When designing a sandbox environment, think beyond the system where the:
- AI agent scaffolding runs
- AI agents commands run
- inference infrastructure is – whether local, remote or as a service
Where possible, these elements should be segregated from one another.
Instead, consider everything the agent can access or influence, whether directly or indirectly. This includes:
- Execution: between scaffolding, agent command execution sandbox and inference infrastructure
- Network: what it can remotely access
- Compute: what it can locally access
- Credentials: what identity and roles it can impersonate or otherwise have access to, intentionally or not
- Data: what data it has access to
Some autonomous AI tools, such as OpenClaw and Hermes Agent, are designed to interact with large numbers of systems and services. The wider the access, the greater the potential impact if the AI agent malfunctions unexpectedly or is compromised. To help limit the agent’s potential impact – sometime described as its ‘blast radius’, you should try to restrict access to just the resources needed for the task being performed whilst monitoring for attempts at wider access.
c. Restrict network access
Where possible, deny all inbound and outbound network traffic to the AI agent’s environment by default. Then, only allow connections that are required, using allowlists.
When selecting network sandboxing technologies, consider the security properties described in our cross domain approach and architecture guidance.
Some use cases require internet access and allowlists may not always provide the level of control or granularity required. In these cases, consider using protocol- or service-aware proxies that allow connections only by exception and require manual approval before permitting communications outside of approved scopes.
The following maturity model will help you assess your approach:
- Level 1 (lowest): unrestricted network access
- Level 2: access restricted to an allowlist of approved domains
- Level 3: access restricted to just the API of the model
- Level 4 (highest): no external network access, with the model hosted locally inside the network sandbox
d. Strengthen compute and host isolation
Many AI agent solutions include built-in sandboxing technologies. For some use cases, these may provide a sufficient level of protection. However, you should evaluate whether they are appropriate for your use case.
For higher risk activities, consider enforcing stronger isolation using additional controls and solutions.
When prompted or trained on the underlying model to do so, AI agents may be able to discover and exploit configuration issues, or potentially even vulnerabilities, in certain technical controls. If this event occurs, it could lead to a sandbox escape.
To reduce this risk, use multiple layers of isolation and control whilst regularly validating configurations, potentially via agentic AI approaches, to identify weaknesses or misconfiguration. This should include explicit prompts to not:
- connect to domains outside an allowlist
- attempt to escape the sandbox
Not all sandboxing technologies offer the same level of protection. Choose mature, trusted sandbox technologies that are designed specifically to isolate potentially malicious code and activities.
The following maturity model will help you assess your approach:
- Level 1 (lowest): no compute isolation. The AI agent runs on, or has remote access to, the host platform alongside other workloads and data
- Level 2: the agent runs on the same host as other workloads, but is constrained using kernel primitives such as process separation and OCI containers which are properly configured. A residual risk of kernel exploit breakout remains
- Level 3: the agent runs on the same host as other workloads but is isolated using virtualisation technologies
- Level 4 (highest): the AI agent runs on dedicated hardware that is separate from other workloads
e. Assign and limit an agent’s access to credentials
All agents should be assigned their own unique identity in a class which differentiates them from human or individual systems.
The credentials available to an AI agent form part of its potential ‘blast radius’ if it behaves unexpectedly.
Credentials include API keys, OAUTH grants, SSH keys and any authenticated sessions the agent can access or use. These credentials allow the agent to perform actions using the identities and permissions associated with them.
Where an agent has access to a host environment, such as a level 1 above (no compute isolation), it may also be able to use credentials that are available to the user account under which it is running.
Where possible you should restrict the credentials available to the agent. Ensure it has only the permissions it needs for the task being performed and use credentials with the shortest possible lifetime. For some use cases, a proxy can help by injecting credentials into requests without exposing the credentials directly to the agent, which ensures the agent cannot use the credentials through an unexpected endpoint it finds access to.
