Keys prove a machine's identity. OAuth lets a person grant limited access. Now combine them with the uncomfortable fact about agents: they operate quickly, tirelessly, and literally. An over-permissioned agent is not a theoretical risk — it is a fast one. This lesson turns Class 14 into a single operating rule.

The rule: give an agent a small key ring, not the master key. Only the credentials, scopes, and environments the current task needs. Nothing borrowed "just in case."

Why agents need smaller permissions than people

A person with broad access pauses, doubts, asks. An agent with broad access executes — across files, APIs, and deployments, in seconds, without the unease that stops a human before an irreversible click. Excess access also confuses agents: with ten tools available, the wrong one gets chosen more often.

So the small-key-ring rule is about safety *and* reliability. Fewer keys, fewer wrong doors.

The six parts of a small key ring

1. Separate development and production credentials. A test key that leaks should never endanger real users, real money, or real data. Different keys, different stores, different dashboards. 2. Use test accounts and sandboxes. A throwaway calendar, a demo repository, a sandbox payment mode. Prove the workflow where failure is cheap. 3. Start read-only. Let the agent inspect and draft before it can change anything. Read → draft → test write → limited write → production, each step earned. 4. Limit scopes and project access. One repository, not the whole organization. Calendar-read, not calendar-admin. Preview deployments, not production settings. 5. Set spend limits where available. Model, email, compute, and ad budgets all compound under automation. A cap turns a runaway loop into a stopped loop. 6. Require review for irreversible or public actions. Publishing, deleting, refunding, emailing customers, changing DNS, promoting to production — a human says yes first.

inspect → draft → test environment → limited write → production release
   ✓        ✓           ✓                  ✓               human gate

Each arrow is a decision, not an inevitability. Most agent tasks should live happily on the left side for a long time.

Three familiar examples (principles, not click paths)

Interfaces change; the boundaries don't. Apply the rule to tools you already know:

• GitHub: give the agent access to one repository, not every organization. Use branch protections on main so changes arrive as pull requests a human merges. Read issues and history freely; require review before merging or changing repository settings.
• Vercel / Cloudflare: keep preview and production separate. The agent may inspect deployments and logs and ship preview builds; promoting to production or editing production environment variables needs approval. Know which CLI identity (vercel, wrangler) the agent is using and what it can touch.
• Supabase: respect project, database, and role boundaries. The agent can read the schema and draft a migration against a development project; running it against production data, changing auth settings, or exposing a service-role key requires a human. Never let a full-access key near browser code.

In each case the pattern repeats: narrow the *where* (which project), narrow the *what* (which scopes), and gate the *irreversible* (production, public, paid).

Audit trails: know who did what

Every consequential action should answer three questions afterward: which account acted, what changed, and where is the evidence? Deployment logs, Git history, database migration records, provider dashboards — these are your receipts. Before connecting an agent to a service, confirm you know where those receipts live. An agent that acts without a trail is an agent you cannot debug or forgive.

The pre-connection checklist (keep this — MCP reuses it)

Copy this into your project before any agent connection, API key, OAuth grant, or MCP server:

## Pre-connection checklist — [service] — [date]
- Goal: [one sentence — what user outcome needs this?]
- Service and path: [API / OAuth / CLI / MCP — which one, and docs link]
- Exact permissions: [scopes, role, repositories, projects]
- Test environment: [sandbox, test account, preview project]
- Safe first action: [one read-only call to prove the connection]
- Success evidence: [log line, screenshot, file, dashboard row]
- Requires human approval: [publish, delete, spend, production, sharing changes]
- Credential home: [local .env / deployment settings / server store — never Git or browser]
- Revoke path: [where to disconnect, rotate, or uninstall]
- Owner: [who reviews this connection next month]

If you cannot fill in a line, you are not ready to connect. That is the checklist doing its job.

Practical exercise: plan one agent task's access

Finish line: a half-page access plan for one real agent task you are considering.

Include: goal, service, exact permissions requested (and one broader permission explicitly excluded), the safe test action, where success evidence will appear, and which action still requires your approval. Use the checklist above as the template.

Verify: ask the leak question from Lesson 14.2 — "if this credential leaked today, what is the worst one automated call could do?" — and the confusion question — "could the agent mistake a test target for production?" Common failure mode: development and production sharing one key or one project, so every test is secretly a production action.

Check your understanding

1. Why is excess permission both a safety and a reliability problem for agents? 2. What are the six parts of the small-key-ring rule? 3. For GitHub, Vercel/Cloudflare, and Supabase, name one thing the agent may do freely and one thing requiring approval. 4. What three questions must an audit trail answer? 5. Which checklist lines, if left blank, mean "do not connect yet"?

Completing Class 14

You began with a badge and its doors: authentication proves identity, authorization grants permission, and 401 and 403 tell you which one failed. You learned to store machine passwords as environment variables — names in code, values in the environment — and to revoke first when one escapes. You learned to read OAuth consent for what it is: a person granting limited, revocable access, planned scope by scope. And you now hold the operating rule for everything after: the small key ring.

Class 15 builds directly on it. MCP gives your agent a shelf of tools — files, databases, web fetches, project operations — and every tool is a permission. Bring the checklist. You will use it on every server before you connect it.