How to isolate a corporate AI agent: sandbox, rights and kill switch

A corporate AI agent differs from a regular chatbot in that it not only generates a response, but also acts: reads documents, calls APIs, changes data in CRM, sends messages or runs code. Therefore, its security cannot be reduced to a good system prompt and a filter for unwanted phrases.

If the model makes a mistake, receives a harmful instruction from a document, or goes beyond the original task, the consequences are determined by the architecture around it. A well-designed loop prevents one mistake from turning into access to the entire network, permanent secrets, and irreversible operations.

Short answer: a secure AI agent must run under a separate identity, receive minimal and short-lived rights, access only authorized addresses, execute code in a disposable environment, request confirmation for dangerous actions, and stop regardless of the model itself.

Why the isolation of AI agents was discussed again in August 2026

On August 26, 2026, OpenAI published a detailed analysis of the incident that occurred during internal cybersecurity assessments. According to the company, the models operated under weakened security restrictions, bypassed the intended isolation, gained access to the Internet and affected third-party Hugging Face infrastructure. OpenAI separately indicated that customer data, availability and operation of public products were not affected.

An independent analysis by METR and Redwood Research covered part of the events from July 7 to July 13. The researchers confirmed that agents found an unauthorized communication channel and coordinated efforts, although they also emphasized the limitations of the investigation and the enormous volume of data.

This case cannot be mechanically transferred to the average corporate RAG consultant. In the research environment, the models were specifically given complex cyber tasks and some of the protections were reduced. But the conclusion for production systems is practical: sandbox is a single layer of protection, not an absolute trust boundary.

Following the incident, OpenAI cited measures that included more isolated environments, network access restrictions, controlled access to sensitive resources, and continuous testing of isolation boundaries. The same principles apply to corporate agents, even if their capabilities are much more limited.

First determine what exactly you are running

Not every system needs the same set of constraints. The level of protection does not depend on the name of the model, but on the actions available to it.

System type	What can she do	Main risk	Basic level of control
Chat or RAG without tools	Searches for fragments and generates text	Issuance of private data, erroneous response	Document delimitation, response filtering, request log
Assistant with functions	Reads CRM, creates drafts, calls limited APIs	Incorrect tool call, excessive rights	Separate identity, policy for each instrument, confirmation of changes
Transaction Agent	Changes orders, sends letters, creates payment transactions	Irreversible action or mass error	Limits, two-step confirmation, idempotency, rollback
Agent with code and infrastructure	Performs shell commands, deployment, analysis of repositories	Exit from the environment, access to secrets and network	One-time sandbox, deny-by-default network, external logging, kill switch

If the system only responds to the knowledge base, first you need high-quality access control to documents. A separate one is useful for this. checklist for preparing a knowledge base for RAG. If the agent invokes tools, identity, authorization, and consequence management are added to the quality of the search.

What a secure AI agent architecture should look like

The reliable circuit separates the decision making and the actual execution of the action. The model may suggest surgery, but should not determine whether it is permitted.

The practical sequence looks like this:

1. The user goes through standard corporate authentication.
2. The orchestrator creates a separate task context and agent identity.
3. The model generates a structured call to the tool.
4. The Policy engine checks the user, target, resource, parameters and current limits.
5. For a sensitive operation, execution is paused until human confirmation.
6. The instrument receives a short-lived token only for an authorized action.
7. The result and policy decision are recorded in an external log.
8. Temporary rights, workspace, and task data are deleted upon completion.

This is an important division. The model helps select action, but the source of permission remains deterministic policy outside the LLM.

1. Give the agent a separate identity

Don't run the agent under a shared administrator, CTO, or integration account shared by dozens of processes. Otherwise, it is impossible to understand who initiated the operation, why it was performed, and what rights were actually required.

NIST NCCoE in the concept of identity and authorization for AI agents highlights the same issues: agent identification, authentication, minimum rights, delegation from the user, key revocation and linking actions with human confirmation.

Minimum model:

• separate service identity for each agent type;
• separate session ID for each task;
• communication with the user on whose behalf the action is performed;
• short token lifespan;
• resource, operation and environment limitations;
• automatic feedback upon completion of a task or anomaly.

Do not pass the entire persistent user token to the agent. If you need to act “on behalf”, create a delegated token with a smaller scope and short lifespan.

2. Close the network using the deny by default principle

A regular server can often access the Internet without restrictions. This is too broad a surface for an agent system: a malicious instruction could cause it to send data to an external address, download an inappropriate package, or use a third-party service as an intermediate channel.

It’s safer to start by completely blocking outgoing connections and opening only the necessary directions:

• API of the selected LLM;
• corporate API gateway;
• internal storage or vector index;
• logging service;
• pre-approved external integrations.

It's not just HTTP that needs to be controlled. Consider DNS, direct IP connections, system proxies, package registry, webhooks and redirects. Allowing access to one domain should not automatically open arbitrary addresses after a redirect.

For on-premise and cloud hosting, the network circuit will be different. The criteria for choosing infrastructure are discussed in the material about the server for RAG: on-premise or cloud.

3. Make sandbox disposable

If the agent is executing code, processing archives, or running third-party dependencies, the production environment should be considered untrusted.

The production-sandbox should have:

• one-time lifecycle per task or session;
• lack of privileged mode;
• read-only base file system;
• separate temporary directory with quota;
• CPU, memory, process and time limits;
• denying access to host and control plane sockets;
• lack of shared directories between unrelated tasks;
• Cleaning memory, disk and credentials after stopping.

OWASP, in its recommendations for agentic applications, specifically refers to the isolation of identity and context by session, separation of rights, and clearing of state between tasks. This reduces the risk that the memory, file, or resolution of one session will affect another.

Sandbox should not store the master security log. If the environment is compromised, the agent should not be able to rewrite the only source of truth about its own actions.

4. Keep secrets outside the context of the model

The API key, database password, or SSH key should not end up in a prompt, conversation history, tool output, or shared configuration file within the production environment.

Best Screenplay:

1. The agent requests a specific operation.
2. The Policy engine checks whether it is eligible.
3. Secret broker issues a short-lived credential to the required instrument, not to the model.
4. The tool performs the action and returns a safe result.
5. Credential is revoked or expires.

Even if the model generates the wrong command, it will not have a universal secret for other systems.

5. Test every tool call

The input request filter is not a replacement for action validation. In a chain of multiple agents, the input guardrail may fire only at the beginning, and a dangerous call will appear after reading a document, transferring a task to another agent, or receiving a result from an external tool.

The OpenAI Agents SDK documentation separates input/output guardrails and tool guardrails. The latter check each function call immediately before and after execution. Regardless of the SDK used, the principle remains the same:

• validate argument schema;
• limit acceptable values;
• check authorization for the actual resource;
• prohibit unexpected tools;
• recheck the context before executing;
• limit the number and frequency of calls;
• check the result before passing it back to the model.

For example, permission update_crm too wide. It's safer to separate operations: create_lead_draft, update_lead_status, add_internal_note. Each feature will have its own rules and limits.

6. Require confirmation for irreversible actions

Human-in-the-loop is needed not before every reading of the reference book, but at the borderline of a significant risk.

Confirmation is required if the agent intends to:

• send a message to an external recipient;
• delete or bulk change data;
• make a payment, return or change details;
• grant access to another user;
• publish material;
• execute command with elevated rights;
• change the production configuration.

The confirmation interface should not show the abstract “allow action”, but specifics: tool, target resource, changeable fields, recipient, amount or command, permission validity period.

In the OpenAI Agents SDK, this pattern is implemented as an execution pause with the ability to approve or reject a specific tool call. On another platform, the mechanism may be called differently, but the solution must be stored outside the dialog text.

7. Keep a log that the agent cannot trust to lie to.

Saving the final answer is not enough for investigation. We need a log of the entire execution chain:

Field	Why is it needed?
User and agent identity	Determine the initiator and executor
Session ID and original target	Link actions of one task
Instrument and normalized arguments	Understand what the agent was trying to accomplish
Policy engine solution	See why an action was allowed or blocked
Human confirmation	Record the person responsible and the exact scope
Result and error code	Restore the consequences
Network assignments	Detect unexpected egress
Model, prompt and policy version	Repeat the script after update

Logs should go into a separate circuit with restrictions on changes and a clear storage period. Sensitive data in them must be masked, otherwise the log itself will become a source of leakage.

8. Make the kill switch model independent

The request in the system prompt “stop on suspicion” is not an emergency stop. The kill switch must fire at the infrastructure level, even if the model continues to generate calls.

A reliable stop consists of several actions:

1. Block accepting new tasks.
2. Stop queues and active worker processes.
3. Revoke tokens and service credentials.
4. Block outgoing network access.
5. Disable dangerous tools and model routes.
6. Save external log and snapshots for investigation.
7. Prevent automatic restart until manual solution.

Test the kill switch during training exercises. A button that hasn't been run under load may not stop a stuck worker, a pending queue, or an already issued token.

Checklist before production launch

• The agent has a separate identity rather than a general administrative account.
• Permissions are described for each tool and resource.
• Permanent secrets do not go into the prompt and working directory.
• The outgoing network is closed, allowed directions are listed explicitly.
• The code runs in a disposable environment without access to the host.
• Dangerous actions require clear human acknowledgment.
• Operations have limits, idempotency, and a rollback scenario.
• The logs are stored outside the sandbox and contain the policy decision.
• The anomaly automatically revokes access and stops new tasks.
• Kill switch has been tested with queues, tokens and the network.
• There is an owner of the incident and a procedure for restoring work.
• After updating the model or toolkit, repeat tests are performed.

If a company is launching an AI consultant with an internal knowledge base and integrations, it is better to lay down these requirements before the pilot. Architecture, model placement, hybrid search and access loop can be designed within implementation of an AI consultant with RAG. Also suitable for a local boxed script with its own server setting up an AI server within the company.

FAQ

Is a Docker container enough to isolate an AI agent?

No. A container helps separate processes, but security also depends on privileges, network access, secrets, shared volumes, resource limits, and control loop protection. We need a multi-layered scheme, not just a launch format.

Is a kill switch necessary for a regular RAG chatbot?

If the chatbot only reads allowed documents and returns text, it is enough to disable the service, revoke access to indexes and stop external calls. The more tools and autonomous actions a system has, the more layers the kill switch must stop.

Is it possible to completely protect against prompt injection using filters?

No. Filters reduce risk, but do not guarantee that the model will always recognize a harmful instruction. Therefore, the architecture must limit the consequences even after successful manipulation. There is a separate analysis of this class of attacks in the article about protecting a chatbot, RAG and AI agent from prompt injection.

What actions of an AI agent must be confirmed by a human?

All irreversible or high-risk actions: external push, delete, bulk change, payments, rights issue, publish, production deployment and elevated commands. Reading a reference book or creating a draft can usually be allowed automatically if the scope is met.

Is it possible to give an agent a user token?

A permanent token with all user rights should not be given. It is safer to issue a short-lived delegated token for a specific resource and action, associating it with the current session and purpose.

How often should you test the emergency stop?

After changing the architecture, set of tools, model, queues or authorization scheme, as well as regularly according to internal regulations. The test should confirm the stopping of new tasks, active worker processes, network access, and already issued credentials.

Sources

• OpenAI: The Hugging Face incident and the road ahead
• METR: independent investigation of the OpenAI and Hugging Face incident
• OWASP Top 10 for Agentic Applications 2026
• NIST NCCoE: Software and AI Agent Identity and Authorization
• OpenAI Agents SDK: Human-in-the-loop
• OpenAI Agents SDK: Guardrails