PATTERN Cited by 1 source

Agent sandbox with gateway-only egress¶

Pattern¶

Give the AI agent a real sandbox (container / microVM / OS- level isolation) with full compute, tool, and filesystem access for its reasoning and tool-output post-processing — but constrain network egress to one destination: the governance gateway. Authentication flows via out-of-band metadata associated with the agent's identity, never via files / secrets inside the sandbox.

This inverts the common mental model where "sandbox the agent" means "isolate its execution so it can't hurt anything locally". The real invariant is egress control: the agent can run arbitrary code inside the sandbox, but every byte leaving the sandbox goes through the gateway.

Canonical statement¶

From the 2026-04-14 Redpanda Openclaw is not for enterprise scale post (Source: sources/2026-04-14-redpanda-openclaw-is-not-for-enterprise-scale):

"Sandboxes are right. You give all your human workforce computers after all. Giving agents computational power to achieve their goals is one of the key capabilities to how Claude Code has taken over software development. It's well known how much more efficient LLMs are at deriving insights when they can post process tool output with standard Unix commands, and sandboxes are the best way to safely enable this. However, these sandboxes need to have very limited network access so that they can only go through the gateway."

"Additionally, it is imperative that authentication is passed via out-of-band metadata associated with the agent's identity. This allows the agent to perform exactly the actions it needs through the gateway, only during that session."

Why sandboxes matter (rebuttal to "just lock it down")¶

A common naïve design is "don't give the agent a shell" — restrict the agent to a fixed tool surface (web search, database query) with no general compute. The post explicitly rejects this: LLMs are more effective when they can post-process tool output with Unix pipelines. Denying compute makes the agent weaker; the question is how to give compute safely.

The pattern's answer: give compute, restrict egress.

The three invariants¶

Egress restriction to the gateway only. The sandbox's network stack is configured (iptables, netns, CNI policy, eBPF, microVM firewall) so the only reachable destination is the gateway. DNS is proxied through the gateway. External IPs unreachable.
No credentials inside the sandbox. The agent's auth to the gateway is passed via out-of-band metadata — the runtime that launched the sandbox injects agent-session identity into the gateway's call context, not into the sandbox's environment. A compromised sandbox yields no credentials because there are no credentials to yield.
Agent-session lifetime bounds authorization. "The agent to perform exactly the actions it needs through the gateway, only during that session." Authorization is session- scoped; after teardown, the agent's identity is no longer honoured by the gateway.

The Unix-composability invariant¶

The post's design goal is keeping Unix workflow inside the sandbox. Agents running inside the sandbox should be able to use pipelines, redirection, shell utilities — the standard composable-Unix tooling — while still routing tool invocations through the gateway. The mechanism:

"We at Redpanda have a demonstration of this using our 'agentic gateway interface' or agi CLI (yes, the name is a play on that AGI) to allow the agent to invoke our AI gateway from within the sandbox, this way. [...] We use a dynamic, self-describing CLI to mediate access to external tools. This provides an interface for agents to discover and invoke services outside the sandbox, fitting cleanly into the composable Unix workflow while keeping all communication strictly governed by the gateway."

The agi CLI inside the sandbox is what lets the agent say agi salesforce.opportunity.update --id $ID --stage won in a shell pipeline while the gateway enforces policy + injects the token from the vault. See systems/redpanda-agi-cli.

Architecture¶

  [ Sandbox ]                         [ Gateway ]
  +-----------------+                 +---------------+
  | agent reasoning |                 | auth check    |
  | + tool calls    | --( only path ) |  (agent       |
  | + Unix pipelines|     via agi CLI |   identity    |
  | + shell        |                  |   from OOB    |
  | + file I/O      |                 |   metadata)   |
  |                 |                 | policy check  |
  | no credentials  |                 | token vault   |
  | on disk / env   |                 |   request     |
  +-----------------+                 +---------------+
     |                                      |
     | egress blocked except to gateway     v
     +-- (iptables / netns / microVM FW)  external
                                          service
                                          (Salesforce,
                                          GitHub, etc.)

The sandbox executes freely; the gateway is the only external-world touchpoint.

Why this isn't the bare-sandbox failure mode¶

The Openclaw- in-a-crate failure mode is "sandbox the agent with its credentials" — the dog in a crate with the documents. This pattern is "sandbox the agent without its credentials" — the credentials live in the concepts/token-vault at the gateway, not in the sandbox.

Composition with the four-component stack¶

This pattern is component #4 of the patterns/four-component-agent-production-stack:

Gateway (component #1) is the only egress destination.
Audit log (component #2) sees every egress by virtue of seeing every gateway call.
Token vault (component #3) mints the scoped credentials the gateway injects per call — never visible inside the sandbox.
Sandboxed compute (component #4) — this pattern.

The four components compose; this pattern alone (sandboxed compute without the other three) doesn't solve the problem because the compute-only restriction doesn't address credential- holding or observability.

Contrast: credentialed proxy sandbox (Fly.io)¶

patterns/credentialed-proxy-sandbox (canonicalised by Fly.io's agent-infra posts) uses a credentialed proxy at the agent-side: the proxy holds credentials, the agent runs on the other side of the proxy.

This pattern is similar but with the governance-layer additional invariants:

Gateway isn't just a credentialed proxy — it's a policy-enforcement point with per-call policy + audit log capture.
Token vault is a distinct component from the gateway (vault mints credentials out-of-band; gateway consumes).
Agent identity flows via OOB metadata so OBO works.

The two patterns are sibling instantiations of the "credentials-not-in-the-agent's-execution-environment" idea at different altitudes.

Composition with other wiki patterns¶

patterns/central-proxy-choke-point — the gateway-egress- only invariant makes the gateway a choke point for the agent's traffic.
patterns/agentic-access-control — the sandbox enforces the "no long-lived credentials in the agent's reach" property.
patterns/isolated-egress-proxy-for-user-urls — Fly.io / Cloudflare-class pattern for sandboxing user-supplied URL fetches through an egress proxy. Agent-sandbox-with-gateway- only-egress is the whole-sandbox generalisation at agent-infra altitude.

Mechanism gap¶

The 2026-04-14 source names the pattern without disclosing:

Sandbox implementation. Container (Docker / gVisor)? microVM (Firecracker)? FreeBSD jail? WebAssembly?
Egress enforcement mechanism. iptables? eBPF? CNI NetworkPolicy? microVM firewall? Userspace proxy?
Out-of-band identity transport. Sidecar token injection? Kernel-level credential passing? mTLS cert per sandbox? SPIFFE/SPIRE workload identity?
Sandbox lifecycle. Per-task? Per-session? Long-lived? Reusable with state reset?
Filesystem isolation story. What's in the sandbox filesystem, what's mounted, what's ephemeral?
agi CLI availability. Ships with ADP? Open source? Standalone?

Deferred to future Redpanda material.

Caveats¶

Sandbox escape is out of scope. The pattern assumes the sandbox is a correct isolation primitive. Real escapes (container breakout, VM escape, Spectre-class side channels) bypass the pattern.
DNS exfiltration risk. If DNS leaks outside the gateway (e.g. sandbox can query external DNS servers), agents can use DNS for covert egress. DNS-through-gateway is a structural requirement.
Stealthy egress via the gateway itself. If the gateway allows enough expressiveness in tool calls (e.g. arbitrary webhook URLs), an agent can still use legitimate gateway tools to exfiltrate data. Content filtering at the gateway (patterns/dynamic-content-filtering-in-mcp-pipeline) becomes the backstop.
Usability cost for tool developers. Every tool must be callable via the agi CLI (or equivalent gateway-aware interface). Raw SDKs that go direct to provider APIs don't work in the sandbox — they can't leave it. Ecosystem friction.
Performance overhead. Gateway-only egress adds a network hop to every external call. For latency-sensitive agent workloads, this budget is non-trivial.
OOB identity transport is the hidden complexity. The "out-of-band metadata associated with the agent's identity" is where the mechanism weight lies — the pattern only works if this substrate is correctly implemented (no TOCTOU, no identity spoofing, correct session-lifetime binding). The post doesn't walk this.

Seen in¶

sources/2026-04-14-redpanda-openclaw-is-not-for-enterprise-scale — canonical wiki introduction. Sandboxed-compute-with- gateway-only-egress as the component #4 of the four-component agent production stack. Introduces the agi CLI as Redpanda's sandbox→gateway mediator and names the "composable Unix workflow while keeping all communication strictly governed by the gateway" invariant.