AI coding agents create a new security review problem because they can move from suggestion into software delivery. The practical question is not only whether the generated code is safe. It is whether the workflow can write code, modify workflow files, run commands, use credentials, reach MCP-declared tools, publish packages, or touch production-adjacent paths.
A practical control model
1. Discover where agents enter delivery
Map IDE agents, cloud agents, CI bots, repo automations, MCP configs, workflow files, package scripts, and release paths.
2. Map action authority
For each path, identify the owner, credential, action class, target system, and whether the authority is standing or scoped.
3. Classify actions
Allow low-risk read and test actions. Require approval for write, credential-bearing, deploy, publish, destructive, or production-adjacent actions.
4. Keep evidence
Record actor, owner, repo, workflow, credential source, target, approval decision, validation, timestamp, and outcome.
Security checklist for AI coding agents
- Require clear ownership for every AI-assisted workflow that reaches PRs, CI/CD, credentials, or release paths.
- Track whether the workflow can read code, write code, modify workflow files, run shell commands, or call external tools.
- Avoid broad standing credentials for high-risk actions. Prefer scoped, short-lived access tied to owner, repo, branch, task, and time.
- Require independent review before agent-authored changes can merge into protected branches.
- Require approval for workflow-file changes, deployment steps, package publishing, cloud API calls, database writes, and destructive commands.
- Keep evidence of the approval decision, credential source, validation results, and target system outcome.
- Review permission settings and deny rules for local and cloud coding agents, especially around shell commands, network access, and protected files.
Use vendor controls, then map what remains
Major coding-agent products now expose security controls, but each control applies to a specific surface. GitHub documents branch, pull request, Actions, and traceability behavior for Copilot coding agent. Claude Code documents permission modes, allow/ask/deny rules, and sandboxing. MCP defines authorization and security best practices for tool servers.
These controls matter. They still do not give every security team a single buyer-readable map of all AI-assisted software delivery action paths across repos, CI/CD, credentials, tools, and release workflows. That map is the role of an Agent Action BOM.
What evidence should exist?
For security review, customer trust, or audit response, the useful evidence is specific:
- who initiated or owns the AI-assisted workflow,
- which repo, PR, branch, workflow, script, or tool config was involved,
- which credential or identity was used,
- what action was taken and which system was affected,
- who approved the action or merge,
- which validation ran, and
- where the evidence pack, logs, and approval record are retained.
Source notes
- GitHub Copilot cloud agent docs describe pull-request workflows, a GitHub Actions-powered environment, and branch limitations.
- GitHub responsible-use guidance describes workflow approval, runtime permissions, secrets handling, signed commits, and traceability for Copilot cloud agent.
- Claude Code permissions docs describe tool permissions, approval modes, allow/ask/deny rules, and managed settings.
- MCP security best practices describe token passthrough and confused deputy risks for MCP implementations.
Map the action paths before scaling adoption.
Clyra runs a local/private assessment across two to three repos or workflows and returns an action-control graph, Agent Action BOM, and evidence pack.
Request assessment