Sandboxing AI Agents: Understanding the Boundaries of Autonomous Work

🧭 Dojo Compass

Module: Finance, Risk Management and Long-Term Resilience

Focus Area: Technology, AI and Future Readiness

Learning Format: Article

AI agents are becoming increasingly capable of performing tasks on behalf of individuals and businesses. They can access information, interact with applications, execute code, manipulate files, communicate with external services, and coordinate multi-step activities with varying degrees of autonomy.

These capabilities create significant opportunities for SMEs. They also introduce a different category of operational and security risks. An agent that can take action may make mistakes, misunderstand instructions, encounter malicious information, or perform activities beyond what its human operator intended.

Sandboxing is one important approach to managing these risks. It involves placing an agent or its activities within a controlled environment that restricts what it can access and do.

This article introduces the concept of sandboxing, explains why it matters, identifies the principal issues and risks, and provides a framework for discussing sandboxing with management, employees, and internal or external technical teams.

The objective is not to turn business managers into security engineers. It is to ensure they understand the basic principles, recognize the questions that need to be asked, and appreciate that the safe use of AI agents requires more than simply choosing a reputable AI provider.

🎯 Key Challenge

Traditional software generally operates according to instructions and processes established by its developers. Although conventional software can contain vulnerabilities and behave unexpectedly, its operating parameters are usually relatively well defined.

AI agents introduce a different dimension. They may interpret objectives, decide which tools to use, interact with external information, and determine the sequence of actions necessary to complete a task.

An agent might be instructed to research potential customers, update a customer relationship management system, prepare correspondence, or modify a software project. Depending on its configuration, it may be able to access company files, communicate over the internet, execute commands, or interact with other applications.

The problem is that an agent’s actions are not necessarily limited to the immediate task as understood by its human operator.

For example:

• An agent researching customers might encounter malicious instructions embedded in a website and follow them.
• A coding agent might execute a command that modifies or deletes files outside its intended project.
• An agent with access to company systems might disclose confidential information through an external service.
• An agent might make repeated requests or initiate processes that consume substantial computing resources.
• An agent might modify data or trigger an external transaction that is difficult to reverse.

These risks can arise from malicious activity, but they can also result from ordinary mistakes, ambiguous instructions, unexpected interactions between tools, or poorly configured permissions.

The key challenge is therefore controlling the environment within which an agent operates, including the resources it can access and the actions it can perform.

This is where sandboxing becomes relevant.

A sandbox provides a degree of separation between an agent’s working environment and the wider systems and resources of the organization. Ideally, if the agent behaves unexpectedly, the consequences remain contained within the environment in which it is operating.

However, sandboxing is not a single technology or a guarantee of safety. Different products and providers implement it in different ways. Some restrict access to files, some limit network connections, and others use more comprehensive isolation involving separate virtual machines or cloud environments.

An organization should not assume that an AI service is safely sandboxed simply because its provider uses that terminology.

🥋 Dojo Solution

The Dojo proposes treating sandboxing as part of a broader framework for controlling AI agent activity.

The central principle is straightforward:

An AI agent should operate within clearly defined boundaries that are proportionate to the task it performs and the potential consequences of its actions.

Understanding this principle requires five considerations.

1. Understand what the sandbox actually isolates

A sandbox is a controlled environment that restricts an agent’s access to resources outside its permitted operating area.

Depending on its design, it might restrict access to:

• Files and folders.
• Operating system functions and commands.
• Applications and databases.
• Network connections and external websites.
• Hardware and computing resources.
• Credentials, passwords, and authentication tokens.
• Other agents and shared services.

For example, a coding agent might be permitted to read and modify files within a particular project directory but prevented from accessing personal files, confidential company documents, or production systems.

A research agent might be permitted to access approved websites but prevented from connecting to internal financial systems.

The important question is not simply whether a sandbox exists, but what it actually prevents the agent from accessing or changing.

2. Distinguish capability from permission

An agent may be technically capable of performing an action without being authorized to do so.

For example, an agent might have the technical ability to send an email, modify a database, or initiate a payment. That does not mean it should have unrestricted authority to perform those activities.

This distinction is fundamental.

Organizations should apply the principle of least privilege: an agent should receive only the access and permissions necessary to complete its assigned task, for the period during which it needs them.

A sandbox helps enforce those boundaries, but it should be supported by appropriate access controls, authentication, and approval requirements.

3. Recognize that a sandbox is not a complete security solution

A sandbox can reduce the consequences of unexpected or malicious agent behaviour, but it cannot eliminate every risk.

An agent may still access sensitive information that has been placed inside its environment. It may also be able to communicate with external services if network access is permitted.

Some sandbox implementations cover only particular activities, such as command execution, while other tools or integrations operate outside those restrictions.

This means that sandboxing must be considered alongside data protection, network security, identity management, monitoring, and human oversight.

4. Match the level of isolation to the risk

Not every agent requires the same degree of protection.

An agent summarizing publicly available information presents a different risk from one that can modify company source code, access customer records, or interact with financial systems.

The appropriate environment should reflect:

• The sensitivity of information available to the agent.
• The extent of its technical capabilities.
• The degree of autonomy it has been granted.
• The potential consequences of an error or security incident.
• The difficulty of reversing its actions.

Higher-risk activities generally require stronger isolation, narrower permissions, more extensive monitoring, and more explicit human authorization.

5. Treat sandboxing as an evolving management responsibility

AI agents, their capabilities, and the technical environments in which they operate are evolving rapidly.

A sandbox configuration that is appropriate today may not be sufficient when an agent gains access to additional tools, new integrations, or greater autonomy.

Organizations should therefore treat sandboxing as an ongoing management and security issue, rather than a one-time technical configuration.

🏗️ Putting It into Practice

SMEs do not need to design their own sandbox infrastructure to manage these issues effectively. They do, however, need to understand the risks and establish appropriate expectations for the people and providers responsible for implementing AI agents.

The following framework provides a practical starting point.

Step 1: Identify what the agent is expected to do

Begin by describing the agent’s intended purpose and activities.

For example:

• Research and summarize information.
• Read and classify company documents.
• Prepare draft correspondence.
• Access customer or supplier records.
• Write, test, or modify software.
• Execute administrative workflows.
• Interact with external applications and services.
• Delegate tasks to other agents.

The more clearly the activity is defined, the easier it becomes to determine what access and permissions are necessary.

Avoid giving an agent broad capabilities simply because they might be useful in the future.

Step 2: Identify the information and systems the agent can access

Determine what the agent can read, modify, transmit, or delete.

Consider whether it has access to:

• Public information.
• Internal company documents.
• Confidential commercial information.
• Personal or customer data.
• Financial records.
• Intellectual property and source code.
• Credentials and system configuration files.
• Production applications and databases.

It is particularly important to understand whether the agent can access information beyond the immediate workspace in which it is operating.

For example, a coding agent may be intended to work on one software project, but could potentially have access to other directories, credentials, or configuration files on the same computer.

Step 3: Understand the sandbox boundaries

Ask the technical team or provider to explain precisely what is isolated and what is not.

Useful questions include:

• Is the agent operating in a separate environment, or simply within the user’s normal computer or application?
• Can it access files outside its assigned workspace?
• Can it modify the underlying operating system or application configuration?
• Can it access the internet or communicate with external services?
• Are network connections restricted to approved destinations?
• Are other tools, extensions, or integrations operating outside the sandbox?
• Can the agent access credentials or secrets stored elsewhere?
• Can it communicate with other agents or systems?
• What happens if the agent attempts to exceed its permissions?

The answers should be sufficiently clear to establish the actual security boundaries. General assurances that an agent is operating in a secure environment are not enough.

Step 4: Establish permissions and approval requirements

Define what the agent may do independently and what requires human authorization.

A useful starting point is to distinguish between different levels of autonomy:

Level	Agent activity	Example
1. Read	Access and analyze information	Summarize internal reports
2. Prepare	Create proposed outputs without executing them	Draft customer correspondence
3. Modify	Make changes within an authorized workspace	Edit project files
4. Execute	Carry out approved actions	Send an authorized communication
5. Delegate	Assign work to other agents or services	Coordinate a multi-agent workflow

These are illustrative categories, not a universal technical standard. The important point is that permission to read information should not automatically imply permission to modify it, communicate externally, or initiate consequential actions.

For higher-risk activities, organizations should consider requiring explicit human approval.

Examples include making payments, changing financial records, sending sensitive communications, modifying production systems, or granting additional access rights.

Step 5: Consider the principal sandbox risks

Management should ensure that the technical team has considered the following issues.

Prompt injection and malicious instructions

An agent may encounter instructions embedded in websites, emails, documents, or other external information. These instructions may attempt to redirect its activities, obtain confidential information, or cause it to perform unauthorized actions.

This is commonly known as prompt injection.

A sandbox can limit the damage an agent can cause if it follows malicious instructions, but it does not necessarily prevent the agent from being manipulated in the first place.

Data leakage

An agent may have access to sensitive information and the ability to transmit it to external services.

Network restrictions, access controls, data classification, and careful management of credentials are important safeguards.

Unauthorized or unintended changes

An agent may modify or delete files, alter databases, change configurations, or trigger external processes.

Access should be restricted to the resources necessary for the task. Important systems should have appropriate backups, recovery procedures, and change controls.

Sandbox escape or failure of isolation

A vulnerability or configuration weakness may allow activity to extend beyond the intended sandbox boundaries.

The possibility of a sandbox escape is one reason why organizations should not rely on a single security control. Stronger isolation technologies, such as dedicated virtual machines or microvirtual machines, may be appropriate for higher-risk activities.

Excessive autonomy and uncontrolled activity

An agent may undertake more actions than expected, repeat tasks, delegate work, or consume excessive computing resources.

Organizations should consider limits on execution time, computing costs, repeated requests, and the number of actions or delegated tasks an agent can initiate.

Persistent information and residual access

Some environments retain files, logs, memory, credentials, or other information after a task has finished.

Management should understand what is retained, who can access it, how long it remains available, and how it is securely deleted when no longer required.

Step 6: Monitor, test, and review

Sandboxing should not be treated as a substitute for monitoring.

Organizations should have appropriate records of agent activity, including significant tool use, access to sensitive information, changes to important systems, and attempts to exceed permissions.

Before allowing an agent to perform important activities, technical teams should test how it behaves when given unexpected instructions, exposed to untrusted information, or presented with situations outside its intended task.

Where possible, testing should take place in a separate environment using non-production data.

Management should also establish a process for suspending an agent, revoking its credentials, investigating unexpected behaviour, and restoring affected systems.

The environment should be reviewed whenever an agent gains new capabilities, additional integrations, or broader permissions.

Step 7: Adopt a progressive deployment approach

For many SMEs, the most practical approach is to start with relatively low-risk activities and gradually expand the agent’s responsibilities as the organization gains confidence in its performance and security arrangements.

For example, an agent might initially be permitted to research information and prepare reports. It could subsequently be allowed to update a controlled workspace, subject to review. Only after appropriate testing and safeguards might it be permitted to execute selected actions independently.

This approach allows the organization to learn from actual use without immediately exposing important systems and information to unnecessary risk.

📌 Key Takeaways

• AI agents introduce risks beyond those associated with conventional software because they can interpret objectives, use tools, and take actions with varying degrees of autonomy.
• Sandboxing creates a controlled environment that restricts what an agent can access and do.
• The existence of a sandbox does not necessarily mean that all files, tools, integrations, or network connections are isolated.
• An agent’s technical capabilities should be distinguished from the permissions it is authorized to exercise.
• Apply the principle of least privilege: give agents only the access necessary for their tasks.
• Prompt injection, data leakage, unintended changes, sandbox escape, excessive autonomy, and uncontrolled resource consumption are important risks.
• Sandboxing should be supported by access controls, network restrictions, monitoring, testing, human approval, and recovery procedures.
• The level of protection should reflect the sensitivity of the information, the agent’s autonomy, and the potential consequences of its actions.
• SMEs can adopt AI agents progressively, beginning with lower-risk activities and expanding their capabilities as safeguards mature.
• Sandboxing is an evolving technical and management discipline, not a one-time security decision.

🌿 Reflection

Consider the AI agents currently being used or evaluated in your company.

Do you know what systems, files, and information they can access? Are they operating within controlled environments, or are they using the same permissions and resources as the employees who operate them?

If an agent encountered malicious instructions in an email or website, what could it do? Could it access confidential information, modify important files, communicate externally, or initiate transactions?

Do you know whether the sandbox actually restricts those activities, or are you relying on approval prompts and the assumption that the agent will follow its instructions?

Finally, consider whether your organization has a clear understanding of who is responsible for assessing and managing these risks. Is that responsibility assigned to management, internal IT, an external provider, or some combination of them?

The objective is not to prevent employees from using increasingly capable AI tools. It is to ensure that the organization understands the environment in which those tools operate and the boundaries within which they are permitted to act.

⚔️ Dojo Mission

Select one AI agent currently being used or considered by your company.

Ask the person responsible for its implementation, or the relevant technology provider, to explain:

1. What information and systems can the agent access?
2. What actions can it perform independently?
3. What sandbox or other isolation arrangements are in place?
4. Can it access external networks, services, or other agents?
5. What happens if it receives malicious instructions or attempts to exceed its permissions?
6. How are its activities monitored, and how can access be suspended?

If the answers are unclear, identify what additional information or technical review is needed before expanding the agent’s use.

The mission is not to conduct a technical security audit. It is to establish whether management understands the boundaries within which its AI agents operate—and whether those boundaries are appropriate for the risks involved.