Chapter 2 introduced the Maturity Model. Level 4 (Governed) requires five architectural capabilities that most enterprise software stacks don't provide for AI agents. This chapter examines each pillar in depth: what it is, why it matters, what "good" looks like, what "bad" looks like, and how to implement it.
These pillars are not independent. Identity feeds into Authorization. Authorization decisions are captured by Audit. Verification samples from Audit data. Federation extends all four across organizational boundaries. The pillars compose — and they must all be present for governance to work.
Pillar 1: Identity
The principle: Every AI agent must have a unique, cryptographically verifiable identity — not a shared API key, not a service account, not "the company's OpenAI key."
Why Identity Matters
Without identity, you cannot answer: "Which agent did this?" When an unauthorized data access appears in your SIEM, can you trace it to a specific agent, deployed by a specific team, in a specific workspace? Or does the log show "api-key-prod-2024" — a credential shared by 47 agents?
Agent identity is the foundation of everything else. Authorization checks "can agent X do Y" — but if you can't identify agent X, authorization is meaningless. Audit logs record "agent X did Y" — but if X is a shared key, the log is useless for incident response.
What "Good" Looks Like
| Capability | Standard | What It Does |
|---|---|---|
| Unique ID | SPIFFE | Every agent gets a URI identity: spiffe://domain/tenant/{id}/agent/{id}. Globally unique. Revocable. Your IAM can reference it. |
| Signed Credentials | W3C Verifiable Credentials | Agent carries a cryptographically signed "badge" listing its tools, permissions, and governance status. Third parties can verify without calling back to the issuer. |
| Short-lived Tokens | JWT-SVID | Agent authenticates with a JWT signed by the platform's CA. 1-hour TTL by default, 24-hour max. Stateless verification — no DB lookup needed. |
| Cross-org Trust | SPIFFE Trust Bundles | When your agent talks to a partner's agent, trust is verified via exchanged SPIFFE trust bundles — not a phone call to their IT department. |
| Delegated Access | OAuth 2.0 Token Exchange (RFC 8693) | Agent A can delegate limited capabilities to Agent B via token exchange. Scoped, time-limited, auditable. No shared secrets. |
What "Bad" Looks Like
Shared API keys
50 agents share one OpenAI key. A breach exposes all 50. You can't revoke one without disrupting the other 49. Audit logs show the key, not the agent. Incident response means rotating the key for everyone.
Service accounts without scoping
Each agent has a service account, but all service accounts have the same permissions. One compromised agent escalates to full access. "Least privilege" is aspirational, not enforced.
Implementation Checklist
- Every agent has a unique, persistent identifier (not generated per-session)
- Identity is cryptographically signed (not self-asserted)
- Credentials are short-lived with automatic renewal
- Identity is visible in your IAM / security dashboard
- Revocation is instant (seconds, not days)
- Cross-organization identity verification uses trust bundles, not manual configuration
Pillar 2: Authorization
The principle: Every tool call an agent makes must pass through a policy check. Default deny. Fail closed.
Why Authorization Matters
An AI agent with access to your CRM, email, and code repositories is more dangerous than any individual employee — because it can act at machine speed, 24/7, without fatigue or second-guessing. A human might pause before emailing 10,000 customers. An agent will not — unless a policy check stops it.
Authorization for agents is fundamentally different from authorization for humans. Humans have 10-20 applications they use daily. An agent can invoke 190+ tools in a single session. The authorization model must be per-tool-call, not per-application.
The Three Enforcement Modes
Production authorization systems need a progressive rollout model. You don't flip from "no enforcement" to "hard blocks" overnight — that breaks running agents and erodes trust.
| Mode | What Happens on Deny | When to Use |
|---|---|---|
| Audit | Denial logged, request allowed | Initial rollout. Discover what your agents actually do before blocking anything. |
| Warn | Denial logged + warning header, request allowed | Progressive tightening. Teams see warnings and can fix permissions before enforcement. |
| Enforce | Denial logged, request blocked | Production governance. Agent cannot proceed without proper authorization. |
The progressive activation pattern
Start in warn mode. Let it run for 2 weeks. Review the denial logs. Fix legitimate access gaps (agents that need permissions they don't have). Only then move to enforce. This is how you get governance adoption without breaking production — which is the number one reason governance initiatives fail.
What "Good" Looks Like
| Capability | Standard | What It Does |
|---|---|---|
| Per-tool policies | OpenFGA (Zanzibar) | Every tool has a policy. "Agent X can read CRM contacts but not write." Granularity at the tool + resource + action level. |
| Default deny | Zero Trust | If no policy grants access, the request is denied. No implicit permissions. No "admin" backdoor. |
| Cascading policies | Governance hierarchy | Organization → Workspace → Team → Agent. Policies cascade and the most restrictive level wins. |
| Delegation control | TBAC | Tool-Based Access Control for cross-agent delegation. Agent A can grant Agent B limited tool access via scoped tokens. The delegation chain is auditable. |
| Kill switch | Emergency halt | Instantly revoke all permissions for an agent, team, or entire tenant. Cascade-enabled. Notification channels. Requires admin approval to restart. |
What "Bad" Looks Like
Binary access (admin or nothing)
Agent can either access "everything" or "nothing." No granularity. A sales agent that needs CRM read access also gets email send, file delete, and database write. One tool's permissions bleed into every other tool.
Static configuration files
Permissions defined in YAML at deploy time, never updated. Agent's actual needs drift from its configuration. Nobody reviews. "Least privilege" decays into "maximum privilege we configured 6 months ago."
Implementation Checklist
- Every tool invocation passes through a policy check (not just application-level auth)
- Default deny — no implicit permissions
- Enforcement modes support progressive rollout (audit → warn → enforce)
- Policies cascade from organization to individual agent
- Kill switch available at agent, team, and organization level
- Delegation chains are scoped, time-limited, and auditable
- Policy changes take effect immediately (not on next deploy)
Pillar 3: Verification
The principle: Don't trust that agents followed policy — verify it. Mathematically, not anecdotally.
Why Verification Matters
Authorization checks individual tool calls. But compliance often requires reasoning about sequences of actions. Did the agent access PII in step 1 and then send data to a US endpoint in step 3? Did total spending across all steps exceed the budget? Did the same agent both approve and execute a payment (separation of duties violation)?
Per-call authorization can't catch these — it only sees one call at a time. Verification adds a cross-step analysis layer that examines agent behavior over a session or task.
Two Modes of Verification
Mode A: Policy Analysis (deploy-time)
Before agents run, analyze the policy set itself for problems:
- Contradictions: Policy A allows what Policy B denies. Which wins?
- Privilege escalation: Agent A can grant permissions to Agent B, who can grant to Agent C, creating an unintended chain.
- Fail-open gaps: Resources with no deny rule — if the default isn't properly configured, they're unprotected.
- Redundant rules: Rules subsumed by other rules, adding complexity without security value.
This is what AWS Cedar's automated reasoning does for IAM policies. For AI agents, the stakes are higher because the action space is larger and the consequences are faster.
Mode B: Execution Verification (runtime or post-hoc)
After (or during) agent execution, verify that the sequence of actions complied with policy:
- Budget accumulation: Total cost across all steps stayed within budget
- Data flow tracking: PII accessed in step N was not transmitted in step M
- Separation of duties: No agent both proposed and approved a sensitive action
- Cross-step constraints: Any rule that requires reasoning about the full session
Verification is complementary to authorization
Authorization is a gate — it blocks individual unauthorized actions in real-time. Verification is a proof — it demonstrates that the full sequence of actions was compliant. You need both. Authorization without verification misses cross-step violations. Verification without authorization catches problems too late.
Execution Certificates
When verification passes, the system issues a cryptographic execution certificate — a signed attestation that the agent's session was verified against a specific set of policies. This certificate can be:
- Attached to audit records as compliance evidence
- Presented to auditors during SOC 2 or regulatory reviews
- Verified independently by any party with the platform's public key
- Used as input for agent reputation systems
Implementation Checklist
- Policy-as-code with a formal language (not natural language descriptions)
- Deploy-time analysis catches contradictions and gaps before agents run
- Runtime or post-hoc verification checks cross-step constraints
- Verification results are cryptographically signed (execution certificates)
- Certificates are independently verifiable (no callback to issuer required)
- Verification failures trigger alerts and can block continued execution
Pillar 4: Audit
The principle: Every action, every decision, every tool call — logged, integrity-protected, and queryable. Not for compliance theater — for incident response.
Why Audit Matters
When (not if) something goes wrong with an AI agent, the first question is "what happened?" If your audit trail is console.log statements scattered across 50 microservices, the answer is "we don't know" — and the average time-to-recover doubles.
SOX requires immutable financial audit trails. HIPAA requires access logs for PHI. GDPR requires processing records. These aren't new requirements — but AI agents generate orders of magnitude more auditable events than human users. An agent that runs for 30 minutes might invoke 50 tools, access 200 records, and make 15 decisions. Your audit system must handle this volume without becoming the bottleneck.
What "Good" Looks Like
| Capability | Why It Matters |
|---|---|
| Tamper-evident logging | Hash-chained entries with HMAC integrity. If someone modifies a log entry, the chain breaks. Auditors can verify integrity independently. |
| Full action capture | Not just "agent ran" but "agent called crm_search_contacts with query {name: 'Acme'}, returned 12 results, took 340ms, cost $0.002." Every tool call, every parameter, every result. |
| LLM pipeline audit | Log the full security pipeline: prompt injection detection (pass/fail), PII redaction (what was redacted), content moderation (score), output validation (pass/fail). Not just the final response. |
| Separate audit storage | Audit logs shouldn't compete with application data for database resources. Dedicated audit database with independent retention, backup, and access controls. |
| SIEM integration | Real-time streaming to Splunk, DataDog, Sentinel, etc. Your SOC shouldn't need to learn a new tool — agent events should appear alongside your existing security events. |
| Retention guarantees | 7+ years for SOX. Configurable per regulation. Visible retention vs. stored retention strategy (upgrade value). |
The LLM Gateway Audit Pipeline
Every LLM call — whether from an AI agent, a coding session, or a direct API request — should pass through a security gateway that audits each stage:
- Budget check: Is the tenant within spending limits?
- Prompt injection scan: Does the input contain adversarial patterns?
- PII redaction: Detect and mask personal data before it reaches the LLM
- Content moderation: Check input against safety policies
- Audit entry: Record the sanitized input, model, and context
- [LLM call]
- Output validation: Check response for policy violations
- Content moderation (output): Verify response safety
- PII restoration: Re-insert redacted PII into response for the user
- Token billing: Record usage and cost
- Audit entry: Record the full pipeline result with cumulative hash
The pipeline hash — a SHA-256 computed cumulatively across all stages — provides an integrity proof that no stage was bypassed. If someone skips prompt injection detection to save latency, the hash chain breaks.
Implementation Checklist
- Every agent action logged with actor, target, action, result, cost, and timestamp
- Audit entries are integrity-protected (HMAC or hash chain)
- LLM gateway pipeline logs each security stage, not just the final result
- Audit storage is separable from application storage
- SIEM export in standard formats (JSON, CEF)
- Retention is configurable per regulatory framework
- Inline audit trail visible in the dashboard (not buried in log files)
Pillar 5: Federation
The principle: When your agent talks to another organization's agent, trust must be verified cryptographically — not assumed.
Why Federation Matters
The value of AI agents multiplies when they can collaborate across organizational boundaries. Your sales agent negotiating with a supplier's procurement agent. Your compliance agent exchanging audit evidence with an auditor's agent. Your engineering agent requesting a code review from a partner's DevOps agent.
But cross-org collaboration introduces risks that don't exist within a single organization: identity fraud (is that really Acme Corp's agent?), data sovereignty violations (did our EU data just get processed in the US?), privilege escalation (did their agent gain access to our internal tools through the collaboration?), and accountability gaps (who is liable when a cross-org agent interaction goes wrong?).
The Trust Problem
Today, cross-org integrations are built on shared API keys, IP allowlists, and contractual trust ("we trust Acme because we signed an NDA"). This doesn't scale to agent-to-agent communication where interactions happen at machine speed without human review.
Federation requires automated trust verification — the equivalent of border control for the Internet of Agents. Every cross-org interaction should verify:
- Identity: The remote agent is who it claims to be (SPIFFE trust bundle verification)
- Authorization: The remote agent is allowed to make this request (delegation chain validation)
- Data residency: Data shared in this interaction stays within agreed-upon boundaries
- Audit: Both organizations have a complete record of what was exchanged
The Emerging Standards (as of March 2026)
| Standard | Governance | What It Does | Adoption |
|---|---|---|---|
| MCP | Agentic AI Foundation (Linux Foundation). Donated by Anthropic Dec 2025. Co-founded with Block and OpenAI. | Tool integration — how agents use tools | 10,000+ public servers. Fortune 500 deployments. |
| A2A | Linux Foundation A2A Project. Initially launched by Google Apr 2025. | Agent-to-Agent — how agents collaborate. Agent Cards, task delegation, SSE streaming. | 150+ organizations including Microsoft, SAP, Adobe. v0.3 stable. |
| SLIM | AGNTCY / Linux Foundation. Formative members: Cisco, Dell, Google Cloud, Oracle, Red Hat. | Cross-org messaging with identity verification. gRPC transport. Post-quantum crypto roadmap. | Production at Swisscom, SRE automation. 75+ companies. IETF draft submitted. |
| OASF | AGNTCY | Open Agent Schema Framework — agent description schema, skill taxonomy, decentralized directory. | Part of AGNTCY stack. Schema finalized. |
| AI Card | Linux Foundation | Unified metadata format across protocols. | Draft specification. |
The standards landscape consolidated rapidly in late 2025 and early 2026. Both MCP and A2A moved to Linux Foundation governance. AGNTCY joined with Cisco, Dell, Google Cloud, Oracle, and Red Hat as formative members. The fragmentation risk that worried enterprises a year ago is resolving — the remaining question isn't which standard but how fast your organization adopts them.
Federation Security Architecture
Trust establishment
Before two organizations' agents can communicate, a trust relationship is established. Each organization exchanges its SPIFFE trust bundle — the public keys needed to verify the other's agent identities. Trust is explicit, revocable, and audited.
Message routing
Cross-org messages flow through a federation bridge that verifies identity, checks trust status, encrypts the payload (AES-256-GCM), and logs the interaction. If trust is revoked mid-session, the bridge terminates the connection immediately.
Circuit breaker
If a remote organization's endpoint becomes unreliable (3 failures within 5 minutes), the circuit breaker opens and blocks further requests. This prevents cascading failures and gives the remote organization time to recover. The circuit resets automatically after the cooldown period.
Implementation Checklist
- Trust relationships are explicit and revocable (not implicit from network access)
- Remote agent identity verified via trust bundle (not API key)
- All cross-org messages encrypted in transit
- Federation bridge with circuit breaker prevents cascading failures
- Both organizations maintain complete audit records of cross-org interactions
- Data residency constraints enforced at the federation boundary
- Built on open standards (SLIM, A2A) — no proprietary lock-in
How the Pillars Compose
The five pillars aren't independent layers — they form a reinforcing system:
| Interaction | What Happens |
|---|---|
| Identity → Authorization | Authorization checks reference the agent's cryptographic identity, not a shared key. Policies are bound to specific agents. |
| Authorization → Audit | Every authorization decision (grant or deny) is recorded in the audit trail with the full policy context. |
| Audit → Verification | Verification samples from audit data to check cross-step compliance. The audit trail IS the verification input. |
| Verification → Identity | Execution certificates are signed with the platform's identity key. Verification status becomes part of the agent's credential. |
| Federation → All | Cross-org interactions extend identity verification, delegation authorization, federated audit correlation, and cross-org compliance attestation. |
The composability test
If you remove any single pillar, the others degrade. Authorization without identity can't attribute decisions. Audit without authorization has no policy context. Verification without audit has no data to verify. Federation without identity can't verify trust. This is why point solutions (just audit, just authorization) don't achieve governance — you need the integrated system.
Chapter Summary
The Five Pillars — Identity, Authorization, Verification, Audit, and Federation — are the architectural foundations of AI governance at Level 4+. Each pillar addresses a specific governance dimension that enterprise IAM, SIEM, and compliance tools don't cover for AI agents. The pillars compose into a reinforcing system where each one strengthens the others.
The next chapter maps these pillars to specific regulatory requirements — EU AI Act, GDPR, HIPAA, SOX, DORA, and NIS2 — with control mapping tables your CISO can hand directly to an auditor.