The AI Agent Governance Framework: From Register to Retire

Governing one agent well is a lifecycle. Governing several is a sequence of gates that someone owns, and the last gate is the easiest one to skip.

The example in this article is a composite scenario built from patterns common to finance and operations teams. It is not a single real organisation, and its figures and dates are illustrative. The code is real: every output block below was produced by running it.

At the interim audit in September, the IT auditor at a mid-sized distributor ran a routine test: take every service account that had authenticated in the last 30 days and match it to an owner and a purpose. One account, svc-agt02-stmtrecon, had last signed in at 02:00 the night before. The company's agent register, built in the spring, listed its agent as retired on 13 March.

The agent was a supplier-statement reconciliation pilot. It read the statements suppliers emailed in, matched them to the ledger, and set a "reconciled" flag on the supplier account when balances agreed. When the pilot ended, the team removed its dashboard tile and marked its register row retired. The nightly schedule, the mailbox rule feeding it and its credential were never touched. For 200 nights it kept reading statements and setting flags, and at month-end the accounts-payable clerks skipped any statement already flagged, as they had during the pilot. The analyst who built it had moved to treasury in April.

The auditor's question was short: who reviewed the reconciliations this account flagged since March? Nobody had. Nobody had known there was anything to review.

The same company had governed its duplicate-invoice investigator, the agent followed through this curriculum, carefully: tool contracts, per-action approval gates, a calibrated evaluation, a trace that could answer an auditor. It had not governed the portfolio, and the failure sat between decisions, where no lifecycle stage looks.

Why per-agent discipline feels like governance

The eight-stage lifecycle in What Is AI Agent Management? runs from workflow map to review and business case, and the autonomy ladder beside it sets how much an agent may do without a person. Every piece of evidence in this curriculum attaches to one agent, and a folder full of it is easy to read as governance.

The lifecycle is run by the team that owns the agent, and the questions that fail are ones that team has no reason to ask: who notices that the running version isn't the approved one, who decides an agent should stop, and who checks that it did. Those are portfolio questions. NIST's AI Risk Management Framework puts both ends of that portfolio in its GOVERN function, next to each other: "Mechanisms are in place to inventory AI systems" (GOVERN 1.6) and "Processes and procedures are in place for decommissioning and phasing out AI systems safely" (GOVERN 1.7) (NIST, 2023). Neither is something a single agent's lifecycle can do for itself.

The test: list every agent paused, replaced or retired in the last twelve months. For each, look up its credential in the identity provider today. Any that is still enabled is a retirement that happened on paper.

Gates decay between decisions

A register records decisions. The identity provider, the deployment pipeline and the scheduler record facts. Governance fails when those two drift apart, and they drift in a small number of ways, each of them ordinary:

• An owner leaves. The register still names them, so every later review, approval and stop decision has nobody to make it.

• A provider moves a model alias. The configuration says "latest", so the model under the agent changes without a release.

• A fix ships outside the gate. A prompt edit goes straight to production during a busy week, so the running version is not the approved one.

• A toggle changes autonomy. An approval step is switched off during a backlog, so an action approved at Level 2 runs at Level 3.

• A pilot ends in the interface only. The dashboard tile goes; the credential, triggers and data stay.

None of these passes a gate, because none looks like a decision to the person making it. The last is the hardest to see: a retired agent raises no alerts and sits in nobody's review calendar.

The discovery move that would have caught it belongs at registration, not at retirement: what would have to be true for this agent to be fully off, and which system would show each item? For the pilot, four lines: account disabled in the identity provider, job removed from the scheduler, mailbox rule deleted, statement store purged. Written on day one, those become the retirement checklist and the places a checker looks. People already get this treatment. NIST SP 800-53 control AC-2 asks organisations to notify account managers "when accounts are no longer required" and to "align account management processes with personnel termination and transfer processes" (NIST SP 800-53 Rev. 5). An agent's account deserves the same leaver process as the person who built it.

The test: for one agent, write the "fully off" list now, naming the system that shows each item. If you can't name the system, you couldn't prove the agent had stopped.

Seven gates that wrap the lifecycle

The framework is a sequence of seven organisational gates. Each asks one question, names the evidence that answers it, names who owns the answer, and blocks until the evidence exists. It doesn't replace the per-agent lifecycle: five of the gates collect evidence the lifecycle and this curriculum already produce, and two (Deploy and Retire) cover moments the lifecycle has no stage for.

Gate	Question	Evidence	Owner	Blocks when
Register	Is it on the inventory?	Inventory card: named owner still employed, its own identity, entry door	Agent owner	No owner, shared identity, or an agent account the register doesn't list
Assess	What is its risk tier?	Role card, workflow map reviewed by someone who did the work, a tool contract for every action	Owner and risk	Any action without a contract
Approve	May it run, and at what level per action?	Per-action levels within the tier cap; regression and evaluation results; kill switch rehearsed; sign-off matching the tier	Approvers set by tier	A level above the cap, a missing signature, no rehearsal
Deploy	Is the running version the approved one?	Prompt version, model id and configuration hash match the approval; rollback tested	Engineering	Any mismatch, or autonomy configured above what was approved
Monitor	Is it behaving?	Observability checklist checked in the last month; alerts routed to a named person	Operations	Fields missing; alerts with no owner
Review	Is it still worth running at this level?	A dated decision: keep, raise, lower or retire, with the evidence for it	Agent owner	Review overdue for its tier; owner gone; model changed since the last review
Retire	Is it fully off?	Credential disabled, scopes removed, triggers off, data handled, consumers told, entry closed	Owner and security	Any item without evidence

The evidence is deliberately borrowed. Register is the inventory card from Agent Governance Starts With an Inventory Nobody Has, keyed on authority rather than intent. Assess uses the side-effect class each tool declares in its contract, from Designing Tool Contracts and Least Privilege for AI Agents. Approve takes per-action ceilings and the planted-item measures from Where Human Approval Belongs, the calibrated evaluation from Evaluating AI Agents, and the regression result from Prompt Regression Testing in CI. Monitor is passed by The AI Agent Observability Checklist running against real traces. For those five gates the framework adds no artefact, only an owner per question and a rule that the agent doesn't move on without the answer.

Deploy is new because approvals attach to versions, and versions change. The gate compares the three identifiers the observability checklist already records on every run (prompt version, model id, configuration hash) with the ones the approval named.

The test: take your most powerful agent and fill in the evidence column from records, not memory. The first blank row is the gate it hasn't passed, whatever it is doing in production.

Risk tiers cap autonomy before anyone argues about it

Approval meetings tend to negotiate autonomy from scratch. A cap settles the default in advance. The tiers are the authority tiers from the inventory post, set by what an agent can do unattended, and each carries a ceiling for every action until a review raises it with evidence:

Tier	What it can do unattended	Cap per action before review	Review every	Kill switch
0	Read internal data only	Level 1	12 months	Not required
1	Writes that are easily reversed	Level 3	6 months	Recommended
2	Externally visible or compensable actions	Level 3	3 months	Tested at least once a year
3	Irreversible actions, restricted data, regulated decisions	Level 2	3 months	Rehearsed every quarter

(These caps and cadences are ShiftQuality's working defaults, not an external standard. Set yours before the first approval, so they can't be argued into fitting a particular agent.)

One list overrides the tiers. Financial commitments, contracts, external communications, production changes, data deletion, permission changes and decisions about people stay at Level 2 or below whatever the evidence, unless a written policy names the action. It says external rather than customer communications, because a sent email can't be recalled whoever receives it.

The cap stopped the next agent in the queue. The customer service team's delivery-query reply drafter, tier 3 because it handles customer personal data, came to approval asking for send_reply at Level 3. The drafts were accurate and the queue was long, but sending is an external communication, so the request was resubmitted with a person sending.

The cap also explains why the investigator holds two actions at Level 3 while its tier caps at Level 2. A review on 4 September raised place_invoice_on_hold and draft_reversal_upto_5000 after eight weeks of approval-gate measures passed, for one legal entity, with demotion triggers signed. Posting stayed at Level 2 because it is a financial commitment. A cap moved by a recorded review is the framework working; a cap moved by a toggle is what it exists to catch.

The test: for each agent, write its tier and the highest level any of its actions runs at today. Any action above the cap with no dated review raising it is running on someone's convenience.

A review that can only raise is a renewal stamp

The Review gate exists to answer one question on a schedule: is this agent still worth running at this level? NIST asks organisations to plan periodic review of their risk management and its outcomes, with roles defined, "including determining the frequency of periodic review" (GOVERN 1.5); the tier table above is one way to set that frequency for agents. The answer has four values, and two of them reduce what the agent may do.

The distributor's purchase-order chaser shows why lowering must be a normal outcome. It was approved in April as a tier 2 agent: Level 3 for updating a purchase order's expected delivery date, Level 2 for emailing suppliers. Over the summer a supplier portal changed its date format and buyers started correcting the agent's updates more often; a prompt fix, version 1.5.0, went straight to production; and during a backlog someone switched off approval on the chaser emails. Its quarterly review, due on 18 August, didn't happen.

The review that ran on 7 October brought the emails back to Level 2 and lowered the date updates from Level 3 to Level 2 until the regression pack covered the new format. Version 1.5.0 went through the regression gate and became the version of record.

The other skipped outcome is retire. The stock-rebalancing advisor, a read-only tier 0 agent, had recommended transfers between warehouses since August 2025. Its owner left in June, and its model changed underneath it because its configuration pointed at the provider's latest alias. The planners said they had stopped opening its weekly report months earlier. It was no longer worth an owner, a credential and a review slot, and the review said so.

Demotion shouldn't wait for a review date. An action drops a level until evidence is rebuilt when the owner leaves, the model or prompt changes outside the gate, the inputs change, or a measured rate such as the planted-item catch rate crosses its threshold. EU law expects the same shape for high-risk systems: Article 9 of the AI Act describes risk management as "a continuous iterative process planned and run throughout the entire lifecycle of a high-risk AI system, requiring regular systematic review and updating" (Regulation (EU) 2024/1689). Whether an agent is high-risk is a legal classification made per system; the habit is worth having either way.

The test: count last year's review decisions by type. If lower and retire are both zero across more than a handful of agents, either your agents are unusually stable or your reviews can't say no.

Retirement is a procedure, not a status

Retirement is the one gate with no deadline and no sponsor, and the cheapest way to "retire" an agent is to change a word in the register. OWASP names the consequence in its entry on excessive agency: an extension "may have been trialled during a development phase and dropped in favor of a better alternative, but the original plugin remains available to the LLM agent" (OWASP, 2025). An abandoned agent is the same leftover a level up.

NIST sets the bar at decommissioning "in a manner that does not increase risks or decrease the organization's trustworthiness" (GOVERN 1.7), with responsibilities assigned to "supersede, disengage, or deactivate" systems (MANAGE 2.4) (NIST, 2023). In practice, six items, each evidenced by the system that holds it:

1. Credential disabled, shown by the identity provider, not by the agent's console.

2. Scopes removed, so a re-enabled account would hold nothing.

3. Triggers off: schedules, mailbox rules, webhooks and any queue it consumes.

4. Data handled: memory, vector stores, cached documents and traces deleted, or kept under a named retention rule.

5. Consumers told: the people and systems that used its output know it has stopped, and know what to check.

6. Entry closed by the owner and security together.

The fifth item made the pilot expensive. Disabling the account stopped new flags but did nothing about six months of flags the clerks had already trusted, so every reconciliation flagged since 13 March had to be re-checked. The fourth mattered too: the statement store held supplier bank details.

The test: retire something small this month using the six items, and time it. If it takes a day, budget a day for every retirement, and put that day in the business case for every new agent.

Running the gates as a check, not a meeting

A gate that exists only in a meeting decays like a register. The checker in the code folder (about 200 lines of standard-library Python) joins three sources: the register, an export from the identity provider, and the deployment records that say what is running and at what level. This is the part that catches the pilot, verbatim from gate_check.py:

    if agent["status"] == "retired":
        r = agent.get("retirement", {})
        retired_on = d(r.get("date"))
        if acct and acct["enabled"]:
            used = d(acct["last_used"])
            late = f"; last used {acct['last_used']}, {(used - retired_on).days} days after retirement" if used and retired_on and used > retired_on else ""
            f.append(("retire", "BLOCK", f"credential {agent['identity']} still enabled{late}"))
        if acct and acct["scopes"]:
            f.append(("retire", "BLOCK", f"scopes still granted: {', '.join(acct['scopes'])}"))
        live = [t["name"] for t in (dep or {}).get("triggers", []) if t["enabled"]]
        if live:
            f.append(("retire", "BLOCK", f"triggers still enabled: {', '.join(live)}"))
        for key, (text, _) in zip(("data_handled", "consumers_told", "closed_by"), RETIREMENT[3:]):
            if not r.get(key):
                f.append(("retire", "BLOCK", f"no evidence: {text}"))
        return ("retired, clean" if not f else "retired on paper only", f)

Run against the distributor's records as they stood at the audit:

AS OF 2026-09-30: 5 agents on the register

AGT-01  duplicate-invoice investigator  (tier 3, active)
  position: in service; next review due 2026-12-03

AGT-02  supplier-statement reconciliation pilot  (tier 2, retired)
  position: retired on paper only
  BLOCK retire   credential svc-agt02-stmtrecon still enabled; last used 2026-09-29, 200 days after retirement
  BLOCK retire   scopes still granted: erp.supplier.read, erp.supplier.flag.write, mail.statements.read
  BLOCK retire   triggers still enabled: nightly-statement-run 02:00, mailbox rule statements@ -> agent inbox
  BLOCK retire   no evidence: data handled
  BLOCK retire   no evidence: consumers told
  BLOCK retire   no evidence: entry closed

AGT-03  delivery-query reply drafter  (tier 3, proposed)
  position: stopped at approve
  BLOCK approve  send_reply requested L3: 'external communication' stays at L2 or below whatever the evidence
  BLOCK approve  approval needs sign-off from: risk, security
  BLOCK approve  missing eval_report
  BLOCK approve  kill switch never rehearsed

AGT-04  stock-rebalancing advisor  (tier 0, active)
  position: stopped at register
  BLOCK register owner Inventory planning analyst has left; nobody can approve, review or stop it
  BLOCK deploy   version drift: model m-2025-05 approved, m-2026-07 running
  BLOCK monitor  observability checklist not checked in the last 31 days
  BLOCK review   review overdue by 41 days (last 2025-08-20, every 365 days)

AGT-05  purchase-order chaser  (tier 2, active)
  position: stopped at deploy
  BLOCK deploy   version drift: prompt 1.4.0 approved, 1.5.0 running; config_hash 7d42aa approved, 9e10b3 running
  BLOCK deploy   email_supplier_chaser configured at L3, approved at L2 (autonomy creep)
  BLOCK review   review overdue by 43 days (last 2026-05-20, every 90 days)

NOT ON THE REGISTER (enabled accounts tagged 'agent' in the identity provider)
  BLOCK register svc-ai-quotebot: last used 2026-09-27, scopes crm.quote.read, crm.quote.write

18 blocking finding(s)

Read the positions first. Only the investigator is where its owner thought it was. The stock advisor is in production yet stopped at Register, because an agent without an owner hasn't passed the first gate however long it has run. The chaser stops at Deploy on the summer's drift. The last block nobody had asked about: an agent account with write access to CRM quotes, used three days earlier, missing from the register. It was a hackathon prototype, disabled that week.

Every finding came from joining records the company already had. The register alone said five agents, all accounted for; the identity provider alone listed seven enabled service accounts and no story. The join only sees accounts someone tagged as agents; the credential sweep in Agent Governance Starts With an Inventory Nobody Has finds the ones nobody tagged.

A month later, after the decisions in the last three sections, the same check on the updated records:

AS OF 2026-10-31: 5 agents on the register

AGT-01  duplicate-invoice investigator  (tier 3, active)
  position: in service; next review due 2026-12-03

AGT-02  supplier-statement reconciliation pilot  (tier 2, retired)
  position: retired, clean

AGT-03  delivery-query reply drafter  (tier 3, proposed)
  position: ready to pass approve

AGT-04  stock-rebalancing advisor  (tier 0, retired)
  position: retired, clean

AGT-05  purchase-order chaser  (tier 2, active)
  position: in service; next review due 2027-01-05

0 blocking finding(s)

Twelve unit tests pin the rules down, including that a review can raise an action above its tier cap but never one on the mandatory-gate list, and that a lowered level fails the running configuration until it follows.

The test: export your identity provider's service accounts with their last-used dates and join them to your agent register by account name. Count the enabled accounts tagged as agents with no register entry, and the retired entries whose accounts are still enabled.

How to evaluate your own portfolio

Answer each with evidence you can produce within the hour:

1. Can you list every agent, including vendor-embedded and builder-made ones, and does that list match the identity provider's agent accounts?

2. Does each agent have a tier, and does its highest running autonomy level sit within that tier's cap or a dated review?

3. For each running agent, do the prompt version, model id and configuration hash in production match the ones its approval named?

4. Is every review on time, and has any review in the last year lowered or retired an agent?

5. For the last agent you retired, can you show all six retirement items?

Four or five yes answers: you govern a portfolio. Two or three: you govern agents one at a time, and the gaps are probably Deploy and Retire. One or none: start with question 1, because every gate depends on the list. (These bands are ShiftQuality's working thresholds, not an external standard.)

Tradeoffs and exceptions

Choice	Gains	Costs	Use when
Gates checked in code against system records	Drift found in minutes, not at audit	Export plumbing; tagging agent accounts consistently	More than a handful of agents, or any tier 2 or 3 agent
Gates as a review meeting only	Cheap to start	Decays between meetings; checks what people say, not what systems show	A first agent while the register is being built
Strict tier caps	Safe defaults; shorter approval arguments	Some good agents wait for a review to earn more	Any agent touching money, customers or personal data
Retirement as a six-item procedure	Nothing left running or trusted unnoticed	About a day of work per agent	Every retirement, including pilots

Exceptions. Personal, read-only assistants are better governed as a class, which still needs an owner and a review. Vendor-embedded agents you can't configure still get an entry; their Deploy gate becomes a check on release notes and your admin settings. A sandboxed prototype without production credentials can skip Approve until the day it gets one. If you are building an AI management system to ISO/IEC 42001, which "specifies requirements for establishing, implementing, maintaining, and continually improving" one (ISO, 2023), a register with gate evidence is the kind of operational record such a system runs on; nothing here claims conformity with the standard's clauses.

How agent governance frameworks go wrong

• The register is the framework. A list of agents with statuses is a set of claims. Without a join to the systems that hold credentials and deployments, it describes intentions.

• Reviews that only renew. No review has ever lowered anything, so a review date is a formality.

• Owners as teams. "Procurement" can't approve, review or pull a kill switch. A person can, and when that person leaves, the agent should stop at Register until someone else is named.

Who owns what

The agent owner holds Register, Review and Retire and signs every level change. Risk joins at Assess and co-signs tier 3 approvals with security. Engineering owns Deploy, operations owns Monitor, and security owns the identity export and co-signs every retirement. One person, often in quality or risk, owns the checker's weekly run, and is the person the auditor asks first.

What to do next

Export the identity provider's service accounts with last-used dates and scopes, tag the agents, and join them to your register. Fix enabled accounts on retired entries first, then agent accounts with no entry. Then fill in the seven-gate evidence for your highest-tier agent from records; the first empty row is where its next review starts.

Final takeaway

Per-agent discipline proves one agent behaved on the day someone looked. A governance framework keeps the portfolio's decisions true: every agent registered, capped by its tier, running the approved version, reviewed with the power to lower or retire, and fully off when it ends. The register says what was decided; the identity provider and the deployments say what is true. Join them, and the agent nobody remembers has nowhere to run.

Sources

• NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, January 2023. GOVERN 1.5 (ongoing monitoring and periodic review), GOVERN 1.6 (inventory of AI systems), GOVERN 1.7 (decommissioning and phasing out safely), MANAGE 2.4 (mechanisms to supersede, disengage or deactivate).

• NIST, Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Rev. 5, control AC-2 Account Management, items h.1 (notify when accounts are no longer required) and l (align account management with personnel termination and transfer). Wording verified against NIST's OSCAL catalogue for Rev. 5.

• OWASP GenAI Security Project, LLM06:2025 Excessive Agency, 2025. Excessive functionality, including an extension trialled and dropped that "remains available to the LLM agent"; limiting extensions to the minimum necessary.

• Regulation (EU) 2024/1689 (AI Act), Article 9, risk management system, paragraph 2. Applies to high-risk AI systems.

• ISO, ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system, standard overview page, accessed 11 October 2026. Only the public description is cited.

Frequently Asked Questions

What is an AI agent governance framework?

A sequence of organisational gates every agent passes: Register, Assess, Approve, Deploy, Monitor, Review and Retire. Each gate asks one question, names the evidence that answers it and the person who owns it, and blocks until that evidence exists. It wraps the per-agent lifecycle rather than replacing it.

How do risk tiers limit an AI agent's autonomy?

Each authority tier carries a cap on the autonomy level any action may hold before a review raises it with evidence. Read-only agents stay at Level 1, agents with irreversible actions or restricted data at Level 2. Actions on a mandatory-gate list, such as payments or external messages, stay at Level 2 whatever the tier.

What does it take to retire an AI agent properly?

Six things, each with evidence: the agent's credential disabled, its tool and API scopes removed, every trigger turned off, its memory and data deleted or retained under a named rule, the people who used its output told, and the inventory entry closed by the owner and security.

---

Part of the Agent Engineering curriculum: eight paths from prompts and context to testing, evaluation and governance.