# AI Agent Governance Framework — Template

A minimal, working governance framework for teams running AI agents against real
systems. Three artifacts: a **constitution** (the non-negotiables), a **permissions
matrix** (who may do what), and **merge authority rules** (where the human sits). Fill
in the brackets; delete what you do not need; put the result in version control next to
your code, because governance that is not reviewed like code rots like code.

Distilled from the governance that runs the Turbo Rig coding rig (agents build, AI
reviews, humans merge) — adventureonthewave.com/agentic-engineering/agent-governance.
Marcus Patman, Adventure On The Wave. Free to use, no warranty. Version 1.0, October 2026.

## 1. The constitution

Write it as short laws an engineer — or an agent — can apply without judgment calls.
Real examples below; keep the count small enough to remember.

```
1. Agents never merge their own work. Merge authority is human-only.
2. No force-push, no direct pushes to main, by anyone, including automation.
3. Secrets never enter prompts, repos, logs, or agent memory. They live in [SECRETS MANAGER].
4. Every agent runs under a budget of [MAX UNITS/DAY], enforced by the platform.
5. Destructive actions (deletes, deploys, publishes, payments) require a human approval, by construction.
6. When the review gate cannot run or cannot decide, the change does not ship. Missing verdict = rejection.
7. Every agent action leaves a trace we can audit: input, action, cost, change, time.
```

Add per team: data boundaries ("agents never touch [SYSTEM]"), change windows,
escalation paths.

## 2. The permissions matrix

One row per actor, one column per capability. Fill with **grant / deny / human-required**.
The point is that the matrix is enforceable in config (CI rules, IAM scopes, branch
protection), not aspirational prose.

| Capability                    | Coding agent (builder) | AI reviewer (gate) | Human engineer | Automation / CI |
| ----------------------------- | ---------------------- | ------------------ | -------------- | --------------- |
| Create branches               | grant                  | deny                | grant          | grant           |
| Push to own branch            | grant                  | deny                | grant          | grant           |
| Approve PR                    | deny                   | grant (verdict)     | grant          | deny            |
| Merge to main                 | deny                   | deny                | grant          | deny            |
| Deploy to staging             | grant (via PR)         | deny                | grant          | grant (post-merge) |
| Deploy to production          | deny                   | deny                | human-required | deny            |
| Read production secrets       | deny                   | deny                | human-required | grant (scoped)  |
| Rotate credentials            | deny                   | deny                | grant          | grant (CI vault) |
| Spend above [THRESHOLD]/day   | deny                   | deny                | grant          | deny (hard cap) |
| Delete data / infrastructure  | deny                   | deny                | human-required | deny            |

Rules of thumb while filling yours:

- If a cell says "grant", you must be able to name the mechanism that enforces the
  boundary (branch protection, IAM policy, CI rule) — not the convention.
- If you cannot name the mechanism, the cell is "human-required" until you can.
- The AI reviewer gets **verdict authority, never merge authority**. Its review is an
  input to a human decision, not the decision.

## 3. Merge authority

- The merge is the control point. Everything expensive happens after it, so nothing
  automated happens at it.
- Quorum for risky classes: changes to the constitution, the matrix itself, security
  surfaces, or payments require [N] human approvers — pick N ≥ 2.
- The gate is fail-closed: reviewer unavailable, quota exhausted, or verdict unparsable
  all mean **do not ship**. Convenience is not a verdict.
- Override paths (if you must have them) are logged, rate-limited, and reviewed in the
  weekly [GOVERNANCE REVIEW].

## 4. Operating the framework

- Store all three artifacts in the repo (e.g. `GOVERNANCE.md`, `PERMISSIONS.md`), review
  them like code, and date every change.
- Re-run the matrix against reality monthly: any permission that drifted from the matrix
  is an incident, not a cleanup.
- New tool, new model, new agent = matrix review before it gets credentials.

---

Adoption notes, evidence from a real governed rig, and how this maps onto a team
rollout: adventureonthewave.com/agentic-engineering/agent-governance-framework and
adventureonthewave.com/consulting/team-onboarding.