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 control question is 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 commands that can affect production.
Two CI/CD paths that deserve review
GitHub Actions release path
Agent-assisted PR changes `release.yml`; the job uses `GITHUB_TOKEN`, package registry token, or signing key; publish runs after merge.
Generic pipeline deploy path
AI-authored config changes a Buildkite, GitLab CI, CircleCI, or Harness step that can assume cloud role, run migration, or trigger deploy.
Which CI/CD actions should require approval?
Require approval for workflow changes that use credentials, publish, deploy, sign, migrate, or change infrastructure.
- 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 packet 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 a customer, auditor, or incident review 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 maps selected repos or workflows and returns an action-control graph showing credential, approval, and evidence gaps.
Map one workflow