Inside CloudThinker's Sandbox: How We Built a Secure Execution Environment for AI Agents
A technical guide to CloudThinker's sandbox: three-tier isolation, per-agent Kubernetes pods under gVisor, syscall interception, scoped credentials, and the defense-in-depth design that makes autonomous AI operations safe enough for banking, healthcare and enterprise.
Why sandbox security is the foundation of agentic AI
An agent is halfway through an incident at 3 a.m. It has queried a production database, read a security group, and is about to restart a service. Every one of those calls ran somewhere, with some credentials, on some kernel, next to some other workload. Where that "somewhere" is decides what happens if the agent is wrong, or if someone has fed it a malicious instruction through a log line.
When an AI agent executes code against your production infrastructure (querying databases, restarting services, modifying security groups), the execution environment is the single most critical security boundary in the system.
Every AI agent operation at CloudThinker runs inside a purpose-built sandbox with one goal: make autonomous AI execution safe enough for the most security-conscious organizations. It's an execution environment built for agentic workloads, where isolation, short-lived credentials and auditability are architectural primitives rather than add-ons.
Why the usual execution model breaks for agents
Most platforms treat execution as an afterthought: spin up a container, run the script, hope for the best. That model was fine for CI jobs running code a human reviewed. It breaks for agents for structural reasons.
Containers share the host kernel. A container escape is a kernel bug away, and every container on the node shares that attack surface. That's acceptable for trusted build steps. It isn't acceptable for code an AI model wrote a second ago.
Credentials live too long. The common pattern is a long-lived API key in an environment file or a secrets mount that outlives the task. Any leak, through a log line, an output or a compromised dependency, stays exploitable until someone rotates it.
The executor validates itself. If the same agent that decides on an action also checks whether the action is safe, a prompt injection that fools the first check fools the second.
State leaks between runs. Shared volumes and warm containers carry files, caches and tokens from one task into the next, and sometimes from one customer into another.
Audit is opt-in. Logging is a setting someone can forget to enable, or disable to save cost.
The sandbox is designed around each of those failures.
Three-tier isolation: organization, workspace, sandbox
Security starts with boundaries. CloudThinker uses a three-tier isolation hierarchy that separates tenants, teams and individual executions.
01Tier 1
Organization
Tenant boundary: its own SSO, RBAC, billing, audit logs, compliance settings and encryption keys.
02Tier 2
Workspace
Team boundary: its own knowledge base, skill config, agent permissions, credentials and scheduled tasks.
03Tier 3
Sandbox
Execution boundary: a Kubernetes pod under gVisor per agent, with credentials scoped to each task.
Tier 1: Organization (tenant boundary)
Each organization is a fully isolated tenant with its own SSO configuration, RBAC policies, billing, audit logs, compliance settings and encryption keys. No data crosses organization boundaries. This is enforced at the infrastructure level, not only in the application.
Tier 2: Workspace (team boundary)
Within each organization, teams work in isolated Workspaces. Each Workspace keeps its own knowledge base, skill configurations, agent permissions, connection credentials and scheduled tasks. The DevOps team's Workspace is separate from the Security team's: different knowledge, different connections, different permission boundaries.
When a skill is shared across Workspaces, only the skill definition is shared. Credentials, execution context and data access stay scoped to each Workspace. Same blueprint, isolated execution.
Tier 3: Sandbox (execution boundary)
Every AI agent runs in its own isolated sandbox, and every task inside it gets credentials scoped to that task alone, revoked when the task ends. The sandbox's filesystem belongs to that one agent: it can persist across pause and resume so a long investigation picks up where it left off, and it's deleted when the sandbox is terminated. No cross-sandbox access is possible. Each sandbox is its own Kubernetes pod under gVisor, with its own memory, storage and network stack.
Anatomy of a sandbox
CloudThinker's sandbox isn't an ordinary container. It's a Kubernetes pod running under gVisor with six security properties built into every execution: a gVisor-isolated pod, syscall interception, scoped storage, a per-tenant VPC, scoped credentials and an immutable audit trail. The first four are below; credentials and audit have their own sections.
gVisor-isolated pod
Each sandbox runs as a Kubernetes pod under gVisor, a user-space application kernel that intercepts the pod's syscalls. Ordinary containers talk to the host kernel directly and share its attack surface; agent code in a CloudThinker sandbox never does, which removes a whole class of container escape vulnerabilities.
The pod is built for agentic workloads: fast startup, minimal attack surface, and just enough capability to execute operational tasks. No root access, no shell access beyond the execution scope, no unnecessary system services.
Syscall interception
Every syscall from agent code lands in gVisor's user-space kernel first, and every sandbox enforces an allowlist-only syscall policy. Only the system calls the task needs are permitted, and everything else is blocked before it reaches the host. Even if an attacker gets code execution inside a sandbox, they can't:
- Open network sockets to unauthorized destinations
- Access the host filesystem
- Spawn unauthorized processes
- Modify kernel parameters
- Mount filesystems or access devices
Scoped storage
Filesystem state belongs to one sandbox. There's no shared filesystem between sandboxes and no path from one agent's files to another's. For long-running work the filesystem persists across pause and resume, so installed tools and partial analysis survive overnight (the OpenSandbox post covers how). When the sandbox is terminated, its storage is deleted with it.
Credentials are the exception that never persists. They live only in memory, so nothing sensitive survives a pause, and a resumed sandbox gets fresh credentials for its next task.
Per-tenant VPC
Each sandbox runs in full network isolation. There's no peering between sandboxes, no shared subnets and no lateral movement path. Each execution environment has its own network namespace with deny-all default security groups. Only explicitly allowlisted egress is permitted, and only to the endpoints the task needs.
The execution lifecycle
Every task follows an eight-stage lifecycle with a security check at each phase, from request to revocation.
01Stages 1 to 2
Guard-In
The request is sanitized, checked for PII and injection, and permission-verified.
02Stages 3 to 4
Provision
The sandbox starts or resumes with deny-all networking and short-lived credentials in memory.
03Stage 5
Execute
The task runs inside the boundary. Every call and output streams to the audit trail.
04Stages 6 to 7
Guard-Out
Outputs are filtered and schema-checked before anything is delivered.
05Stage 8
Revoke
Credentials are revoked. The sandbox pauses, or is terminated with its storage.
1. Request received. The orchestrator receives a task from a user, a schedule or an event trigger, and the request enters the execution pipeline.
2. Guard-In validation. Before anything runs, the independent Guardrails Engine validates the request: input sanitization, PII detection, prompt injection defense, schema validation and permission checks. The Guard-In agent is separate from the executing agent and doesn't answer to the orchestrator.
3. Sandbox provisioned. The agent's sandbox starts, or resumes from pause, with the right CPU, memory and network allocation. It gets an isolated network namespace with deny-all defaults.
4. Credentials injected. Short-lived, scoped credentials are injected as environment variables. They're never written to disk inside the sandbox and exist only in memory for the session.
5. Script executed. The agent runs the operational task inside the sandbox boundary. Every tool call, API request and output is logged in real time to the immutable audit trail.
6. Guard-Out validation. After execution, the Guardrails Engine validates every output: sensitive-data filtering, schema enforcement, compliance checks. No unvalidated data leaves the sandbox.
7. Results delivered. Validated results go back to the user or into the session log. The Memory layer keeps what was learned for future executions.
8. Credentials revoked. The task's credentials are revoked and its egress allowances closed. The sandbox then either pauses, keeping only its own filesystem for the agent's next task, or is terminated, which deletes its storage, network and memory with it.
Here's how that plays out for a typical request (an illustrative example). An engineer asks why a service's disk is filling up. Guard-In checks that this user may read that host group. A sandbox pod starts with a read-only credential scoped to the CloudWatch metrics and the one instance in question, with egress allowed only to those endpoints. The agent reads the disk metrics and the log directory sizes, finds a log file growing by 2GB an hour, and proposes a rotation fix. Guard-Out strips a database connection string that appeared in a log excerpt before the answer is posted. The read-only credential is revoked a few seconds later. The proposed fix, if approved, runs as a new task with a new, write-scoped credential.
Defense in depth: six security rings
The sandbox isn't a single wall. It's six independent rings of defense. An attacker would need to breach all six at once to exfiltrate data.
01Ring 0
Network
Per-tenant VPC, zero peering, private subnets, deny-all security groups.
02Ring 1
Compute
A pod per agent under gVisor, whose user-space kernel intercepts syscalls, plus memory encryption.
03Ring 2
Data
Storage scoped to one sandbox, deleted on termination, AES-256 at rest, no cross-sandbox access.
04Ring 3
Identity
Short-lived STS tokens, least-privilege IAM, RBAC-gated, session-scoped credentials.
05Ring 4
Validation
Guard-In sanitization, Guard-Out validation, PII detection, injection defense.
06Ring 5
Observability
Immutable audit trail, OpenTelemetry tracing, VPC flow logs, real-time alerting.
The key design decision is that each ring is independent. Network isolation doesn't depend on compute isolation. The validation pipeline doesn't depend on credential management. The audit trail captures everything regardless of what the other rings do. A failure in one ring doesn't cascade; the other five keep protecting.
Credential management: never trust, always scope
How credentials are handled inside sandboxes is one of the most sensitive parts of the architecture. CloudThinker uses a zero-trust credential lifecycle: credentials are always scoped, always short-lived and always revoked.
- Request. The agent requests credentials scoped to specific resources and actions.
- Retrieve. The credential manager pulls from an encrypted vault (AES-256 at rest).
- Issue. A short-lived token is generated with a least-privilege policy. Maximum TTL is the session duration.
- Inject. The token goes into the sandbox as an environment variable. It's never written to disk.
- Use. The agent uses the scoped credential to work against customer infrastructure.
- Revoke. The credential is revoked automatically when the task ends.
Key principles
Least privilege. Every credential is scoped to the minimum permissions for the task. An agent checking disk space doesn't get write access to S3. An agent reading CloudWatch metrics doesn't get EC2 instance management.
Short-lived. Credentials have a maximum TTL equal to the sandbox session. Most operations finish in seconds to minutes. No long-lived API keys are stored anywhere in the system.
Never on disk. Credentials live only in sandbox memory. They're never written to the filesystem, never logged in plaintext and never included in any output.
Automatic revocation. When a task ends, its credentials are invalidated, whether the sandbox pauses or is terminated. There's no window where orphaned credentials could be used.
Encrypted at rest. Credential storage is encrypted with AES-256 platform-managed keys. All sensitive data is encrypted before it's written to any storage layer.
Guard-In and Guard-Out: the independent safety agent
The Guardrails Engine runs as a fully independent safety agent. It doesn't answer to the orchestrator or to the executing agent. The agent that executes an action is never the agent that validates it.
Every request passes Guard-In before execution and Guard-Out after. There are no shortcuts and no unvalidated executions. Internal system operations go through the same pipeline.
| Guard-In prevents | Guard-Out prevents |
|---|---|
| Prompt injection: crafted inputs that try to steer agent behavior | Data leakage: sensitive information in execution outputs |
| PII exposure: personal data entering the execution context, masked first | Malformed responses: outputs that don't match the expected schema |
| Schema violations: requests outside expected formats and value ranges | Compliance violations: outputs that break regulatory requirements |
| Unauthorized actions: operations the requesting user isn't allowed to run | Unlogged actions: every output is captured for the audit trail |
Private network connectivity (optional)
Some organizations need private network paths between CloudThinker and their infrastructure, with no traffic over the public internet. CloudThinker supports several options. They're optional: the default uses TLS-encrypted public API connections with scoped credentials, which is enough for most cases.
01Default
Public API
TLS 1.3 to public cloud APIs with scoped credentials. Zero setup, mTLS and IP allowlisting available.
02Private path
PrivateLink / VPCE
On AWS, Azure and GCP. No public IP, and you control access through endpoint policies.
03Hybrid
Site-to-site VPN
IPSec with AES-256-GCM and BGP routing, for on-premises and multi-cloud networks.
PrivateLink / VPCE
Available on AWS, Azure and GCP. The service endpoint connection is set up at the network level, so traffic between CloudThinker sandboxes and customer resources never leaves the cloud provider's private backbone. No public IP is needed. The customer controls access through endpoint policies and can cut connectivity instantly by deleting the endpoint.
Site-to-site VPN
For on-premises infrastructure or multi-cloud environments, CloudThinker supports IPSec VPN tunnels with AES-256-GCM encryption and BGP dynamic routing. That covers data centers, private clouds and hybrid environments without a cloud-native private link option.
Who needs private connectivity
Private connectivity is usually required by:
- Banking and financial services with regulatory requirements for private network paths
- Healthcare organizations processing PHI that must not cross public networks
- Government agencies with strict network boundary requirements
- Organizations with on-premises infrastructure that isn't reachable through public APIs
Most customers run on the default TLS-encrypted public API connectivity, with IP allowlisting and scoped credentials on top.
Compliance by architecture
The sandbox isn't compliant because of policies layered on top. Its security properties are architectural primitives: they can't be turned off, bypassed or misconfigured.
| Standard | Coverage |
|---|---|
| SOC 2 Type I | Security control design review: access controls, encryption, change management and audit logging verified at a point in time. |
| SOC 2 Type II | Ongoing operating effectiveness: continuous monitoring of access controls, encryption at rest and in transit, change management, and a full audit trail over an observation period. |
Scoped by design. Credentials never touch disk, a sandbox's files are never visible to another sandbox, and terminating a sandbox deletes its storage.
Auditable by default. Every execution produces a complete, tamper-proof record. You don't need to enable logging, and you can't disable it.
Isolated by construction. Tenant separation is infrastructure-level isolation, not a software flag. Organization data can't leak because the systems can't reach each other.
Encrypted by architecture. Data is encrypted at rest and in transit. Stored data uses platform-managed AES-256 keys, and network traffic is protected by TLS 1.3.
Why this beats the usual execution model
| Typical agent execution | CloudThinker sandbox | |
|---|---|---|
| Kernel | Shared with every container on the node | gVisor user-space kernel per pod |
| System calls | Default container profile | Allowlist only |
| Credentials | Long-lived keys in env files or mounts | Short-lived, scoped, memory-only, revoked on exit |
| State between runs | Warm containers and shared volumes | Scoped to one agent, deleted on termination |
| Validation | The executing agent checks itself | Independent Guard-In and Guard-Out |
| Network | Shared cluster network | Per-tenant VPC, deny-all, allowlisted egress |
| Audit | A setting someone can switch off | Always on, immutable |
The deeper difference is what you have to trust. In the usual model, safety depends on the agent behaving well and on every operator configuring every control correctly. In the sandbox, a wrong or manipulated agent still runs inside a boundary it can't widen, with a credential that expires when it does.
Why this matters for autonomous operations
The sandbox is what makes CloudThinker's autonomous operations model viable. Without strong execution isolation, you can't safely let AI agents:
- Run diagnostic scripts against production databases
- Restart services during incident response
- Modify security groups as part of remediation
- Use customer infrastructure credentials
- Run cost optimization operations that modify resources
With it, agents can act within Auto Mode, so you decide what runs on its own and what waits for approval. Either way, every execution is isolated, scoped, validated, audited and ephemeral. Auto Mode decides whether an action waits; it never loosens the sandbox.
Deploying agentic AI without this level of execution security isn't bold; it's reckless. Asking for it isn't paranoid; it's professional.
See the sandbox in action
Every free trial includes full sandbox isolation, audit trails and the security architecture described above. A good first request is read-only:
"Check disk usage on our staging web hosts and tell me what's growing. Read only. Show me which credentials and permissions you used for the check."
Then look at the receipt:
"Show me the audit trail for that run: what you called, from which sandbox, and when the credential expired."
Start your free trial or book a demo to see secure autonomous AI execution in practice.