An unreviewed registry is a list of what a firm believed last quarter: agents gain tools, owners leave, and usage decays fast, so the review on a calendar is the control, and the database is just where the answers get written down.

The checklist

1. Steal the agenda from a standard the firm already runs. ISO/IEC 42001’s clause 9.3 is the closer fit for an agent estate than 27001’s, and it is the same shape: top management reviews at planned intervals, with prescribed inputs (status of actions from the last review, changes in internal and external context, performance and monitoring results, audit findings, feedback, and improvement opportunities) and an output that must be decisions, retained as documented evidence. Two adjustments. 42001’s input list drops 27001’s risk-assessment and risk-treatment status; adding that as a standing agenda item is a local choice rather than a requirement of the standard. And “top management at planned intervals” is the wording that matters: a named accountable role and a schedule, not senior people when calendars allow.

2. Force a decision per row. Keep, re-tier, reassign owner, retire. Four checks generate them: is the owner still here, is the tier still right, is usage above the retirement floor, are the credentials still scoped to what the agent actually does. Cheap version: one hour, a spreadsheet, a decision column. Thorough version: staleness flags computed from logs, and the meeting spends its time only on flagged rows.

3. Automate the hygiene, then distrust the inactivity signal. One firm in the MISQE case study ran a fully automated lifecycle on low-code apps: flag at three months inactive, quarantine at nine, archive at twelve. Transplantable, with a caveat that matters more for agents than it did for apps: a scheduled agent that fires nightly is never inactive, however useless it has become. Pair inactivity with a value signal (runs that changed something, outputs a human consumed) or the rule will archive the abandoned chatbot and keep the pointless cron.

4. Re-evaluate the zone on adoption, sensitivity and decay. Microsoft’s guidance recommends promoting an agent as adoption grows or data sensitivity increases, and retiring it when usage drops. Be precise about the status of that: the zone model is documented product behaviour, but the re-evaluation triggers appear only in Microsoft’s guidance prose, not in the product docs, with no mechanism, automation or threshold behind them. Treat the triggers as this wiki’s recommendation and set the thresholds locally.

5. Give the review teeth, then verify the teeth closed. Blocking is a real documented action: the Microsoft 365 admin center’s agent registry supports block and unblock tenant-wide, alongside delete, start/stop, assign-new-owner, and publish/reject. Two limits belong in the runbook. Block is not uniform: for agents built with Agent Builder or Copilot Studio it removes availability across Copilot and the host products, but for agents built with SharePoint or Foundry it only removes them from Copilot Chat, and the agent still lives elsewhere. And the action can fail silently: if the agent sits in a Power Platform environment with the IP firewall in active enforcement, a block issued from the M365 admin center is rejected, because the request arrives carrying the upstream service’s IP rather than the administrator’s. A review that records “blocked” without confirming from a user’s seat is manufacturing a false compliance record.

6. Let the review loosen controls, not only tighten them. If agents are running under the same approval requirements they had on day one, six months and a clean record later, the governance layer has calcified. That formulation is a consultancy’s, not Anthropic’s, despite how it circulates; the first-party version is Anthropic’s autonomy telemetry, where experienced operators grant more autonomy and interrupt more often, evidence that a cadence should be able to move controls in both directions.

7. Run a cheap continuous layer underneath the quarterly one. One case firm’s governance hub receives a daily email summarizing everything moved to production the previous day. That costs nothing and it is what keeps the quarterly review from being the first time anyone hears about a change.

8. Write sunset criteria before they are needed. Define in advance what low usage or poor return looks like and what it triggers. The clearest statement of this comes from an insurance trade association’s CEO playbook, generic portfolio hygiene with a lineage worth noting: it is about use cases rather than agents, predates the agentic wave, and its broader posture is buy-never-build, a position this wiki argues against.

How you’d know it’s working

Decisions issued per review. Retirements, re-tiers and owner reassignments that actually executed. A review that has never retired an agent is a status meeting with a spreadsheet.

Time to trace an incident to the specific live agent instance that caused it. BCG proposes this as the registry health metric and explicitly rejects the count of registered agent IDs as a substitute. It is a consultancy’s assertion with no measurements attached, so earn it rather than cite it: per-instance identity and correlatable logs, covered in logging and audit, are what make the trace fast, and a drill is what produces the number.

Enforcement spot-checks. Pick one agent blocked last quarter and try to use it from an ordinary account. See item 5.

What this doesn’t solve

The review covers what is registered. Shadow agents are invisible to it by construction, and discovery is a different control; the mature posture is continuous discovery and mapping rather than an annual inventory project, which is a security vendor’s stated position and also just true of any inventory.

The strongest objection to this page is that periodic review is the wrong instrument entirely. Kurshan, Balch and Byrd argue that generative and agentic systems need real-time adaptive oversight and that traditional monitoring is obsolete. Read their target carefully: the passage is item (iii) in an enumerated critique of the model risk management stages inherited from SR 11-7 and OCC 2011-12: model rating, initial validation, ongoing monitoring. They are attacking periodic model validation, not portfolio-level registry review. Those are different jobs, and this page concedes the first: a quarterly meeting governs the portfolio and cannot substitute for runtime monitoring. Both halves of their claim rest on a single citation that could not be located, and it is an argument in a preprint rather than a measurement, so cite it by name as a counter-position. The practical form of their point is real, though, and KPMG states it plainly: oversight has to scale with autonomy. Higher-tier agents need a shorter interval than the calendar quarter, and the runtime controls in runtime guardrails are what cover the gap between reviews.

See also

• Agent inventory and registry — the control that creates what this review maintains.
• Agent sprawl — the failure mode an unreviewed registry becomes.
• Shadow agents — what this review cannot see.
• Offboarding agents and owners — where the retire and owner-departed decisions execute.
• Risk-tier assignment — the re-score this review triggers.
• The agent control plane — the architecture that makes the review cheap.