The three tiers

Free sample

Allow always, allow with a boundary, always ask — and where sandboxes do not help.

permissions/README.md · 2.4 KB

permissions/README.md

# Permissions

Sort commands by **blast radius**, not by how dangerous they sound.

> If this ran a hundred times with wrong arguments, what is gone?

That question produces three tiers.

## Tier 1 — Allow always

Read-only, or scoped entirely to files git already tracks.

Reads, searches, your test command, your linter, your type-checker, your
build, `git status`, `git diff`, `git log`.

Getting this tier right is what makes an agent usable. **If it has to ask
before running your tests, it will not run your tests**, and it will hand you
unverified code.

## Tier 2 — Allow with a boundary

Writes, but recoverable through git.

`git add`, `git commit`, `git checkout -b`, writing files inside the repo,
installs into the project directory, migrations against a local database.

Precondition: **clean working tree before every task.** An agent working on
top of your uncommitted changes removes the undo you were relying on.

## Tier 3 — Always ask

Anything outside the repository, or not undoable with git.

`git push` (especially `--force`), deploys, anything touching a real
database, `rm -rf` outside the working tree, publishing, `curl` piped to a
shell, anything with a credential in the arguments.

There is no version of "the agent is good enough now" that makes an
unattended `git push --force` a reasonable default.

## Using the file here

`settings.permissions.json` implements the three tiers. To install:

    # merge into .claude/settings.json
    # then replace the placeholder build commands with your own

**Edit the allow list.** It ships with common commands; the specific ones
that matter are yours (`make check`, `pnpm check`, `cargo test`).

## Maintaining it

- Approved something three times? Move it to `allow`.
- Something surprised you? Add it to `deny`.
- Review `deny` quarterly. Never review it during an incident.

## Secrets

The agent should never need to read a real credential.

- `.env` in `.gitignore` is not enough — deny reading it too.
- Give scoped test keys, never production ones.
- The realistic threat is not a malicious model. It is an agent helpfully
  pasting a key into a log line to make an error easier to debug.

## Sandboxes

A sandbox raises how much you can allow, but note two things it does not fix:

**The repository is usually mounted for real** — which is exactly the thing
still at risk.

**Network access is the whole game.** A sandbox with network can exfiltrate
whatever it can read.

That was one of 28 files

The rest of The Agent Operating Kit is written the same way. $39 once, yours permanently, 14-day refund.

# Permissions Sort commands by **blast radius**, not by how dangerous they sound. > If this ran a hundred times with wrong arguments, what is gone? That question produces three tiers. ## Tier 1 — Allow always Read-only, or scoped entirely to files git already tracks. Reads, searches, your test command, your linter, your type-checker, your build, `git status`, `git diff`, `git log`. Getting this tier right is what makes an agent usable. **If it has to ask before running your tests, it will not run your tests**, and it will hand you unverified code. ## Tier 2 — Allow with a boundary Writes, but recoverable through git. `git add`, `git commit`, `git checkout -b`, writing files inside the repo, installs into the project directory, migrations against a local database. Precondition: **clean working tree before every task.** An agent working on top of your uncommitted changes removes the undo you were relying on. ## Tier 3 — Always ask Anything outside the repository, or not undoable with git. `git push` (especially `--force`), deploys, anything touching a real database, `rm -rf` outside the working tree, publishing, `curl` piped to a shell, anything with a credential in the arguments. There is no version of "the agent is good enough now" that makes an unattended `git push --force` a reasonable default. ## Using the file here `settings.permissions.json` implements the three tiers. To install: # merge into .claude/settings.json # then replace the placeholder build commands with your own **Edit the allow list.** It ships with common commands; the specific ones that matter are yours (`make check`, `pnpm check`, `cargo test`). ## Maintaining it - Approved something three times? Move it to `allow`. - Something surprised you? Add it to `deny`. - Review `deny` quarterly. Never review it during an incident. ## Secrets The agent should never need to read a real credential. - `.env` in `.gitignore` is not enough — deny reading it too. - Give scoped test keys, never production ones. - The realistic threat is not a malicious model. It is an agent helpfully pasting a key into a log line to make an error easier to debug. ## Sandboxes A sandbox raises how much you can allow, but note two things it does not fix: **The repository is usually mounted for real** — which is exactly the thing still at risk. **Network access is the whole game.** A sandbox with network can exfiltrate whatever it can read.