AI Code Governance Checklist

Instructions

Complete this checklist when implementing governance controls for AI-generated code in your CI/CD pipelines. Work through each section in order. Every item should be addressed before considering your governance framework production-ready. If any section has unfinished items, document the gap and assign an owner.

1. AI PR Detection Setup

• Co-authored-by trailer patterns defined for all AI tools in use
• PR labels for AI-generated changes configured and required
• Bot accounts and GitHub App authors identified and tracked
• Branch naming conventions for agent-created branches enforced
• Detection logic tested against known AI-generated PRs (zero false negatives)
• Detection redundancy in place (multiple signals checked, not just one)

2. Policy Configuration

• Allowed file patterns defined (directories and file types agents may modify)
• Blocked file patterns defined (auth, CI/CD, infrastructure, secrets)
• Scope limits set for maximum files per PR
• Scope limits set for maximum lines added per PR
• Policy file (.ai-code-gate.yml or equivalent) checked into the repository
• Policy violations produce hard blocks (not just warnings)
• Policy exceptions require documented justification and manual override

3. Security Scanning

• Secret detection scanner configured and running on all AI-generated diffs
• Dependency vulnerability scanner checking newly added packages
• Hallucinated package detection in place (packages that do not exist in registries)
• Static analysis (SAST) running for all languages in the repository
• Infrastructure-as-code scanner configured if Terraform/CloudFormation/Docker is in scope
• Scan thresholds for AI-generated code are stricter than for human-authored code
• High-severity scan findings produce hard blocks on merge

4. Sandboxed Execution

• Container-based sandbox environment provisioned for AI-generated code
• Sandbox has isolated filesystem (no write-back to host)
• Sandbox network access restricted or fully disabled
• Sandbox resource limits set (CPU, memory, execution timeout)
• Sandbox runs without root privileges and without Docker socket access
• Test suite executes inside sandbox against AI-generated changes
• Sandbox results reported back to the PR as status checks

5. Review Gates

• Risk scoring factors defined and weighted (files changed, lines added, sensitive paths, scan findings)
• Risk tiers configured (low, medium, high) with score thresholds
• Low-risk tier auto-merge policy documented and approved by security team
• Medium-risk tier requires at least one human approval
• High-risk tier requires two approvals including security team member
• Risk score and tier displayed in PR comments for reviewer context
• Review gate cannot be bypassed by removing labels or re-opening the PR

6. Audit Trail

• Trigger events logged (who initiated, what prompt, what task)
• Detection results logged (which signals matched, confidence level)
• Policy check results logged (patterns evaluated, violations found)
• Scan results stored as versioned artifacts linked to the PR
• Risk score calculation logged with all contributing factors
• Review decisions recorded (who approved, when, with what comments)
• Audit events emitted as structured JSON (not unstructured log lines)
• Audit data retained per compliance requirements (SOC 2, ISO 27001, etc.)
• Post-incident replay possible from audit records alone

Review Decision