# Agents

Give each coding agent its own sandbox, a token scoped to it, and a signed record of what it did.

An agent works in a sandbox the way an engineer works in production: it deploys, signs in, reads mail, runs jobs and reads logs. It holds a **sandbox token**, which reaches one sandbox and nothing else, and every call it makes is recorded against the person it acts for.

## Hand over a sandbox [#hand-over-a-sandbox]

Create the sandbox with your project token, then give the agent the sandbox token that `parity up` prints once:

```sh title="Terminal"
parity up --sandbox fix-invite-expiry --ttl 4h
# → "token": "pst_t7acme-fix-invite-expiry_…"
```

Start the agent with that token. With a sandbox token, every command targets its sandbox, and `parity up` updates it in place:

```sh title="Terminal"
PARITY_API=https://api.parity.ninja PARITY_TOKEN=pst_t7acme-fix-invite-expiry_… claude
```

Or connect it over MCP, remote or local; see [MCP](/reference/mcp):

```sh title="Terminal"
claude mcp add parity -e PARITY_API=https://api.parity.ninja -e PARITY_TOKEN=pst_… -- parity mcp
```

## What the agent does [#what-the-agent-does]

A typical loop, in CLI or MCP terms:

1. `parity up` / `sandbox_sync` after each change, and `sandbox_status` until `ready`.
2. Drive the app through its public URL, `https://web--fix-invite-expiry--t7acme.env.parity.ninja`.
3. Create users with `parity auth user create ana@acme.test --org acme --role admin`, or through the app's own sign-up, and sign in with a one-time link from `parity signin ana@acme.test`.
4. Wait for mail with `parity inbox wait --to bob@acme.test` and follow its links and codes.
5. Run jobs with `parity run digest`, and debug with `parity logs` and `parity exec`.
6. Attach evidence with `parity proof add` and export a signed bundle with `parity proof export`.

Every command prints JSON. Over MCP, no call waits more than about 50 seconds; a tool still waiting returns a `next` hint.

## What a sandbox token cannot do [#what-a-sandbox-token-cannot-do]

| Action | Sandbox token |
| --- | --- |
| Use, update and destroy its own sandbox | Yes |
| Reach another sandbox | No: `wrong_sandbox` before any lookup |
| Create sandboxes | No |
| Promote, freeze, change members or domains | No |
| Reveal secret values, reach the production database, exec in production | No, whatever the person's role |
| Widen the egress allowlist | No: a host the promoted manifest doesn't list stays blocked |
| `parity exec` | Only when `sandbox.agent_exec` is true (the default) |

An agent never has more access than the person it acts for. See [Permissions](/security/permissions).

## Proof for reviewers [#proof-for-reviewers]

`parity proof export` writes a zip with the files the agent attached, every API call made against the sandbox and its result, and the person and agent behind them. Parity signs it; `parity proof verify proof.zip` checks the signature against the published keys (`GET /v0/keys`) and exits non-zero if any file changed.

```sh title="Terminal"
parity proof add screenshots/ test-output.txt --note "Invite link expires after 7 days"
parity proof export --result pass --summary "Invites expire; expired links show the resend page" -o proof.zip
```