The Sandbox for the Agentic Era: Inside ironsh/irons

How a Go-based CLI and a specialized egress proxy are replacing local environment variables with boundary-level secret injection to secure autonomous coding agents.

7 min read • View on GitHub • More from ironsh

A close-up of a heavy steel safe with its door wide open, revealing a glowing holographic placeholder token instead of physical valuables. A mechanical hand reaches for the hologram, illustrating the concept of replacing plaintext secrets with boundary-level injected tokens.
By swapping real credentials for proxy tokens, irons ensures sensitive keys never touch the agent's local disk.
Key Takeaways

Giving an autonomous coding agent raw internet access and a plaintext .env file is a massive security vulnerability. A single successful prompt injection can lead to complete data exfiltration. If an agent is compromised, it can simply read the local environment variables and use a basic network request to send critical API keys to an external server.

The ironsh/irons CLI introduces a paradigm shift for this specific threat vector. It solves the exfiltration problem by moving secrets off the execution environment entirely. It creates a secure, default-deny sandbox tailored specifically for autonomous machines.

Boundary-Level Secret Injection

The secret-swapping proxy flow intercepts outbound requests and injects real credentials at the network boundary.

The core innovation of the irons architecture lives in its API client layer and the accompanying iron-proxy. The AI agent is given a proxy token instead of a real API key. When the agent makes an outbound request to an external service, the proxy intercepts the packet.

The proxy pauses the transaction, injects the real credential into the authorization header, and forwards the request to its destination. The agent never possesses the real key. Even if the agent turns malicious, it only has access to a meaningless placeholder token that is useless outside the sandbox network.

The Default-Deny Chokepoint

A wide shot of a medieval fortress with a single fortified drawbridge. A toll collector meticulously inspects the papers of departing mechanical courier pigeons against a thick ledger, representing strict egress control.
The egress manager ensures agents can only communicate with explicitly approved destinations.

Beyond credential management, the system enforces a strict egress firewall. The cmd/egress.go implementation dictates that the environment is default-deny. Outbound network access is strictly limited using FQDN and CIDR block allowlists.

Developers can toggle between enforcement and warning modes during testing. This allows teams to audit exactly what endpoints an agent attempts to contact before locking down the production sandbox.

The Human-in-the-Loop Multiplexer

A secure sandbox is useless if engineers cannot observe the agent's behavior. The irons attach command utilizes a specialized pseudo-terminal proxy to solve this visibility problem.

By dropping the human developer directly into the agent's active tmux session, the multiplexer allows real-time observation. Engineers can course-correct the agent or supply manual inputs without terminating the underlying process.

The Sandbox Landscape

While standard cloud VMs provide compute and container runtimes offer filesystem isolation, few tools address the specific network-level vulnerabilities of autonomous agents.

FeatureLocal DockerCloud VM (EC2)ironsh/irons
Secret StoragePlaintext .envPlaintext .env / Metadata ServiceBoundary Injection Proxy
Egress ControlAllow AllSecurity Group (IP only)Default-Deny (FQDN + CIDR)
Audit TrailNoneVPC Flow LogsPer-request JSON
Human Attachabilitydocker execSSHNative PTY Multiplexer