CI/CD turns an AI-assisted change into an executable path. A pull request can trigger tests, build scripts, package managers, deployment jobs, cloud commands, and release automation. The security job is to know which agent-assisted paths can reach those systems and where approval is required before the path runs.
CI/CD surfaces to map
Workflow files
Changes to GitHub Actions, GitLab CI, Buildkite, CircleCI, Harness, or similar workflow definitions.
Credential inheritance
CI secrets, cloud keys, package tokens, service accounts, environment variables, and OAuth grants.
Build and test scripts
Package manager commands, shell scripts, setup steps, generated code, test runners, and install hooks.
Release paths
Deploy jobs, package publishing, artifact signing, infrastructure changes, migrations, and production-adjacent commands.
Which CI/CD actions should require approval?
Approval should focus on actions with real blast radius, not every prompt or code suggestion.
- workflow-file changes, especially changes that alter permissions or execution conditions,
- jobs with access to production, staging, release, package, or signing credentials,
- package publish, deployment, infrastructure, database, and destructive jobs,
- jobs that can exfiltrate artifacts, logs, secrets, or customer-sensitive data, and
- changes that widen network access, tool access, or MCP server reach.
What evidence should remain after CI/CD runs?
For an AI-assisted workflow, the evidence pack should connect the software change to the operational action.
- the agent or workflow involved,
- the human owner or requester,
- the repo, branch, PR, workflow, and job,
- the credential or environment used,
- the approval decision and approver,
- the target system or package registry, and
- the job outcome and retained logs.
Why GitHub Actions is a useful example
GitHub documents Copilot coding agent as operating through pull requests and a GitHub Actions-powered environment. GitHub also documents approval and traceability constraints for the Copilot cloud agent. Those controls are useful examples of how agentic development is becoming part of normal delivery infrastructure.
The same review question applies outside GitHub: which workflow can run, what credentials are reachable, which systems can be affected, and what evidence exists if security asks later?
Source notes
- GitHub Copilot cloud agent docs describe pull-request workflow behavior, a GitHub Actions-powered environment, and branch limitations.
- GitHub responsible-use guidance describes workflow approval, runtime permissions, secrets handling, and traceability for Copilot cloud agent.
- Claude Code permissions docs describe permission modes and tool rules for file, shell, network, and MCP access.
Map CI/CD action paths before they become normal.
Clyra reviews two to three repos or workflows and returns an action-control graph showing credential, approval, and evidence gaps.
Request assessment