How to Connect AI Coding Agents to CI Safely

Four controls decide whether security will sign off: who has access, what the policy allows, how data moves and whether anyone measures adoption. Settle them before the pilot starts, because they apply whichever tool you pick.

The owner column matters as much as the controls. A control with no named owner goes unchecked until someone has to answer for it. If nobody owns identity, for example, nobody checks that people who leave lose access.

Security does not own all four. Identity is IT's system of record, and policy is engineering leadership's call about what the team may ship. Adoption belongs to whoever owns developer experience. Security owns the data-flow question and the audit path, and it will ask about both.

Data flow is the question that stalls approvals, so answer it before the review meeting. Write down what the tool can read, what it can change, what leaves your network and where any of it is retained. Most of the answers come from the vendor's documentation and your own configuration. Ask the vendor for anything the documentation leaves out, and note where each answer came from.

The stack below breaks a rollout into layers. Policy comes first because the other layers carry it out. Identity controls who gets access, workflow moves code from prompt to merge, and measurement shows whether the rollout is working.

Start narrow, and expand only when the pilot earns it.

1. 1Week 1: pick one team, one repo and three realistic tasks.
2. 2Week 2: write the workflow standard from the pilot.
3. 3Week 3: train champions and add policy guardrails.
4. 4Week 4: expand only after quality, cost and review load are visible.

Treat the four weeks as an order, not a deadline. The first two weeks mostly show you what your standard should say. A pilot too broad to watch closely can't teach you that, so it starts with one team and a few real tasks. Pick the team that will tell you when something breaks, even if another team would produce a better-looking result. Put policy and training in place before the rollout grows, because both are harder to add once people have formed their own habits.

Expansion is the step to slow down. After a good pilot, the pressure to widen access can arrive before the evidence does. Before you add teams, answer three questions with numbers: did review load go up or down, what does a developer cost per month, and did quality hold.

Record the same numbers before the pilot starts, so you have a baseline to compare against. Two more weeks of the same pilot cost less than a rollout you have to walk back, so run them if any answer is still a guess.

Keep credentials out of the agent's context entirely. Use a helper script that sets the secrets in the shell's environment, and have the agent call the script by name. The agent drives the terminal as a tool and reads its output, but the shell's environment variables are never shown to it, unless a command prints them.

One security engineer, an admin on both GitHub and AWS, uses this pattern. He types something like creds prod, the script exports the environment variables, and the agent can then run elevated AWS commands without ever holding the secrets. He still approves every elevated command and reads each one, often a complex aws ... | jq parse.

The same pattern works for any privileged system an agent has to drive. Keep the secret in the environment, put the elevated step behind explicit approval and read each command before you approve it, including any that would print the environment.

Your Run Mode decides whether that approval happens. Allowlist asks before any command that isn't on your allowlist. Auto-review, the recommended default, can run a command without asking once its classifier allows it, and Run Everything never asks. In CI, nobody approves commands by hand, so a permissions policy has to do that job.

Leave branches, commits, pushes and pull request comments to the workflow. Cursor's GitHub Actions guide recommends this restricted approach, with permission-based restrictions, for production CI. The agent only changes files in the working directory, and later workflow steps create the branch, commit, push and post the comment. The critical operations then stay deterministic and auditable.

Print mode supports the split. Without --force, agent -p only proposes changes and doesn't modify files. Add --force only to the step where the agent is meant to write, and pair it with a permissions file that denies Shell(git), Shell(gh) and writes to .env*.

The per-command approval prompt goes away. agent -p "..." runs headlessly: one prompt goes in and one result comes out. That is the form you use in a CI job, a git hook or a shell script, where nobody sits at a keyboard to approve steps.

Cloud agents, including the ones Automations start, don't stop for approval either. They don't use Run Modes, and they never ask you to approve an action.

With nobody at the prompt, put a review gate before anything merges, as you would for any unattended automation.

Write the allow and deny policy before the first pipeline run. A policy written afterwards only describes what the agent already did. In an interactive session, that discovery is cheap: a command comes up, you decline it and you move on. In CI, you read about the command in a log after it has run.

Start with read access, add a narrow rerun next, and allow nothing that writes to the branch until the rest has become routine. A right to rerun is also a right to retry in a loop. An agent that can rerun a job can rerun it many times, and from the outside that looks like progress.

Where to draw the rerun boundary depends on what one job in your pipeline is allowed to touch. Rerunning a job that only runs tests costs compute. Rerunning a job that deploys or publishes repeats the deploy.

A retry loop does show up as spend. CLI and headless jobs authenticate with an API key set in CURSOR_API_KEY, and their usage appears in team analytics and billing with everyone else's. Check that dashboard in the pipeline's first week, not at the end of the month.

Somebody named, recorded in the same place as your other service accounts. The control table above gives identity to IT and data flow to security. An agent's CI key falls between the two, so it tends to end up with whoever wired the job.

On a team of six, that is fine. The key stays with the person who built the pipeline, everyone knows who that is, and the risk is that this person leaves. On a larger team, nobody can name the owner. Test it: could you revoke the key this afternoon without first asking around to find out what it does?

On Enterprise, Cursor recommends a service account for CLI runs in CI. The key then belongs to an account instead of a person, the account doesn't take a seat, and an admin can rotate its key, suspend it or cap its spend each billing period. That cap also puts a ceiling on the retry loop described above.