Sandbox and secrets
How runs are isolated, what the coding agent may touch, and how kanman keeps secret values out of runs.
kanman lets a coding agent work on your repositories. This page describes the boundaries around that work: the sandbox each run gets, the limits your policy sets, and how secrets are handled.
One sandbox per run
Every run starts in a fresh, isolated environment:
- Fresh machine. A run never reuses another run’s workspace. When the run ends, the machine and its checkout are discarded.
- Only allowed repositories. The run can clone only the repositories and branches listed in your team’s policy (
allowed_repos). - Git access for the run’s repository. The run clones and pushes with the token of your git connection. It is handed to git as a header, never written into URLs, and removed from logs.
- No access to kanman internals. The run talks to kanman only through the kanman MCP tools, with a token that is valid for this one run and stops working when the run ends.
- A narrow tool set. The coding agent can read, search and edit files and run commands in its checkout. Claude Code runs without web search and web fetch; Codex runs in its workspace sandbox.
Coming in a later release
Repository tokens that are scoped to one repository and expire with the run.
The sandbox is part of the safety floor. It is on for every team and every preset and cannot be turned off.
What the coding agent may touch
Your team’s policy defines the scope of each run. kanman enforces it twice: while the agent works (Claude Code is stopped before it writes to a denied path, and any agent can ask first with check_policy), and again on the final diff of every attempt.
| Limit | Setting | Default |
|---|---|---|
| Repositories and branches | allowed_repos |
none until you add them |
| Paths the agent must not change | denied_paths |
infra/**, **/*.tf, .github/workflows/** (depends on the preset) |
| Maximum changed files | max_changed_files |
30 |
| Maximum changed lines | max_changed_lines |
800 |
| Budget per run | budget_run_cents |
2.00 EUR |
One path is always denied, whatever your policy says: .kanman/acceptance/**. This is where kanman keeps the acceptance specs that prove a story is done. If any commit by the coding agent touches it, the diff guard stops the run. See The outcome gate and evidence.
A change outside these limits does not go through quietly. The run stops and kanman asks in the decision inbox, for example “Path infra/alarms.tf is not allowed by policy Balanced” with the options Allow once and Reject.
Secrets: names only
kanman never stores secret values and never hands them to the coding agent.
- In the policy you list only the names of secrets a run may use (
secret_names). - In
.kanman/verify.jsonyou list only the names of CI variables (ci_var_keys) the local verification needs. The values stay in your CI system. - In the evidence pack and logs kanman does not print secret values.
If your tests need credentials, keep them in your CI settings and let CI run those tests. The outcome gate reads the CI result as one of its signals.
Warning
Do not put secret values into .kanman/acceptance.json, .kanman/verify.json, story descriptions or acceptance criteria. Everything in a story can be read by the coding agent and is sent to its model provider.
Commits and authorship
kanman stamps commit authorship itself, so every commit from a run is attributable to kanman and to the run that made it. The coding agent commits as kanman <[email protected]>; acceptance specs are committed as [email protected]. Combined with the diff guard, which also compares the spec with the version approved at Ready, a reviewer can see exactly which changes the coding agent made and verify that the acceptance spec was not edited by the implementation.
Production data and security posture
Three kinds of decisions always go to a human, no matter how your policy is configured:
- touching production data,
- changing the security posture (for example permissions, authentication or network rules),
- spending more than the budget allows.
kanman stops and asks in the decision inbox with a recommendation and two to four options. You cannot lower these to automatic. See Policies, presets and authority levels.
Self-hosted runners
With a self-hosted runner the same rules for the coding agent apply, on your hardware. The runner connects out to kanman with a workspace API token and needs no inbound ports. Treat that token like any other credential: give it its own name, rotate it, and revoke it in Settings > API if a runner host is retired. Runs on one runner share that host, so use a dedicated host or VM for it. See Run the self-hosted runner.
Related pages
Last updated: January 1, 0001
Open kanman