Chapter 16. Governing Agents
Systems that act, not advise, and the governance chain that constrains them.
16.1 Why agents need separate treatment
An agent differs from other AI systems in one governance-relevant respect: it converts an architecture question into an authority question. For a conventional application the question is what this component computes. For an agent it is what this component is permitted to do, and to whom that authority was delegated.
Classical enterprise architecture has well-developed thinking about data flow and integration. It has comparatively underdeveloped thinking about delegated authority, machine identity, and bounded autonomy, because until recently software did not act on its own.
16.2 The governance chain
Eight links, each a control point.
Agent → Identity → Permission → Tool → Policy → Action → Verification → Audit
Table 43. The governance chain
| Link | What it establishes | Recorded in | Failure if absent |
|---|---|---|---|
| Identity | A registered machine identity, distinct per agent, least privilege | Agent Card; IAM | Actions cannot be attributed; shared service accounts make audit meaningless |
| Permission | The authority boundary, machine-readable | Agent Card; ADR; policy engine | Boundary cannot be compared against actuals, so expansion is undetectable |
| Tool | Explicit allow-list of tools and APIs | Agent Card | Implicit tool access expands silently |
| Policy | Machine-enforced constraints; mandatory preventive control for standing-authority Tier 3–4 agents | Policy-as-code | Boundary exists on paper only |
| Action | Execution, with a pre-approved kill-switch condition | Runtime | No stopping mechanism when behavior goes wrong |
| Verification | Post-action check within a maximum audit-latency ceiling | Runtime, audit log | Errors compound before detection |
| Audit | Immutable log feeding Control Plane observation | Audit store | No basis for investigation or drift detection |
Two requirements in that table were added after the framework’s stress-testing found the original design insufficient, and both are worth implementing early. Standing-authority Tier 3–4 agents require a mandatory preventive control, not merely detective monitoring; detection after an irreversible action is not a control. And verification must occur within a defined maximum latency, because an audit that runs weekly does not constrain an agent acting hourly.
16.3 The Agent Card
The Agent Card is the primary record carrying the enforceable content of an agent’s authority.
Table 44. The Agent Card
| Field | Requirement |
|---|---|
| Registered machine identity | Unique per agent, never shared |
| Authorized tool list | Explicit allow-list, not a deny-list |
| Action boundaries | Value limits, counterparty limits, rate limits, scope limits |
| Reversibility per action | Each authorized action classified for reversibility |
| Escalation thresholds | Conditions that route to a human rather than proceeding |
| Kill-switch conditions | Mandatory at Tier 3–4; objectively evaluable |
| Delegation chain | For multi-agent systems: which agents may invoke which |
| Owner | Named Agent Owner, always human |
An allow-list instead of a deny-list is a deliberate choice. Deny-lists fail open: any capability nobody thought to prohibit is permitted. For a component that acts, failing open is the wrong default.
Worked example
Agent: Reconciliation-Agent-02
Identity: svc-recon-agent-02, dedicated, no interactive login
Authorized tools: read ledger; read bank statement feed; post correcting journal entry
Not authorized: approve payment; modify chart of accounts; access customer records
Action boundaries: single entry ≤ 5,000 currency units; aggregate ≤ 50,000 per day; entries to reconciliation suspense accounts only
Reversibility: journal entries reversible; audit trail and downstream reporting not
Escalation: any single entry > 5,000, any entry outside suspense accounts, any unmatched item older than 30 days
Kill-switch: attempted entry outside authorized account range, or aggregate exceeding daily limit → suspend agent, revoke posting permission, alert Agent Owner and AI Governance Lead, preserve state
Owner: Financial Control Manager
Tier: 4 (see Chapter 7, Example C)
Note the aggregate daily limit. It is not required by the framework — the cumulative exposure gap in Chapter 13, §13.4 is unaddressed — and it is exactly the kind of compensating control an implementer should add.
16.4 Multi-agent systems
Multi-agent composition carries the highest governance weight in the framework and the weakest coverage in existing standards.
Three additional questions apply beyond single-agent governance. Which agents may invoke which others, recorded as an explicit delegation graph instead of emerging from configuration. What authority each delegation carries — whether an invoked agent acts under its own boundary or the caller’s, which is the question that determines whether authority can compound. And what the composite boundary is: the union of authority reachable through a delegation chain, which is frequently broader than any individual agent’s boundary and is what actually needs governing.
[Practice recommendation] Compute and record the composite reachable authority for any multi-agent system, and score D2 and D3 against that composite rather than against the entry-point agent. A chain of individually modest agents can reach an immodest capability.