Checklist
AI Coding Agent Governance Checklist
A practical checklist for teams letting Claude Code, Codex, OpenCode, Cursor, GitHub Copilot Coding Agent, or MCP-enabled agents touch real repositories.
The core rule
Review intent before execution. A coding agent should not discover its own authority while it is already changing the repo. The approved artifact should say what outcome is allowed, where the agent may act, how success will be verified, and when the run must stop or return to review.
1. Name the work before the agent starts
- Write the intended outcome in one sentence.
- List the repo, branch, issue, PR, or spec that defines the task.
- Decide whether this is a low-risk edit, a bounded implementation, or a high-risk change needing explicit approval.
2. Bound the blast radius
- List the files, directories, packages, services, and configuration surfaces the agent may touch.
- Call out forbidden areas: credentials, production config, migrations, billing, auth, deploy pipelines, or customer data.
- Require review before the agent expands scope beyond the approved boundary.
3. Classify tool and MCP access
- Separate read-only tools from tools that write files, run shell commands, call APIs, send messages, or deploy code.
- Treat every MCP server as a capability boundary, not just a convenience integration.
- Approve high-effect tools per task, not globally because they were useful last time.
4. Put approval before execution
- Review the plan before the agent mutates the repo, not only after the diff exists.
- Make the reviewer edit the allowed outcome, scope, validation plan, and stop conditions directly.
- Do not let the worker approve its own expanded plan or self-certify vague success criteria.
5. Define validation evidence
- Name the exact checks that prove the work is done: tests, build, lint, screenshot, migration dry run, or manual acceptance step.
- Require command names and outputs in the handoff, not just a natural-language claim that checks passed.
- Decide which failures stop the run and which are acceptable to report as blockers.
6. Preserve an audit trail
- Keep the approved plan, scope changes, tool approvals, validation output, and final handoff together.
- Make drift visible: what changed from the approved intent, who accepted it, and why.
- Prefer a reviewable artifact over a long transcript that has to be reconstructed after the fact.
Turn the checklist into a Goal Contract
Caskade turns this review into a concrete Goal Contract: outcome, blast radius, validation plan, and stop conditions approved before execution. The checklist is the first public artifact; the product loop is the review surface that keeps those boundaries alive while agent work progresses.
Bring us a real agent workflowFAQ
What is AI coding agent governance?
AI coding agent governance is the set of review, approval, access, validation, and audit practices that decide what a coding agent may do before it changes a real repository.
Where should the human approval step happen?
For non-trivial work, the first meaningful approval should happen before execution: review the outcome, blast radius, validation plan, and stop conditions before the agent starts mutating files.
How is this different from reviewing the final pull request?
Pull-request review still matters, but it is late. Caskade's view is that the plan itself should become a reviewed Goal Contract before the repo changes, so drift and unsafe scope expansion are caught earlier.