This playbook provides an ordered path from proposal to retirement. It does not prescribe one technology architecture. Control depth should follow the impact and delegated authority of the use case.
Phase 1 — Define Purpose, Owner and Prohibited Outcomes
State the business task, intended users, expected outcome and system boundary. Name a business owner and technical owner. List outcomes the agent must never produce, such as approving its own access, sending unreviewed regulated advice or changing records outside an authorised scope.
Use-case statement, accountable owner, technical owner, success criteria and prohibited actions.
Phase 2 — Assign Autonomy and Impact Levels
Classify whether the agent observes, recommends, acts with explicit approval or acts within bounded delegated authority. Assess impact separately using consequence, reversibility, data sensitivity, scale and affected people. Use the agentic AI governance framework for the complete model.
Phase 3 — Register the Agent and Its Dependencies
Record agent identity, purpose, owners, lifecycle status, model, data sources, memory, tools, credentials, environment, upstream requester, downstream agents and target systems. Include supplier and version context where relevant. The record becomes the anchor for change and evidence.
Phase 4 — Design Identity, Permissions and Approval Gates
Map effective authority across direct access, groups, delegated users, connectors and downstream services. Separate read, create, modify, approve and delete. Limit resource, environment, time, value and frequency. Put human confirmation or an independent policy gate before irreversible or high-impact actions.
The agent identity and permissions guide provides a detailed demonstration matrix.
Phase 5 — Test Behaviour, Failure Modes and Intervention
Test normal tasks, prohibited actions, boundary values, hostile or misleading context, incorrect data, unavailable tools, unavailable approvers, repeated attempts and rollback. Confirm the agent cannot expand its own authority or bypass the control when a dependency fails.
Phase 6 — Deploy Runtime Monitoring and Enforcement
Define signals, policy decisions and response ownership. Decide when the system will allow, log, redact, limit, request approval, block, pause or terminate. High-impact controls should sit at an enforcement point the agent cannot rewrite.
Set thresholds and escalation routes before production. Verify fail-open, fail-closed or pause behaviour explicitly with the runtime governance controls guide.
Phase 7 — Retain Evidence and Review Operation
Capture the initiating requester, agent identity, context source, policy version, tool request, decision, approval or block, external result and exception. Assign review cadence and metrics for ownership gaps, excessive permission, failed controls, incidents and overdue change decisions.
Use the evidence and metrics model to keep records portable and decision-focused.
Phase 8 — Govern Change, Suspension and Retirement
Trigger reassessment after changes to purpose, model, instructions, data, memory, tools, permissions, autonomy, users, geography or supplier service. Define emergency authority to pause or revoke. At retirement, disable identities and credentials, remove connectors, preserve required evidence and verify that the agent can no longer act.
Playbook Control-Gate Matrix
| Phase | Required decision | Minimum artefact / evidence | Approval owner | Exit criterion |
|---|---|---|---|---|
| 1 · Purpose | Is the use legitimate and owned? | Use-case statement and prohibited outcomes | Business owner | Purpose, owner and boundary are explicit |
| 2 · Classification | How much autonomy and impact? | Autonomy and impact rationale | Risk owner | Control tier is assigned |
| 3 · Registration | What forms the governed system? | Agent, data, tools, memory and dependency record | Technical owner | System boundary is reviewable |
| 4 · Authority | What may act, where and under whose authority? | Identity, permission and approval design | Business and security owners | Effective authority is bounded |
| 5 · Testing | Do controls handle expected and failure cases? | Scenario results and unresolved findings | Control owners | Required tests pass or exceptions are accepted |
| 6 · Runtime | How will operation be constrained? | Signals, policy, response and fail-safe test | Operations owner | Monitoring and enforcement are live |
| 7 · Evidence | Can the organisation prove and review operation? | Trace, metrics, review and incident routes | Governance owner | Evidence is complete and portable |
| 8 · Change | When must approval be reopened or use stopped? | Change triggers, suspension and retirement record | Business owner | Reassessment and revocation work |
Worked Example: A Customer-Service Agent With Refund Authority
- Purpose: resolve standard service cases; never change identity details or approve its own limits.
- Classification: Level 3 for refunds above a low threshold and Level 4 within a bounded low-value policy; material customer impact.
- Registration: record CRM, ticketing, knowledge source, payment tool, model, memory and service owner.
- Authority: distinct workload identity, read-only customer profile access and refund permission capped by value and frequency.
- Testing: valid case, missing evidence, repeated request, hostile ticket content, unavailable approver and payment-tool failure.
- Runtime: allow low-value policy-compliant refund, require approval above threshold, block excluded accounts and repeated attempts.
- Evidence: retain requester, ticket, policy, approver where applicable, tool result and final CRM/payment state.
- Change: new customer segment, payment tool, model or higher limit triggers reassessment; retirement revokes credentials and connectors.
Use the Playbook to Evaluate Governance Platforms
Ask each shortlisted supplier to demonstrate the same use case across registration, decision gates, change and evidence. Record which steps are native, integrated, manual or unsupported. The playbook creates a comparable test; it does not imply that one product must perform every control.
Use the AI Control Map catalogue to screen solutions, then apply the outcome-led requirements method during procurement.