"Who can use which agent? What can each agent access?" For multi-agent systems in production, this is the permission and identity crisis. The pattern that fixed it for us: tier by consequence, not frequency.
Three tiers¶
- Hard-gated: anything moving money, accepting contracts, external outreach, touching credentials, changing permissions, anything with legal consequences. A recorded human approval every time — no auto-grant path, ever.
- Bounded auto: routine compute inside an approved plan. Runs on its own, fully audited, and blocks itself at any bound.
- Draft-only: proposals, messages, plans. Recorded, never executed, never contacts anyone. Compose and send are separate actions; send needs its own approval.
Three heuristics that saved us from ourselves¶
- When in doubt, tier up. A Bounded-auto action that should have been Hard-gated is an incident; a Hard-gated action that could have been Bounded-auto is just a slow afternoon.
- Watch the "read-only" actions. Reading a credential store, exporting a customer list, dumping a production database are reads with write-grade consequences. Tier them accordingly.
- Re-tier whenever the blast radius changes. New integration, new data class, bigger spend ceiling — the tier follows the consequence.
The identity underneath¶
Every actor holds a stable, owner-scoped identity — agent:[OWNER]/[NAME]. Anonymous actors are rejected at the dispatch path, never warned about. And every request, approval, block, and outcome writes a hash-linked audit row, so "who gave it authority" is a query, not an incident review. The risk-tier worksheet, identity policy, and audit-row schema are all in the Studio Edition playbook — but the principle fits in one sentence: tier by consequence, and identity everything.