CTO Toolkit
Agent Autonomy Model
Risk-tiered levels defining how much authority an AI agent receives for a specific change.
How to use this
Assign a level per class of change, not per tool. Start conservative and widen deliberately as evidence accumulates. Record the level on the execution contract so reviewers know what was permitted.
The levels
- A0 Read only — investigation and explanation. No write access.
- A1 Autonomous — documentation, formatting, test-only additions. Standard review at merge.
- A2 Autonomous with mandatory verification — normal application change. Cannot merge without a complete evidence pack.
- A3 Human approval before execution — auth, payments, migrations, infrastructure. Agent may plan and propose only.
- A4 Human-controlled execution — production operations, destructive actions, secrets. A human executes.
Assigning a level
- How reversible is this change if it is wrong?
- What is the blast radius — one component, one service, or customer data?
- Does it cross a security, financial or regulatory boundary?
- Can automated verification actually detect failure here?
- Would a junior engineer be allowed to do this unsupervised?
Guardrail design
- Least privilege by default — widen deliberately, never implicitly
- Bypass paths exist but are auditable; an unusable rule gets routed around
- Agent identity is distinct from human identity in every audit log
- Permissions are scoped per task, not granted permanently
- Escalation is cheap enough that agents actually use it
Anti-patterns
- Granting autonomy by tool rather than by risk of the change
- One blanket permission set for every repository
- Approval fatigue — asking humans to confirm every trivial action
- Treating an agent as accountable; accountability stays with a named human
This is an original, generic framework for reuse. It is not proprietary employer material.