The security model
This page is a map rather than a claim. Each boundary below is described in full on the page it links to, and nothing here is true only on this page.
Five boundaries
Section titled “Five boundaries”| Boundary | What it protects | Where it is described |
|---|---|---|
| Workspace isolation | One company’s work from another’s | Projects and your workspace |
| Execution containment | Your machine from the coding agent running on it | The runner security model |
| Credential release | Your logins and secrets from the agent that uses them | Agent credentials |
| Approval gates | The outside world from an unattended action | The autonomy ladder |
| The record | Your ability to answer “who did this, and why” | The company profile and the audit log in administration |
Execution containment
Section titled “Execution containment”A coding agent is a program with a shell. It runs inside an operating-system sandbox that the runner proves works before every start, using a real denial rather than a version check. A machine that cannot enforce a boundary does not run an agent at all, and there is no flag that downgrades this.
The agent gets a fresh synthetic home for each attempt instead of yours, which is why your keys, your tool configuration, and your keychain are unreachable by omission. The runner, not the agent, is what pushes to your repository.
Details, including what the environment allowlist covers: the runner security model and workspaces and git.
Credential release
Section titled “Credential release”Two kinds of secret reach a run, and both are released the same way: to a single attempt, once.
- Coding-agent logins are captured from the machine that already has them, stored against your account, and staged into the attempt that needs them. The staged copy dies with the attempt. A second release for the same attempt is refused.
- Project environment values are injected into the run that needs them and are never echoed back through the interface that set them.
Pairing a runner works on the same principle. Approval happens in your browser, and you never paste a token: see pairing.
Approval gates
Section titled “Approval gates”Some actions never happen unattended, and the platform is explicit about which:
- Anything at L1 becomes an approval task and waits for you.
- Advertising spend is hard-locked to L1 and cannot be raised.
- A run that reaches its soft budget cap pauses. Raising it is an authorized, recorded act by a project owner or approver.
- Changes to your company profile are proposals until you approve them.
The record
Section titled “The record”What happened is kept, and it is meant to be readable later: the audit log for actions, profile versions for canonical context, and the initiative journey for the lineage from a decision to a shipped change. Runs record which profile version and which runtime target shaped them.
Next steps
Section titled “Next steps”- The runner security model: containment, in full.
- Agent credentials: capture, storage, and one-time release.
- The autonomy ladder: which actions require a person.