In Lesson 31.2 you chose the surface. Now you decide how much power travels across it. New builders hand the agent the master key — full account access, production credentials, permission to send, publish, and delete — because setup is faster that way. That is also how a small agent mistake becomes a public incident.

The fix is an old operations idea: least privilege. Give the agent the smallest permission that lets it do its current step, and require a human gate before anything consequential.

The five controls

Scopes limit what a credential can do. A read-only market-data key cannot place orders. An OAuth token scoped to tickets:read cannot send mail. When you create the credential, you choose the scope — and the agent can never exceed it no matter what the model proposes. Scopes are your first and strongest boundary.

Read-only credentials are scopes applied as a habit. Start every new agent with read-only access. Let it inspect sources, retrieve context, and produce drafts. Writes come later, narrowly, after the read path works and the audit trail exists.

Test environments are safe copies: a preview deployment, a sandbox CRM, a test mailbox, sample data. The agent can exercise its full loop — including writes — without touching customers, money, or production records. If there is no test environment, a clearly labeled test folder, test tag, or draft queue serves the same purpose.

Dry runs are rehearsals. The agent computes exactly what it *would* do — which records it would update, which message it would send, which command it would execute — and shows the plan without executing it. Many CLIs and APIs support a --dry-run or preview flag. Use it. A dry run turns "trust me" into "read this diff."

Approval gates are the human checkpoint. Certain actions pause the loop until a named person reviews and approves. The gate states who approves, what they see, and what happens on reject. Without a gate, an agent's draft and an agent's action look identical in the logs. With one, there is a visible line: proposed versus executed.

The ladder: inspect to execute

Teach every agent to climb one rung at a time:

inspect → draft → test → propose → execute after approval

• Inspect: read-only. Read logs, read filings, list tickets, describe the current deployment. No changes.
• Draft: produce language or a plan. A reply draft, a report, a deployment plan. Nothing sent, published, or applied.
• Test: run against safe data or a preview. Test inbox, sandbox CRM, preview URL, dry-run output.
• Propose: open the change for review — a pull request, a queued post, a ticket update marked pending, a diff with a dry-run log.
• Execute after approval: a human approves, and only the approved change runs, under the narrow scope, with logging.

An agent earns each rung with evidence: clean inspect logs before drafting, good drafts before test writes, reviewed proposals before execution. Skip a rung and you lose the ability to say where things went wrong.

A concrete boundary: deploys

Make it real with a deployment agent:

• Allowed now: read deployment logs, list recent releases, create a preview deployment from a branch, run the test suite, open a pull request.
• Needs human confirmation: promoting a preview to production, changing DNS records, publishing a release announcement, rotating secrets, deleting an environment.

Read access plus preview creation is genuinely useful — the agent can investigate failures and prepare fixes all day. DNS and publish actions are consequential, hard to reverse, and public. The gate is not bureaucracy. It reflects reversibility: previews can be discarded, DNS changes propagate, publishes cannot be unseen.

Check your understanding

1. What is least privilege, and why does it start with read-only credentials? 2. What is the difference between a test environment and a dry run? 3. Name the five rungs of the permission ladder in order. 4. Why do DNS changes and publishes require a human gate while preview creation does not?

Exercise: create AGENT-PERMISSIONS.md

Write the permission contract for one agent you might actually run — a support triage agent, a research agent, or a deploy assistant.

# AGENT-PERMISSIONS.md — [agent name]

## Mission (one sentence)

## Surfaces and scopes
| Surface / tool | Credential | Scope | Read or write |
| --- | --- | --- | --- |
| | | | |

## Ladder position
- Allowed today (inspect / draft / test / propose / execute-approved):
- What evidence earns the next rung:

## Test environment
- Where safe runs happen:
- Test data / mailbox / preview target:

## Dry-run rule
- Which actions support dry-run / preview:
- Where the dry-run output is reviewed:

## Approval gates
| Action | Approver | What approver sees | On reject |
| --- | --- | --- | --- |
| e.g., production publish | | diff + preview URL + test log | |
| e.g., DNS change | | | remains draft |
| e.g., outbound send | | | queued, never sent |

## Never allowed
- [ ] send money / place trades / change prices
- [ ] publish without approval
- [ ] delete production data
- [ ] change DNS / secrets / access controls
- [ ] [your addition]

## Owner
- Human owner:
- Review cadence:

Finish line: one filled-in AGENT-PERMISSIONS.md with scoped credentials, a ladder position, a test environment, dry-run expectations, named approvers for every consequential action, and an explicit never-allowed list.

Verification: check each write permission against a test: "if the model hallucinated the inputs, what is the worst this credential allows?" If the answer involves customers, money, public claims, or production systems without a gate, narrow the scope or add the gate. Confirm the owner is a real person, not "the team."

Next, Lesson 31.4 makes every tool call leave evidence — inputs, timestamps, results, sources, changes, errors, and owners — so a future debugging session is possible.