"What is the bot allowed to do?" should have a one-page answer with a signature on it. This playbook writes the auto-resolve matrix — what AI agents may resolve on their own, what needs human approval, and what is never automated — with logging requirements and rollback duties attached to every row.
Tier: Core · Workflow area: Governance & measurement · ~35 minutes
This playbook produces the desk's central governance artifact for UC-43: a matrix that a service owner can sign, an auditor can test against, and an engineer can implement as platform permissions. It converts pb-41's technical risk classes and pb-42's remediation candidates into policy — before an incident forces you to write it in a weekend.
Inventory every action any agent can take today or is about to. Sources: pb-41's tool contracts, pb-42's remediation rows, the vendor platform's action catalog, and — the one people forget — existing workflow automations that resolve or close tickets. One row per action, phrased as a verb on a target: "reset standard-user password," "close ticket after 3-day no-response," "add user to standard distribution list."
Draft the matrix with three columns and no fourth. Auto-resolve, Human approval required, Never automated. Every action lands in exactly one. Draft with the LLM to move fast, then argue with it:
You are drafting an auto-resolve policy matrix for an IT service desk.
For each action below, propose: column (AUTO / APPROVAL / NEVER),
the single biggest failure mode, the rollback if it goes wrong, and
what must be logged. Be conservative: anything touching authentication,
privileged accounts, data deletion, or money is NEVER unless a strong
case exists. Output a markdown table.
Actions: [paste inventory]
The model's job is completeness of failure modes; the column decision is yours and the service owner's.
Attach the four duties to every non-NEVER row. A row without these is a wish, not a policy:
| Row element | Question it answers |
|---|---|
| Conditions | Under exactly what circumstances may this run (user class, hours, ticket state)? |
| Logging | What is recorded, where, retained how long? |
| Rollback | The documented undo, and who executes it within what SLA? |
| Owner | Which named human answers for this row in a post-incident review? |
Example row: Reset standard-user password — APPROVAL · Conditions: verified identity, non-admin, non-VIP, business hours · Logging: agent action log + ticket work note, 12 months · Rollback: forced reset + session revoke within 15 minutes · Owner: Identity service owner.
Write the NEVER column with reasons, not vibes. Typical residents: anything on privileged or executive accounts, MFA method changes, account deletion, device wipe, financial approvals, security-incident closure. Each carries one sentence of why — "irreversible," "identity-attack surface," "regulatory" — so a future enthusiast has to defeat the reason, not just the row.
Map columns to ITIL-shaped change thinking. AUTO rows are your standard changes: pre-authorized, low-risk, procedure documented, individually logged. APPROVAL rows are normal changes with a lightweight approver path. If your organization runs a change advisory process, take the matrix through it once — the sign-off doubles as change pre-authorization and spares every future AUTO execution a change ticket.
Get the signature, visibly. The matrix carries a version number, a date, the service owner's (or IT manager's) sign-off, and a scheduled review date no more than six months out. Publish it where the desk works — wiki front page, not a buried PDF. Unsigned drafts confer zero authorization: the platform stays read-only until ink lands.
Implement the matrix as permissions, then test the fence. Every NEVER action must be technically impossible for the agent identity, not just prohibited on paper — absent scopes, absent role assignments, absent tools. Prove it quarterly: attempt one NEVER action and one out-of-conditions AUTO action in the test tenant, and file the refusals with the matrix version they validate.
risk_class, requires_approval, and conditions as code. A pull request that changes that file must cite the matrix version that authorizes it.The matrix is a security boundary document — treat proposed changes to it like privileged-access requests, never accept edits that arrive as "the vendor enabled this by default," and audit that platform toggles still match the signed version after every product update.
Three columns, four duties per row, one signature, and a technical fence that makes NEVER mean never — the matrix is what turns "the bot can act" from a risk conversation into a signed, testable, six-monthly-reviewed operating agreement.