Key takeaways
- Central governance should set minimum controls and own exceptions; process teams should own each agent's purpose, procedure and outcomes. Sending every decision to one committee creates a queue, not control.
- Keep one inventory that joins business owner, technical identity, tools, data, risk tier, policy version and lifecycle state. A catalog of agent names alone cannot answer who has authority.
- Tier the deployed use, not the model brand. The same model summarizing an internal document and releasing a payment belongs under different controls.
- Review evidence by exception: new permissions, policy denials, human overrides, failed runs, stale owners and overdue reviews. Dashboard totals hide the items that require a decision.
- Treat material changes as new authorization events. A new tool, data class, external audience or autonomy boundary can invalidate the approval even when the agent name stays the same.
What changes when one governed process becomes a portfolio
The process-level framework asks five questions: access, autonomy, record, escalation and review. At enterprise scale, the questions stay the same. The difficulty is discovering every deployment, applying consistent tiers, keeping owners current and reviewing exceptions without a committee reading every run.
NIST's AI RMF assigns governance across the organization rather than to a single technical team. Current Microsoft maturity guidance likewise connects enterprise standards with identity, data access, logs, human oversight and lifecycle operations. A workable model therefore has a small central rule set and distributed ownership, with evidence flowing back.
Set decision rights before forming the committee
| Decision | Recommends | Decides | Provides evidence |
|---|---|---|---|
| Approve a new low-impact process | Process owner | Department control owner | Builder or platform owner |
| Approve higher autonomy or external action | Process and security owners | Named risk owner or governance body | Platform, testing and approval owners |
| Grant production access | System and process owners | Identity or data owner | Authorization service |
| Accept a time-limited exception | Control owner | Named exception authority | Process owner until expiry |
| Pause after an incident | Any monitoring or response owner | Pre-authorized incident role | Run and incident records |
| Retire an agent | Business owner | Portfolio or platform owner | Identity, system and records owners |
Reserve the central body for policy, high-tier approvals, cross-team conflicts and exceptions. If it approves each ordinary workflow edit, teams will either wait or route around it. Local owners may decide within a published boundary; movement across the boundary comes back centrally.
Build an inventory that can answer operational questions
An inventory entry should join the business deployment to the technical actor. Start with purpose, department, business owner, technical owner, lifecycle state and risk tier. Add the exact identities, environments, tools, data categories, external audiences, maximum autonomous action, policy version, last review and next review.
This is not a model catalog. One model may support several uses with different consequences; one process may switch models without changing its control tier. Inventory the deployed purpose and its permission envelope, then link the current model and procedure as versioned components.
| Question | Fields that answer it |
|---|---|
| Who can stop this today? | business owner, incident role, lifecycle state |
| What can act outside the company? | action tier, tools, external audiences, approval boundary |
| Which access survives a departed owner? | owner directory ID, agent identities, last recertification |
| What changed since approval? | procedure, model, tool, data and policy versions |
| Which review is overdue? | last review, interval, next due date, exception expiry |
Review an exception packet, not a wall of totals
NIST's 2026 monitoring report describes a real scaling constraint: human review does not grow at the speed or complexity of production systems. Use human attention on deviations that require a decision. Totals belong in context; exceptions belong on the agenda.
The cover page lists active agents by tier and lifecycle state, then identifies changes since the prior packet. The decision queue contains new tools or data classes, autonomy increases, repeated policy denials, human overrides, incidents, failed rollback tests, stale owners, expired exceptions and overdue access reviews.
Each item carries one requested decision, one accountable owner, supporting run or configuration evidence, and a due date. Clean low-tier agents do not receive a slide each; they remain available in the inventory and sampled control report.
Use the same gates from proposal through retirement
- 01Propose and classifyHuman approvalName the process, owner, affected people, data, tools, action types and intended autonomy.
- 02Test under supervisionHuman approvalRun normal, boundary and failure cases; capture approvals, denials, overrides and recovery evidence.
- 03Authorize productionHuman approvalApprove the procedure, permission envelope, autonomy line, monitoring and incident owner together.
- 04Monitor and changeCodeRoute material changes, control failures and expired reviews back to a named decision state.
- 05Suspend or retireHuman approvalDisable schedules and credentials, settle queued work, preserve required records and mark the inventory state.
Limitations and when not to use this
- This operating model needs adaptation to the organization's legal, security and sector obligations. It does not assign a regulatory classification.
- An inventory does not discover unsanctioned agents by itself. Pair attestation with technical discovery in identity, network, procurement and platform data where available.
- Central reporting can create false confidence when source systems omit events. Test evidence completeness and cold replay rather than relying on dashboard availability alone.
Sources
- AI Risk Management Framework Core — NIST Accessed 29 July 2026
- Agentic AI maturity model: governance and security — Microsoft Learn Accessed 29 July 2026
- Challenges to the monitoring of deployed AI systems — NIST Accessed 29 July 2026
Build the first evidence packet
Pick five active agents, fill the inventory fields, and bring only missing owners, new permissions, overrides and overdue reviews to the next governance meeting.
Build the first evidence packetUli Prantz
Builds and operates all-agents
Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.