Agentic AI
Systems that pursue goals through planning, tool use, and actions with some degree of autonomy. Autonomy is a capability—not permission.
Read the chapter →
OPERATING KNOWLEDGE // 001
The AI governance field manual.
A visual guide to the moment an AI recommendation becomes a real-world consequence—and the controls that keep speed from becoming unaccountable execution.
MANUAL PURPOSE
Translate standards, incident evidence, and operational controls into decisions a team can actually use.
FOUNDATIONAL CHAPTERS08
INCIDENT REPORTS ANALYZED104
PRIMARY FRAMEWORKS05
ORIENTATION // 01
Govern the action, not the adjective.
“AI,” “agent,” and “copilot” do not tell you how much authority a system holds. Start with the action, the consequence, and the person accountable for allowing it.
AI governance is an operating system for accountability. It connects named decision owners, context-specific evidence, technical boundaries, monitoring, intervention, and recovery across the AI lifecycle. NIST places governance across its Govern, Map, Measure, and Manage functions and explicitly calls for defined human-oversight processes.[1]
01 // PROPOSEMachine recommends
The system produces an answer, decision, tool call, or change.
02 // CLASSIFYConsequence is scored
Reversibility, reach, rights, privileges, and uncertainty are assessed.
03 // PROVEEvidence is assembled
Context, dependencies, telemetry, test results, and rollback state travel with the action.
04 // AUTHORIZEA named owner decides
The reviewer can approve, reject, narrow, delay, or escalate.
05 // VERIFYOutcome is observed
Deployment is staged, measured, contained, and recovered when necessary.
FOUNDATIONAL CHAPTERS // 02
Eight concepts. One control path.
Read in sequence for the complete model, or enter at the pressure point your organization needs to solve.
Augmented AI
An operating pattern in which AI capability is paired with accountable human judgment at consequential checkpoints.
Read the chapter →Human in the Middle
A qualified decision owner placed at the point where machine output could become material consequence.
Read the chapter →Authority Gates
Executable policy that decides which actions may proceed automatically and which require named approval.
Read the chapter →AI Change Validation
Testing an action against your real dependencies, risk tolerances, evidence, and recovery objectives before broad deployment.
Read the chapter →Blast-Radius Control
Limit how far one wrong action can travel through systems, customers, environments, or decisions.
Read the chapter →Known-Good State & Rollback
Prove that restoration works inside the required time—and restore only what the dependency map says was affected.
Read the chapter →Operational Resilience
The ability to continue delivering important outcomes through disruption, intervention, and recovery.
Read the chapter →INCIDENT EVIDENCE // 03
What the ledger contains.
These charts describe the ServantStack incident ledger as verified on August 12, 2026. They do not estimate the prevalence of AI failures across industry.
AI or automation’s causal role
Count of reports by the editorial role assigned in the ledger (n=104).
| Role | Reports |
|---|---|
| Autonomous actor | 47 |
| Advisory output | 18 |
| Decision system | 11 |
| Fraud enabler | 10 |
| Material contributor | 10 |
| Operational automation | 8 |
Primary harm signal
Each report receives one primary harm signal; a report can involve additional harms.
| Harm signal | Reports |
|---|---|
| Data security | 29 |
| Financial harm | 24 |
| Physical safety | 19 |
| Human welfare | 14 |
| Rights & due process | 10 |
| Public trust | 6 |
| Operational disruption | 2 |
Method note. Counts are generated from data/incidents.json, the source dataset for ServantStack’s canonical incident pages. Categories are editorial classifications based on cited records. Selection, documentation availability, recency, and publication bias make this dataset unsuitable for calculating population rates or comparative product safety. Inspect the machine-readable ledger.
OPERATING MODEL // 04
Oversight must change the path.
The UK ICO warns that merely inserting a human somewhere in a lifecycle does not create meaningful review; timing and actual agency over the final outcome matter.[5]
Named authority
Assign the person or role accountable for the decision—not merely the team that operates the tool.
- Competent in the affected domain
- Available inside the decision window
- Empowered to reject or narrow scope
Decision packet
Make the reviewer’s evidence travel with the proposed action, including uncertainty and known omissions.
- Intended outcome and scope
- Dependencies and blast radius
- Tests, telemetry, and conflicts
Least privilege
Give the system only the access and duration required for the authorized action.
- Scoped credentials
- Separated trust zones
- Short-lived execution authority
Real context
Validate against your business services and dependencies—not only a vendor’s generic sandbox.
- Canary or staged cohort
- Per-system health checks
- Business outcome signals
Limited blast radius
Prevent one wrong action from automatically becoming an enterprise-wide event.
- Rate and scope limits
- Progressive deployment
- Automatic halt conditions
Known-good restoration
Prove recovery before execution and validate restoration after a fault.
- Dependency-aware rollback
- Tested recovery objective
- Post-restore verification
DECISION GUIDE // 05
When should a human decide?
Not every output needs approval. The useful question is whether the action can create a consequence the system should not be allowed to authorize for itself.
| Signal | Example | Gate | Minimum evidence |
|---|---|---|---|
| Hard to reverse | Delete data, publish externally, terminate service | HUMAN REQUIRED | Backup state, dependency map, rollback test, named owner |
| Rights, safety, or livelihood | Hiring, benefits, medical triage, physical control | HUMAN REQUIRED | Qualified reviewer, explanation, affected-person recourse, audit trail |
| Crosses a trust boundary | Untrusted content reaches code, credentials, or private data | HUMAN REQUIRED | Source provenance, scoped privileges, output inspection |
| Uncertain or novel | New failure mode, low-confidence recommendation, edge case | ESCALATE BY RISK | Confidence limits, comparable cases, expert review criteria |
| Reversible and bounded | Draft, summarize, simulate, recommend without execution | AUTOMATE WITH MONITORING | Logging, sampling, clear non-execution boundary |
| Repeated low-risk action | Previously approved pattern inside a fixed scope | POLICY-BASED AUTO-APPROVAL | Versioned policy, scope limit, drift monitoring, kill switch |
SOURCE LEDGER // 06
Standards behind the controls.
The manual synthesizes these sources into an operational model; it does not claim that “AugmentedAI,” “Human in the Middle,” or “Authority Gate” are terms defined by these institutions.
- NIST AI Risk Management Framework Core. Govern, Map, Measure, and Manage; includes defined human-oversight processes (MAP 3.5), testing before deployment and during operation, and decisions about whether deployment should proceed.
- NIST SP 800-53 Revision 5. A catalog of security and privacy controls supporting trustworthy and resilient systems.
- CISA, Shifting the Balance of Cybersecurity Risk. Secure-by-design principles emphasize customer security outcomes, transparency, and accountability.
- Regulation (EU) 2024/1689, Article 14. High-risk AI systems must support effective human oversight, including competence, authority, intervention, and stop mechanisms appropriate to risk.
- UK Information Commissioner’s Office, Guidance on AI and Data Protection. Explains why nominal human involvement is not necessarily meaningful review and why sequencing matters.
- OECD AI Principle: Robustness, Security and Safety. Calls for lifecycle risk management and mechanisms to override, repair, or safely decommission systems exhibiting harmful behavior.
- NIST AI 600-1, Generative AI Profile. Cross-sector companion to the AI RMF for generative-AI risks.
- ServantStack Incident Intelligence. A curated, source-cited editorial ledger of 104 AI and automation incidents, last verified per report.
DIRECT ANSWERS // 07
Questions teams ask first.
Short answers for orientation. Each linked chapter includes the nuance, examples, controls, and source trail.
What is AI governance?
The accountable roles, policies, evidence, technical controls, and review processes used to decide whether and how an AI system may act throughout its lifecycle.
Is agentic AI the same as generative AI?
No. Generative AI describes systems that generate content. Agentic AI describes a pattern in which a system pursues goals through planning, tools, and actions. A system may be both, either, or neither.
When is human approval necessary?
When an action is hard to reverse, crosses a trust boundary, affects rights or safety, expands privileges, moves money, changes production, or has a large and uncertain blast radius.
Does a person clicking “approve” create oversight?
No. The reviewer needs relevant competence, sufficient evidence and time, genuine authority to intervene, and a checkpoint before the consequential action.
Can low-risk actions remain autonomous?
Yes. Bounded, reversible actions can run automatically when policy defines their scope and monitoring, logging, and halt conditions remain active.
Are the incident graphs industry statistics?
No. They describe ServantStack’s curated 104-report ledger. The dataset is useful for studying patterns and controls, but it is not a representative census of all AI failures.