Time to read: 18 minutes Time to apply: 60 minutes to audit and establish governance Prerequisites: All Modules 3-12 — governance is useless without a working agent to govern
They give an agent autonomy and walk away. No boundaries, no registry, no audit. The agent has access to tools, models, and data — and nobody watching what it does with them.
Then something goes wrong. The agent deploys to the wrong environment. It accesses a dataset it shouldn't. It spends $500 in inference credits on a runaway loop. The reaction is _tighter controls_, but controls without a governance framework are just reactionary walls — they block the good and the bad equally.
The Sorcerer's Apprentice isn't a fable about magic. It's a fable about giving a tool capabilities without governance. The broom works until it doesn't, and you don't have the axe to stop it.
Agents scale faster than your ability to supervise them. Phase 4 (Harden) taught you how to make an agent reliable. This module teaches you how to govern what it can do, who it acts for, and how to verify it didn't overstep.
Governance doesn't mean zero autonomy. It means calibrated autonomy — the right level of freedom for the right level of risk.
ANARCHY ←—— AUTONOMY ——→ GUARDRAILS ——→ COMPLIANCE
| | | |
Do Decide Act within Act within
anything independently written rules audited rules
+ audit trail
These aren't stages you pass through. They're regimes an organisation operates in simultaneously, depending on the agent's role and what it touches:
| Regime | Risk Profile | Example | Governance Needs |
|---|---|---|---|
| Anarchy | Experimental / sandbox | A developer's local coding agent, no production access | Minimal — the damage radius is contained to the developer's machine |
| Autonomy | Low risk, fast feedback | A CI bot that runs tests, lints, and generates reports | Decision protocols (covered in Module 6), output verification (Module 11) |
| Guardrails | Medium risk, human oversight | A deployment agent with staging access but not production | Registry + policy enforcement + escalation path |
| Compliance | High risk, regulated | An agent handling financial transactions, patient data, or government records | Full stack: registry, gateway, delegation chain, audit trail, attestation |
The mistake is treating all agents the same. A sandbox coding agent doesn't need the same governance as a production deployer. Calibrate to risk.
No matter the autonomy regime, three capabilities must exist before any agent can act on your behalf in a shared environment:
1. Agent Registry — Who is allowed to act? Every agent must be registered before it can interact with other agents, access tools, or call models. The registry maintains: agent_id, public key, capabilities, status (active/rotating/revoked/suspended), and an audit log of all status changes.
A registry without identity (the crypto binding from our Identity Protocol) is a guest list. A registry _with_ identity is a verifiable chain of who did what.
2. AI Gateway / Policy Enforcement Point (PEP) — What are they allowed to do? Every request — whether to a model, a tool, an API, or a data store — passes through a single enforcement point. The gateway checks: is this agent registered? Does this agent have permission for this action? Is this action within rate limits? Is the target resource allowed?
The gateway doesn't guess. It enforces explicit policy. Policy is not a prompt — it's a structured, versioned document.
3. Delegation Framework — On whose behalf are they acting? An agent can only act within the authority delegated to it. Delegation is scoped (which actions, which resources, how long) and chained (Agent A delegates to Agent B, which delegates to Agent C — the chain preserves the original authority and scope).
Without delegation: any agent can claim to act for any user. With delegation: every action carries a verifiable chain of authority back to the human who authorised it.
These three capabilities don't exist in isolation. They form a stack:
┌──────────────────────────────────┐
│ ACCOUNTABILITY │ ─ Who's responsible?
│ Audit log, attestation, report │
├──────────────────────────────────┤
│ VALIDATE │ ─ Did they stay within policy?
│ Post-hoc verification, drift │
│ detection, violation alerts │
├──────────────────────────────────┤
│ MONITOR │ ─ What are they doing?
│ Real-time logging, metrics, │
│ anomaly detection │
├──────────────────────────────────┤
│ BOUNDARIES │ ─ What are they allowed to do?
│ Gateway/PEP, delegation scope, │
│ rate limits, resource access │
├──────────────────────────────────┤
│ IDENTITY │ ─ Who is acting?
│ Registry, crypto binding, │
│ key rotation, revocation │
└──────────────────────────────────┘
Each layer depends on the one below it. Identity without boundaries is a guest list. Boundaries without monitoring is blind enforcement. Monitoring without validation is noise. Validation without accountability is theatre.
The most common mistake in agent governance: putting rules in the system prompt.
Prompts are instructions, not policy. They're unversioned, unenforceable, and the agent can ignore them. Policy is structured, versioned, machine-readable, and enforced at the gateway level — not the model level.
A policy document:
policy_version: "1.0.0"
agent_id: "deploy-bot"
permissions:
- action: "deploy"
target: "staging"
constraint: "branch == main && tests_pass == true"
- action: "api_call"
target: "ec2:*"
effect: "deny" # explicit deny beats allow
- action: "model_inference"
model: "claude-*"
rate_limit: "100/hour"
delegation:
max_depth: 2
allowed_delegates: ["review-bot", "build-bot"]
scoped: true # sub-agent inherits parent scope
This policy says: deploy to staging, but only from main with passing tests. Never touch EC2. Use Claude models at most 100 times an hour. Delegate to review-bot or build-bot, but only 2 levels deep.
The agent never sees this document. The AI gateway enforces it. If the agent tries to deploy to production, the gateway blocks it before the deployment command ever runs.
User
│
▼
Agent (autonomous, delegated authority)
│
▼
┌───────────────────┐
│ AI Gateway/PEP │ (policy enforcement point)
│ │
│ ✅ Registry? │──NO──→ Reject + Log
│ ✅ Permission? │──NO──→ Reject + Log
│ ✅ Rate limit? │──NO──→ Throttle + Log
│ ✅ Scope valid? │──NO──→ Reject + Log
└───────────────────┘
│
▼
┌───────────────────┐
│ Model / Tool / │ (actual execution)
│ API / Data │
└───────────────────┘
│
▼
┌───────────────────┐
│ Audit Log │ (immutable, signed)
└───────────────────┘
The gateway is the choke point. Every request goes through it — model inference, tool execution, API calls, data access. If the gateway doesn't exist, governance is aspirational.
I ran an agent pipeline that deployed SPFx web parts to a test environment. One session, a misconfigured loop caused the agent to rebuild and redeploy 47 times. Each rebuild called a model, ran a build, and triggered a deployment. In 22 minutes: $246 in inference costs, 47 deployments to a test environment that needed exactly one.
After governance:
deploy-bot identity. Unknown agents can't deploy.The runaway still happened. But it cost $5.22 (one deployment) instead of $246. And it was caught in seconds rather than discovered on the monthly invoice.
An PR review agent with governance:
policy_version: "1.0.0"
agent_id: "review-bot"
permissions:
- action: "read_code"
target: "repo:*"
effect: "allow"
- action: "comment_on_pr"
target: "repo:works-with-agents/*"
effect: "allow"
- action: "merge_pr"
target: "*"
effect: "deny" # never merge
- action: "model_inference"
model: "*"
rate_limit: "200/day"
delegation:
max_depth: 0 # review-bot cannot delegate
This agent can review any repo, comment on WWA PRs, and make up to 200 model calls per day. It can never merge, never delegate. If a prompt injection tries to make it merge or delegate, the gateway blocks it — the agent doesn't get to decide.
An agent handling GDPR subject access requests needs a different regime:
policy_version: "1.0.0"
agent_id: "sar-processor"
permissions:
- action: "read_data"
target: "db:user_data"
constraint: "where request_id matches active_sar"
effect: "allow"
- action: "read_data"
target: "db:*"
effect: "deny" # explicit deny everything else
- action: "api_call"
target: "email:*"
effect: "deny" # never send emails autonomously
- action: "model_inference"
model: "gpt-4*"
effect: "allow"
- action: "model_inference"
model: "claude-*"
effect: "deny" # only approved models for PII
delegation:
max_depth: 0
audit:
level: "full" # log every single action
retention: "7 years"
attestation: true # signed attestation per session
PII only goes to approved models. Only the exact user data for the active request can be read. Every action is logged and attested. This agent can operate autonomously for hours — and a regulator can verify every single action it took.
| Pitfall | What happens | Fix |
|---|---|---|
| Rules in prompts, not policy | Agent ignores or "forgets" restrictions — no enforcement | Move all constraints to gateway-enforced policy documents. Prompts for guidance, policy for enforcement. |
| No registry | Unknown agents appear and act — no way to identify them | Every agent registers before first action. Registry is the single source of truth for who's allowed. |
| No gateway | Agents call models/tools directly — governance is aspirational | Every request goes through the gateway. No exceptions. The gateway is the only path to execution. |
| Flat permissions | All agents get the same access — lowest-common-denominator security | Agent-specific policies. Review-bot can't deploy. Deploy-bot can't review PII. |
| No delegation chain | Agent B acts for Agent A's user without verification | Delegation tokens: signed, scoped, time-bound. Verify the chain before every action. |
| Audit without reading | Logs pile up but nobody checks them | Automated drift detection + weekly audit review. If nobody reads it, it didn't happen. |
| Governance at deployment, not design | Agents built without governance, retrofitting is painful | Include governance requirements in the agent design phase. Policy before code. |
| Over-governance | Every action requires approval — agents are useless | Calibrate to risk. Sandbox agents need minimal governance. Production deployers need the full stack. |
| Assuming the model enforces policy | "I told the model not to do it" — models follow instructions loosely | The model doesn't enforce policy. The gateway does. They are not the same thing. |
Time investment: 60 minutes for the audit and first policy. Return: prevented runaways, verifiable compliance, auditable agent actions.
Governance is the capstone of the methodology. The 10 patterns give you a working, reliable, compounding agent system. Governance makes it safe to operate at scale.
From here, the bonus modules cover specific governance-dense domains:
Or go back to the beginning and build your foundation: Phase 0: The Stage.
Module 13 of 13. From the Works With Agents methodology — open specifications and SDKs for AI agent interoperability at workswithagents.dev.