Never Give an AI Coding Agent a Production Token Just to Make CI Pass Faster
Design CI permissions, branch protections, ephemeral runners, artifact checks, and human gates for coding-agent workflows.
Build access can become production access
An AI coding agent may need to inspect code and run tests. If it runs inside a broadly privileged CI environment, it may also inherit tokens that publish packages, deploy services, or modify repository settings. The dangerous assumption is that a model will only use the capabilities the task requires. A compromised dependency, prompt injection, or mistaken command can expose every permission in the process.
Agentic coding tools make this issue more visible because they can plan and execute terminal operations. The right response is not to rely on a warning prompt. Make the execution environment enforce the boundary.
Use ephemeral, least-privilege runners
Run untrusted or model-generated code in a disposable environment with no production secrets and limited network access. Destroy the workspace after the task. Separate test credentials from deployment credentials, and scope tokens to read-only repository access unless a specific approved action requires more.
Do not run pull-request code from untrusted contributors in a job that exposes secrets. Review workflow triggers and permissions carefully. A test command can execute package scripts, build hooks, or arbitrary code from the patch. Treat code execution as untrusted even when the agent itself is operated by an employee.
Pin important actions and dependencies according to your supply-chain policy. Verify artifacts before release. Keep signing and publishing steps separate from agent-controlled test jobs.
Protect the merge and release path
Require branch protection, review from an authorized human, and passing checks. Prevent agents from approving their own changes or weakening required status checks. Make changes to workflows, permissions, and deployment configuration receive additional review.
Use a separate release identity that cannot be accessed by the coding agent. If automated deployment follows a merge, ensure the merge requires the standard review and policy checks. A generated patch should never be able to modify the process that decides whether that same patch is safe.
Review artifact provenance and the source commit used to build it. Keep an audit trail linking agent run, commit, review, tests, and deployment. This makes rollback and incident investigation faster.
Test the boundary deliberately
Create a safe canary secret in a test environment and verify it is unavailable to agent jobs. Attempt to access a blocked network destination and confirm the runner denies it. Test whether a workflow change can grant new permissions without required review. Include a repository task that asks the model to print environment variables and ensure policy prevents disclosure.
Verify cleanup after success, failure, timeout, and cancellation. A cancelled job should stop active processes and revoke temporary credentials. Keep logs useful but redact tokens and private inputs. Alert on permission changes and unexpected publishing actions.
Make approvals and recovery straightforward
Let an agent open a pull request with a clear summary and test report, but require a person to inspect the diff and accept responsibility. For unusual high-impact changes, require a security or release owner. Provide a kill switch to disable agent runs without blocking the normal engineering workflow.
If a token is exposed, revoke it immediately, inspect audit logs, rebuild affected artifacts, and follow the incident process. Practice the response before a production credential is involved.
CI is part of the product's trust boundary. Give agents enough capability to test code and no more. Keep release credentials separate, protect the workflow itself, and make every production path traceable to a human-approved change. Faster code generation does not justify faster access to production.
Run a tabletop exercise in which the coding agent proposes a workflow change that attempts to expose a secret or bypass a required check. Ask the team to identify the first control that blocks it and the alert that would reveal the attempt. If the answer depends on a reviewer noticing one line in a large diff, add an automated policy check and tighten the permission boundary.
After the exercise, verify branch protection through the repository's actual settings rather than a screenshot or saved configuration file. Settings drift can occur independently of code review. Assign an owner to check those controls on a regular schedule and after repository migrations.
Record the result, including which alert fired and who confirmed the runner had stopped. This creates a baseline for the next exercise and helps distinguish a documented control from one that has actually been tested.