How to Connect AI Coding Agents to CI Safely

AI coding agents with CI is a governance question before it is a tooling one. Four controls decide whether security can sign off: who has access, what the policy allows, how data moves, and whether anyone is measuring adoption. The table assigns each an owner.

The owners column matters more than the controls themselves, which I realise is a slightly odd thing to say about a governance table. But a control with nobody's name against it is a control nobody checks, and it fails at exactly the moment someone has to answer for it. The usual mistake is assuming security owns all four. They don't. Identity is IT's system of record, policy is an engineering-leadership call about what the team is allowed to ship, and adoption belongs to whoever owns developer experience. Security owns the data-flow question and the audit path, and they will ask about both.

Data flow is the one that stalls approvals, so answer it before the meeting rather than during it. Write down what the tool can read, what it can change, what leaves your network and where any of it is retained. Most of that comes straight from the vendor's documentation and your own configuration. It's dull work, but it turns a vague objection into a specific one, and specific objections are the kind you can actually close.

A rollout works when it starts narrow and earns its expansion. One team, one repo and a few real tasks in week one, with policy and training in place before anyone scales it wider.

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.

Four weeks is a shape, not a rule. The dates matter much less than the order, and the reason to start with a single team is that those first two weeks are mostly you finding out what your standard should even say. You can't write that from a pilot too broad to watch properly. Pick the team that will tell you when something doesn't work, rather than the team most likely to hand you a good result.

Expansion is where this usually goes wrong. Not because anyone's careless, either — the pilot went well, someone senior noticed, and now there's pressure. That's a hard thing to say no to. Before you add teams, though, check that you can answer three things with numbers instead of impressions: did review load go up or down, what does a developer actually cost per month, did quality hold. If any of those is a shrug, another fortnight of the same pilot beats a rollout you have to walk back.

Never put credentials in the agent's context. 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, but it is not the terminal: it sees terminal output, while the shell's environment variables are never exposed to it.

One security engineer who is both GitHub admin and AWS admin runs exactly this pattern. He types something like creds prod, the script exports the env vars, and from there the agent can run elevated AWS commands it never had the secrets for.

This generalizes to any privileged system an agent must drive in CI: keep the secret in the shell, gate the elevated step behind explicit approval, and let the agent operate the tool through output it can read but not exfiltrate.

The per-command approval prompt goes away. agent -p "..." runs headlessly, one prompt in and one result out, and that is the shape you drop into a CI job, a git hook or a shell script where nothing is sitting at a keyboard to approve steps. Cursor's guidance is to pair it with tight permissions and a review gate.

The permissions policy is now doing the job a person was doing by hand.

The order is the part I would argue about. Write the allow and deny policy before the first pipeline run, not after, because a policy written afterwards is really a description of what the agent already did. In an interactive session that discovery is cheap. You watch a command come up, you decline it, you move on. In CI you read it in a log, some time later, after it has finished.

Cursor documents permissions and the GitHub Actions setup as separate reference pages, and the workflow file is where install, path and secret handling land. Read both before you write it rather than after the first red run.

Read access first, a narrow rerun second, and nothing that writes to the branch until the rest has become boring. A rerun right is also a retry-loop right. An agent that can rerun a job can rerun it many times while looking, from the outside, like something making progress.

Where exactly to draw that rerun boundary I would not claim to know in general. It depends what one job in your pipeline is allowed to touch.

The useful part is that the spend lands where everyone else's does. CLI and headless jobs authenticate with CURSOR_API_KEY set in the environment, and that usage appears in team analytics and billing like a human member's. So the loop comes with a smoke alarm attached, as long as somebody looks at the dashboard in the first week rather than at the end of the month.

Somebody named, in the same place as your other service accounts. The control table above hands identity to IT and the data-flow question to security, and an agent's CI key falls slightly between the two, which is how it ends up belonging to whoever happened to wire the job.

On a team of six that is fine, and I am not going to pretend otherwise. The key lives with the person who built the pipeline, everybody knows who that is, and the failure mode is that they leave. Past a certain size, though, nobody can name the owner at all, and the honest test is whether you could revoke that key this afternoon without first asking around to find out what it does.