Skip to main content
ironrun is a local-first encrypted environment workspace that sits between your AI coding agent and every command it runs. It resolves your secrets from wherever they live — 1Password, Doppler, Infisical, an env file, or your shell environment — injects them into child processes, and strips every secret value back out of the output before the agent ever sees it. Your tests still get a live DATABASE_URL. The agent gets back exit_code: 0 and tests passed — and never the connection string.

​
The threat: secrets leak through normal debugging

Coding agents (Claude Code, Codex, Cursor, and others) run shell commands on your machine, and those commands can see your environment. Most of the time that’s fine. The problem is the small set of commands that print the environment:
When an agent runs one of these — often while legitimately debugging something you asked it to fix — the secret value lands in the chat transcript. From there it’s in the model’s context, it may be in the provider’s logs, and it may be in a screen recording or a shared session. You can’t un-send it, so the safe response is to rotate the credential. This isn’t hypothetical. From the Claude Code issue tracker:
“Three confirmed incidents at one operator workstation in ~6 days. Each incident forced a credential rotation. None of these are exotic — they’re shapes that came up during normal diagnosis work the model was asked to do.” — anthropics/claude-code#65122
There’s a second exfiltration path you may not have noticed. When Claude Code runs a command that uses a secret, that invocation is logged verbatim to:
These JSONL files contain every tool call, every shell command, and every piece of output — including any secret values that appeared in those outputs. They persist between sessions and across project restarts, and they’re readable by any process with access to your home directory. If you’ve ever run a command through Claude Code that touched a secret, assume that value is in those logs.

​
The solution: secrets flow in, never out

The agents don’t redact their own output, and the secret managers you already use (op run, doppler run, infisical run) inject secrets but don’t redact either. ironrun adds the missing piece: it sits between the agent and the command so secrets flow in to commands but never flow back out to the agent.
By default, an agent can use arbitrary argv only during a temporary session you explicitly trust. Strict policy commands remain available for CI, production, and sensitive projects. ironrun never has a tool that returns a secret’s value.
ironrun adds approximately 5–10 ms per command invocation: ~2 ms for provider lookup (env/envfile), up to ~100 ms for a 1Password CLI call. The redaction layer adds under 1 ms for typical output sizes.

​
Key capabilities

How it works

Deep dive into the sealed execution pipeline: secret resolution, process isolation, the rolling-buffer redactor, and encoded-secret detection.

Policy file

The full ironrun.yml reference — commands, providers, TTLs, no_network, seccomp filters, and the audit log.

Agent setup

Wire up Claude Code, Codex, and Cursor so every command they run goes through run_sealed instead of a bare shell.

MCP tools

The value-blind MCP tools ironrun exposes: run_sealed, list_commands, request_workspace_access, workspace_status, and validate_policy.

​
How ironrun compares to op run / doppler run / infisical run

Those tools resolve your secrets and inject them as environment variables — which is great, and ironrun does that too. The difference is everything that happens after the command starts printing output:
Doppler does ship an MCP server, but it gives agents direct read access to secret values — the opposite goal. ironrun’s MCP server lets agents run commands, never read secrets.

​
What ironrun protects — and what it doesn’t

ironrun keeps secrets out of:
  • printenv, env, echo $VAR, and shell-expansion tricks the agent might run
  • The agent’s chat transcript and the model’s context window
  • A screen share, recording, or screenshot of that session
  • Claude Code’s JSONL conversation logs
  • CI logs that a fork-PR author could read
ironrun does not (in v0) protect against:
  • A command that deliberately writes a secret to a file and reads it back later
  • Network exfiltration by a command running with no_network: false (the default)
  • Secrets in files the command itself creates
  • Anyone who already has direct access to the machine ironrun runs on
ironrun guards the path between the agent and the command. It is not an OS sandbox for hostile code. See the security model for the full threat model.