Lessons 88.1 and 88.2 gave your workflow ears (events) and a home (platform or code). Now you hand it keys — and keys are where quiet disasters start. A workflow with your master API key and full mailbox access doesn't just do its job; it can do anything you can do, at machine speed, while you sleep. This lesson makes its power small on purpose.

The vocabulary, in plain language

• Scope: the precise list of what a credential may do — "read contacts, create contacts" rather than "full CRM admin." Scopes are the job description.
• Least privilege: give each actor the smallest power that completes its job — nothing borrowed, nothing "just in case."
• Service account: a non-human identity for the workflow — automation-billing@ rather than your personal login. When the workflow acts, the log shows the service account, not you.
• Secret manager: the vault where keys live — the platform's credential store, a cloud secret manager, or environment variables on your server. Never in chat logs, screenshots, or pasted code.
• Rotation: replacing a secret on a schedule or after any exposure — like changing locks, not because you were robbed but so old copies stop working.
• Audit log: who used which credential to do what, and when. Without it you cannot answer "what happened?"
• Revoke: killing a credential instantly when it leaks, misbehaves, or is no longer needed.

The mental model: a hotel key card, not a master key. The cleaner's card opens the rooms on today's list, expires Friday, and every door logs when it was used. Nobody hands the cleaner the master key "to be safe."

The four non-negotiable rules

1. Read-only first. Start every new workflow with read-only credentials. Add write scopes one at a time, each justified in the contract. A triage draft step (Lesson 87.2) needs read; only the approved resolver needs send. 2. Separate test from production. Test credentials point at sandbox data; production credentials touch real customers and money. The workflow that practiced on fake contacts must not wake up with the real customer list. 3. Dedicated credentials per workflow. One credential per workflow, named for it (n8n-crm-followup-prod). Shared keys mean one leak compromises everything and one revoke breaks everything. 4. No master accounts, no personal logins. The workflow never holds your admin password, your personal OAuth grant, or a key that can delete the workspace. If the builder leaves, the workflow keeps running — and the builder's access can be removed without breaking it.

Apply these on any platform: in n8n, Make, and Zapier each connection is a credential — create one per workflow with the narrowest scopes the app allows. For HubSpot work, check scopes in the HubSpot knowledge base; for payment flows, keep webhook secrets and restricted API keys apart per Stripe webhooks.

Exercise: write the permissions matrix

Create the matrix — actor by actor, no hand-waving:

# PERMISSIONS-MATRIX.md — [Workflow]

| Actor (service account / credential) | Allowed | Forbidden | Secret location | Revoke procedure |
|---|---|---|---|---|
| e.g. `svc-crm-followup-prod` | read contacts, create note | delete, export all, change owners | Make vault / env `CRM_KEY_FOLLOWUP` | disable in HubSpot admin → rotate → update vault, owner ___ |
| e.g. `svc-checkout-webhook` | verify signature, write entitlement | refunds, payouts | server secret manager | revoke at provider dashboard, owner ___ |

## Rules attested
- [ ] read-only default; each write scope justified: ___
- [ ] test/prod split: test cred ___ / prod cred ___
- [ ] dedicated creds; no shared master; no personal login
- [ ] rotation cadence ___ + on-exposure rotation steps
- [ ] audit log location + weekly reviewer: ___

Worked mini-example — ByeBuy publishing helper: svc-content-draft may read the research packet folder and write drafts to the drafts folder; it may not publish, delete canonicals, or read customer data. Publish permission belongs to svc-publish used only by the approved release step. Test credentials point at a sandbox folder. When a key appeared in a pasted log once, the owner revoked it in the provider dashboard, rotated, and updated the vault — a five-minute drill because the matrix said exactly how.

Finish line: a matrix covering every actor with allowed, forbidden, secret location, and a revoke procedure you could follow half-asleep.

Verify quickly: for each credential ask "if this leaked tonight, what's the worst it could do?" If the answer includes anything outside the workflow's job, narrow the scope. Then rehearse one revoke — time yourself finding the disable button.

Common failure mode: the god-key Zap — one personal full-access key shared across five workflows, pasted in a doc, never rotated. One leak, total compromise; one departure, everything breaks. Dedicated narrow credentials feel like paperwork until the night they save you.

Check your understanding

1. Why does each workflow get its own credential instead of sharing one key? 2. What breaks when test and production share credentials? 3. Walk a revoke: what do you disable, where, in what order, and who owns it?

Next

Keys are small and revocable. But even careful workflows meet a messy world — malformed payloads, late vendors, duplicate events. Lesson 88.4 builds the exception paths and the human queue that catch them.