> ## 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.
# run_sealed: Execute Commands Without Exposing Secrets
> The run_sealed tool runs commands with secrets injected below agent visibility. Returns exit code, duration, and redacted stdout and stderr.
`run_sealed` is the core tool agents use to run commands. It accepts either a policy command ID (strict mode) or an argv array (trusted workspace session mode), runs the command with secrets injected, and returns cleaned output. The agent never sees the secret values — only the results of running the command with them.
## Two modes
### Strict mode — `command_id`
Pass a `command_id` that matches an entry in `ironrun.yml`. The command runs with exactly the secrets declared in its policy entry, under whatever constraints the policy sets (TTL, network, seccomp, workdir). No trust session is required.
```
run_sealed({ "command_id": "test" })
```
Use this for CI, production, or any workflow where you want to guarantee only pre-approved commands can run.
### Trusted session mode — `argv`
Pass an `argv` array after a human has granted a workspace trust session. Any argv is accepted — this is the fast path for normal local development.
```
run_sealed({ "argv": ["go", "test", "./..."] })
```
If no trust session exists yet, `run_sealed` creates a pending request and blocks until the human approves it. The agent does not need to call `request_workspace_access` first; `run_sealed` handles the blocking wait automatically.
Exactly one of `command_id` or `argv` must be provided. Passing both, or neither, returns an error.
## Parameters
A policy command ID for strict mode. Must match an `id` in `ironrun.yml`. Do not provide `argv` when using this parameter.
The exact binary and arguments for trusted workspace session mode, for example `["npm", "test"]`. No shell, no glob expansion, no `$VAR` substitution. Do not provide `command_id` when using this parameter.
## Response
The tool always returns a text result, even when the command exits non-zero. A non-zero exit code is a valid result the agent should see and reason about — it is not treated as a tool error.
The process exit code. Zero means success; anything else is a failure from the command itself.
How long the command ran in milliseconds.
Standard output from the command, with all secret values redacted.
Standard error from the command, with all secret values redacted.
### Example response
```
exit_code: 0
duration_ms: 4231
--- stdout ---
ok myapp 4.2s
--- stderr ---
(empty)
```
If the output was cut by the `max_bytes` limit set in policy, a note is appended:
```
exit_code: 0
duration_ms: 1820
[output truncated at max_bytes limit]
--- stdout ---
...
```
If ironrun detects a high-entropy token in the output that wasn't a registered secret (and therefore wasn't redacted), it appends an advisory note — the count only, never the token:
```
[ironrun] note: 1 high-entropy token(s) in the output may be an unredacted secret
```
## Redaction
Before any output reaches the agent, ironrun runs it through a redaction layer that replaces:
* The literal secret value
* Base64-encoded forms of the value
* Hex-encoded forms of the value
* URL-encoded forms of the value
All of these become `[REDACTED]`. This means a command that prints `Authorization: Bearer sk_live_abc123` will produce `Authorization: Bearer [REDACTED]` — even if the encoding was applied by the command itself.
## What triggers a wait
| Situation | What happens |
| -------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| `require_agent_leases: true` and no active lease | `run_sealed` creates a lease request and blocks; the human sees an approval prompt |
| `argv` mode with no active workspace trust grant | `run_sealed` creates a workspace access request and blocks; the human approves with `ironrun trust grant ` |
| A secret required by the command is not configured | `run_sealed` creates a secret request and blocks; the human fulfills it via the TUI or `ironrun access fulfill ` |
| A proposed command is pending human approval | `run_sealed` blocks and resumes after the human runs `ironrun approve ` |
All blocking waits are visible in the global Inbox TUI. The agent continues to wait with no further action needed on its part.
`run_sealed` never accepts a secret value as a parameter. There is no field on this tool for passing credentials. Secrets flow from the encrypted vault into the child process environment, not through the agent.