Security & Containerization

Sandbox & Credential Isolation

Code generated by an Agent and user secrets must never reside in the same place. This is a hard requirement of secure architecture—not merely a best-practice suggestion.

Core Principle

Generated code and secrets
must never be in the same place

This is the first principle of Agent security: physical isolation between credentials and the execution environment.

What Went Wrong with the Old Approach

Traditional Architecture: Everything in One Container

Everything in One Container

Code execution, API keys, OAuth tokens, and session credentials all coexist in the same runtime environment. Whatever the Agent can see, malicious code can see too.

Prompt Injection Steals Keys in One Step

An attacker only needs to convince the Agent via Prompt Injection to run a single line of code (echo $API_KEY) to exfiltrate all environment-variable secrets. The attack chain is extremely short and nearly impossible to prevent.

The Smarter the Agent, the Worse the Problem

A more capable Agent means more powerful tool-calling abilities. Under the old architecture, this also means a larger attack surface. Model improvements do not automatically fix this problem—they actually make it worse.

The more capable the model, the more severe the security problem. This means security architecture cannot rely on the model's self-discipline—it must be guaranteed through structural design: even if the model is fully compromised, attackers should still be unable to reach credentials.

Two Credential Isolation Patterns

MODE 1

Bound to Resource

The Token is embedded into the resource access path at the time of use and never exists as a standalone variable. The Agent can use it, but can never see it.

GIT CLONE SCENARIO

The Token is injected into the remote URL at clone time:
https://token@github.com/repo.git
The Agent in the sandbox can perform push/pull operations normally, but cannot directly read or extract the Token—it is buried deep in the Git configuration, not an accessible environment variable.

Token

Injected into Remote URL

Usable but Invisible to Agent

MODE 2

Vault Proxy Pattern

Tokens are stored in a secure Vault service. Every API call from the Agent is routed through a proxy, which looks up the corresponding credential by Session ID and injects it into the request. The Agent never touches the raw Token.

MCP OAUTH SCENARIO

When the Agent initiates an MCP call, the request first reaches the proxy service. The proxy looks up the OAuth Token from the Vault using the current Session ID, injects it into the request header, and forwards the request to the target MCP server. The Agent only ever knows "the call succeeded"—it never sees a single character of the Token.

Agent Sends Request

Proxy Injects Token

Target Service

OS-Level Sandbox Isolation

Three-Layer Isolation Barrier

Filesystem Isolation

The Agent can only access files within its working directory. All other filesystem paths on the host machine—credentials, configs, and system files—are invisible.

Network Isolation

The sandbox restricts network access. The Agent cannot send data to arbitrary external services—even if it obtains a credential, it has no way to exfiltrate it.

Process Isolation

The Agent's code runs in an isolated process space with no access to other processes on the host. It can neither read other processes' memory nor send signals to them.

Three-Layer Trust Hierarchy

Layered Permission Control from Tool to Organization

TOOL

Tool-Level Trust

The finest-grained control. Certain high-risk tools—like file deletion, database writes, and email sending—require human approval each time they are used. Safe read-only operations (e.g., searching code, reading files) can be set to auto-allow.

SESSION

Session-Level Trust

The permission scope for a single conversation. At the start of a session, the user grants the Agent a specific scope (e.g., "may read/write /src but not modify /config"). The scope remains fixed for the entire session and is automatically revoked when the session ends.

GLOBAL

Global Policy

Organization-level security policy constraints. Regardless of what permissions a user grants during a session, the Agent cannot violate global policies—such as "never access the production database" or "no outbound requests to external domains." This is the ultimate safety backstop.

Structural security > Prompt-level security. Design the system so that attacks are structurally impossible—you can't rely on the model's self-discipline. Physical isolation of credentials from the execution environment, multi-layer trust control, and OS-level sandboxing are the cornerstones of running Agents safely in production.