A useful AI coding-agent approval policy separates ordinary engineering work from credentialed action. The goal is to keep adoption moving while making sensitive actions visible, approved, and reconstructable afterward.
Starter approval policy
Allow
- Normal code edits in repo scope
- Tests, linting, docs, local refactors
- Read-only repo analysis
- Non-sensitive review comments
Approve
- Workflow or CI/CD config edits
- Package install, build, release, or publish scripts
- MCP or internal tool calls
- Cloud CLI, infrastructure, deploy, or database actions
- Actions using standing service tokens or CI secrets
Block
- Disabling required checks
- Unmanaged secret reads
- Broad static key use without owner or purpose
- Destructive production actions without break-glass process
Approval triggers teams can recognize
| Trigger | Practical policy language |
|---|---|
| Workflow or runner change | Require approval before an AI-assisted change can alter CI/CD jobs, reusable workflows, runner labels, or release automation. |
| Credentialed action | Require approval before a path can use a CI secret, service account, package token, signing key, or cloud role. |
| Write to shared systems | Require approval before a tool call, script, or job can write to Jira, Slack, GitHub, cloud APIs, feature flags, databases, or internal admin tools. |
| Release or production-adjacent target | Require approval and retained proof before deploy, publish, migration, infrastructure, or customer-impacting actions run. |
Evidence the approval should create
- Human owner or accountable team.
- Agent, workflow, tool, repo, branch, and PR.
- Credential or identity source and scope.
- Action requested, target system, and risk tier.
- Approver, approval reason, policy decision, and timestamp.
- Validation result, final outcome, and evidence location.
Common policy mistakes
The first mistake is trying to approve every AI interaction. That slows developers and trains teams to route around the process. The second mistake is only approving the PR while ignoring what CI/CD, package scripts, tools, or service tokens can do after merge. The control belongs at the first meaningful action boundary.
Source notes
- Claude Code permissions docs describe allow/ask/deny rules, permission modes, and tool-level decisions.
- GitHub responsible-use guidance discusses approval and traceability controls for Copilot cloud agent workflows.
- MCP security best practices emphasize consent, least privilege, token security, and auditability for tool-connected systems.
Turn the policy into a map.
Clyra maps which selected workflows stay allowed, which need approval, and which gaps block proof.
Map one workflow