Every team running AI agents eventually faces the same question, usually after something has already gone wrong: which of these actions should the agent have been allowed to take on its own? One developer documented a runaway agent loop burning over $700 in 72 hours with no budget controls — a workload that was allowed to run, and keep running, because nobody had ever classified what it was permitted to do. Gartner forecasts that 40% of enterprise applications will incorporate task-specific AI agents by the end of 2026, up from less than 5% in 2025. As the number of agents climbs, "we never decided" stops being an oversight and starts being the incident report.
The Governed Agent Mesh Playbook answers the question before the incident, with a single worksheet: tier every capability by consequence, not by frequency. This AI agent risk tier classification worksheet is that worksheet — five columns, three tiers, and a rule that a capability with no tier, no owner, and no stated consequence does not run.
What the worksheet is (and is not)¶
The worksheet is: a complete inventory of the capabilities your agents actually invoke — tool names, API calls, cron jobs — each one classified by what happens if it goes wrong, given a named owner, and assigned the evidence that would be required to unblock it when it is stopped.
The worksheet is not: an architecture review, a permissions screenshot, or a one-time exercise. It does not describe the system the way the diagram says it works; it lists capabilities the way agents invoke them in production. And it is not finished when it is filled in once — it is re-run whenever the blast radius changes, because the tier follows the consequence, and consequences change.
The three tiers¶
Hard-gated. Actions whose consequences are serious, external, or hard to reverse: moving money, accepting a contract or terms of service, sending external outreach, reading or transmitting credentials or secrets, changing agent permissions or grants, and any action with legal consequences. A hard-gated action always requires a recorded human approval. There is no auto-grant path, ever, and the acting agent can never approve its own action.
Bounded auto. Routine work inside an approved plan: inference batches, intermediate writes to plan storage, ordinary compute. Bounded-auto actions run without asking first — but they run inside stated bounds (an active plan, a cost ceiling, an expiry), they are fully audited, and they auto-block the moment a bound is reached. Reaching the ceiling fails closed: the action is blocked and recorded, never retried automatically.
Draft-only. Work that prepares but never executes: drafting a proposal, composing an outreach message, planning. Draft-only output is recorded and reviewable, but it never contacts anyone and never changes state outside the draft. Note the boundary precisely: composing the message is draft-only; sending it is a separate, hard-gated action.
The worksheet, filled in¶
The five columns are: Action / capability, Consequence if wrong, Tier, Owner, and Evidence required to unblock. The Studio Edition worksheet ships with eight rows pre-filled:
| Action / capability | Consequence if wrong | Tier | Owner | Evidence required to unblock |
|---|---|---|---|---|
| Send a payment / move money | Double-spend, fraud, unrecoverable loss | Hard-gated | Finance owner | Recorded human approval + invoice reference |
| Accept contract or terms of service | Legal liability, auto-accepted obligations | Hard-gated | Legal owner | Signed terms document + approver identity |
| Send external outreach (email/DM/post) | Reputation damage, spam violations | Hard-gated | Growth owner | Approved draft + reviewed recipient list |
| Read or transmit a credential/secret | Credential leak, account takeover | Hard-gated | Security owner | Grant record + time-bounded stated purpose |
| Change agent permissions or grants | Privilege escalation, scope creep | Hard-gated | Platform owner | Change request + owner signature |
| Run inference batch inside plan bounds | Cost overrun if bounds are wrong | Bounded auto | ML engineer | Active plan with cost ceiling + expiry |
| Write intermediate artifacts to plan storage | Data sprawl, wrong data class exposure | Bounded auto | Data owner | Storage bound recorded in the plan |
| Draft a proposal / compose an outreach message | None — drafts never execute | Draft-only | Author | n/a (sending is a separate hard-gated action) |
Read the pattern, not just the rows. Everything that leaves the building, moves money, touches a secret, or changes who is allowed to do what is hard-gated. Everything that only consumes bounded resources inside a plan is bounded auto. Everything that only produces a draft is draft-only — and the moment a draft is sent, it stops being draft-only.
How to fill in the blank rows¶
- List capabilities the way agents invoke them. Tool names, API calls, cron jobs — not the way your architecture diagram describes them. A capability you cannot find in an actual invocation log is a capability you have not really inventoried.
- Write the consequence if wrong, in plain language. Not "high risk" — the actual harm: double-spend, leaked credential, obligations accepted in your name. If you cannot name the consequence of an action being wrong, default it to Hard-gated until you can.
- Assign the tier by consequence, never by frequency. An action that runs ten thousand times a day with a trivial consequence is bounded auto. An action that runs once a quarter and moves money is hard-gated. Frequency is a scheduling fact; the tier is a consequence judgement.
- Name an owner. A person or role who answers for this capability — who approves it if it is hard-gated, who watches it if it is bounded auto. A row with no owner is a row nobody will defend or maintain.
- State the evidence required to unblock. When the action is blocked, what exactly would let it proceed? A recorded approval, an invoice reference, a signed terms document, an active plan with headroom. If the evidence cannot be stated, the block cannot be lifted honestly.
- Get the owner's sign-off. A row is done when all five columns are filled and the owner has signed off. And when two owners disagree on a tier, the higher tier wins — downgrading a tier is itself a Hard-gated decision.
Three tiering heuristics¶
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. The asymmetry is the whole argument: the cost of over-gating is inconvenience; the cost of under-gating is the harm itself, discovered afterwards.
"Read-only" is the most commonly mis-tiered label. Reading a credential store, exporting a customer list, or dumping a production database are reads with write-grade consequences — once the data has left, no rollback retrieves it. Tier reads by what the data would do in the wrong hands, not by the fact that the call was a GET.
Re-tier whenever the blast radius changes. A new integration, a new data class, or a bigger spend ceiling all change the consequence column, and the tier follows the consequence. The worksheet you filled in for last quarter's stack describes last quarter's stack. If the agent gained a tool, a data source, or a larger ceiling since then, the affected rows are stale until they are re-tiered.
Common mistakes¶
- Tiering by frequency. "It runs constantly and nothing has happened" is a statement about luck, not consequence. The runaway loop that burned $700+ in 72 hours was also running constantly.
- Tiering the diagram. Architecture diagrams describe intentions. Agents invoke tools. When the two disagree, the invocation is the truth — and the gap between them is itself a finding.
- Self-approval. Letting the acting agent (or the system that proposed the action) approve it converts the gate into a log entry. The approver of a hard-gated action is a human, recorded by identity, every time.
- Leaving evidence blank. A hard-gated row with no stated evidence to unblock produces exactly two outcomes in practice: the block is bypassed informally, or the work stops and someone routes around the system. State the evidence when you write the row.
- Never re-tiering. Integrations, data classes, and ceilings change quietly. A worksheet that is never revisited certifies a system that no longer exists.
Before you call it tiered¶
- Every capability your agents actually invoke appears as a row — tool names and API calls, not diagram boxes.
- Every row has all five columns filled: action, consequence if wrong, tier, owner, and evidence required to unblock.
- Every hard-gated row names a human approver path with no auto-grant and no self-approval.
- Every bounded-auto row points at a plan with a cost ceiling and an expiry that fail closed.
- Every "read-only" capability has been re-examined for write-grade consequences.
- Downgrades are recorded as hard-gated decisions, and disagreements resolved to the higher tier.
- A re-tier trigger is written down: new integration, new data class, or a raised ceiling reopens the worksheet.
If any line fails, the stack is not tiered yet — it is described. The Governed Agent Mesh Playbook — Studio Edition gives you this worksheet ready to run: the eight pre-filled rows above plus twelve blank rows for your own stack, the six adopt-as-is policy templates (identity, grant issuance, hard-gated actions, spend limits and expiry, fail-closed blocks, audit-row retention), the plan-bound and audit-row JSON schemas, and the 14-day rollout that installs the tiers on day 9 and turns the gates live on day 10. Get the Studio Edition at https://ghostcorpnet.gumroad.com/l/hdigmr.