> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ironrun.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# ironrun: Sealed Command Execution for AI Coding Agents

> ironrun injects secrets into child processes and redacts them from all output, so AI agents can run commands without ever reading credential values.

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:

```bash theme={null}
printenv                 # dumps every env var, including secrets
cat .env                 # prints your local secrets file
echo $STRIPE_SECRET_KEY  # a normal debugging step
docker inspect web       # config blobs often contain credentials
```

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](https://github.com/anthropics/claude-code/issues/65122)

<Warning>
  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:

  ```
  ~/.claude/projects/<hash>/YYYYMMDD_HHMMSS_*.jsonl
  ```

  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.
</Warning>

## 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.

```
┌─────────────────────────────────────────────────────────────┐
│  AI agent (Claude Code, Codex, Cursor, …)                   │
│                                                             │
│   "run the test suite"                                      │
│        │                                                    │
│        ▼                                                    │
│   run_sealed({argv})   ◄── one MCP tool call               │
│        │                                                    │
└────────┼────────────────────────────────────────────────────┘
         │  ironrun takes over here
         ▼
┌─────────────────────────────────────────────────────────────┐
│  ironrun                                                    │
│                                                             │
│  1. Check the human-approved project, dev environment, and  │
│     current agent session                                  │
│  2. Resolve its encrypted environment entries               │
│  3. Run the command with those secrets injected             │
│  4. Stream output through a redactor:                       │
│        any secret value that appears  →  [REDACTED]         │
│  5. Hand back exit code + cleaned output                    │
│                                                             │
│  Agent sees:   exit_code=0, stdout="ok  tests passed"      │
│  Agent doesn't see:   DATABASE_URL=postgres://…            │
└─────────────────────────────────────────────────────────────┘
```

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.

<Note>
  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.
</Note>

## Key capabilities

<CardGroup cols={2}>
  <Card title="How it works" icon="gears" href="/concepts/how-it-works">
    Deep dive into the sealed execution pipeline: secret resolution, process isolation, the rolling-buffer redactor, and encoded-secret detection.
  </Card>

  <Card title="Policy file" icon="file-shield" href="/concepts/policy-file">
    The full `ironrun.yml` reference — commands, providers, TTLs, `no_network`, seccomp filters, and the audit log.
  </Card>

  <Card title="Agent setup" icon="robot" href="/guides/agent-setup">
    Wire up Claude Code, Codex, and Cursor so every command they run goes through `run_sealed` instead of a bare shell.
  </Card>

  <Card title="MCP tools" icon="plug" href="/mcp/overview">
    The value-blind MCP tools ironrun exposes: `run_sealed`, `list_commands`, `request_workspace_access`, `workspace_status`, and `validate_policy`.
  </Card>
</CardGroup>

## 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:

| Capability                                            | ironrun | op / doppler / infisical run    |
| ----------------------------------------------------- | ------- | ------------------------------- |
| Injects secrets as env vars                           | ✓       | ✓                               |
| Redacts secret values from output                     | ✓       | ✗                               |
| Exposes a `run_sealed` tool to agents                 | ✓       | ✗                               |
| Strict saved-command mode for sensitive work          | ✓       | ✗                               |
| One trusted development session for normal agent work | ✓       | ✗                               |
| Blocks fork-PR runs from getting secrets              | ✓       | ✗                               |
| Works across 1Password, Doppler, Infisical, env files | ✓       | each is tied to its own backend |

<Note>
  Doppler does ship an MCP server, but it [gives agents direct read access to secret values](https://docs.doppler.com/docs/mcp) — the opposite goal. ironrun's MCP server lets agents *run commands*, never *read secrets*.
</Note>

## 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

<Warning>
  ironrun guards the path between the agent and the command. It is not an OS sandbox for hostile code. See the [security model](https://github.com/generalized-labs/ironrun/blob/main/SECURITY.md) for the full threat model.
</Warning>
