Controls for a coding agent writing code your team merges.
Your team ships code an agent wrote. These controls make it attributable and safe to merge.
Adoption moved faster than the controls.
A rollout or a licence renewal for Copilot, Cursor or Claude Code. An auditor asking who reviews agent-written code. Or a merged pull request nobody can attribute to a person. The policy document is usually written by then. The pipeline behind it usually is not.
A policy with no pipeline behind it is not a control.
An auditor samples evidence, not intent. A written AI policy with nothing in the pipeline behind it is not a control. Every item below is a setting, a stage or a log route that leaves a record.
Eight settings, stages and log routes.
- Every agent session mapped to a named human through SSO.
- Agent activity routed to the log store your auditor samples.
- Context exclusion, scoped to the surfaces that honour it.
- Secret scanning across the editor, the pipeline and repository history.
- Dependency provenance checks for packages that do not exist yet.
- MCP servers limited to an approved list with least-privilege scopes.
- Agents blocked from untrusted pull requests holding production credentials.
- Branch protection so an agent change cannot self-merge.
Each vendor exposes these under a different name. GitHub records an exclusion change as copilot.content_exclusion_changed and keeps enterprise audit events for 180 days. Claude Code reads organisation policy from managed-settings.json, which a developer can extend but not remove.
Exclusion is assumed to be wider than it is. GitHub documents the surfaces it does not reach: Edit and Agent modes of Copilot Chat, symbolic links, and repositories on remote filesystems. A path that must stay unread needs a second control.
Nobody ships a named control for an invented package name.
The USENIX Security 2025 study We Have a Package for You! generated 576,000 code samples across 16 models and found 205,474 unique package names that did not exist. Commercial models invented one in twenty.
Earlier research registered an empty package under an invented name. It drew more than 30,000 downloads in three months, measured against a control package to exclude scanners. No vendor ships a control for this, so it lives in your pipeline as a provenance check on registry age and downloads.
An agent on an untrusted pull request.
A pull_request_target workflow runs with the base repository secrets. Checking out fork code there hands them to a stranger. From 18 June 2026 actions/checkout v7 refuses it unless the workflow sets allow-unsafe-pr-checkout. A workflow pinned to a SHA never picked the change up, so we grep for the opt-out and the stale pins.
A status table and the policy files.
- Control-by-control status table with the evidence for each.
- Policy files committed to your own repository.
- An evidence note an auditor can sample without a call.
- A named gap list where the vendor ships no control.
Priced by the number of assistants and hosts.
| Scope | Typical elapsed time | Handover |
|---|---|---|
| One assistant, one repository host | Two weeks | Policy committed to your repository |
| Multiple assistants across an organisation | Three weeks | Policy committed to your repository |
| Multiple assistants plus agents running in CI | Quoted after the tool inventory | Agreed in writing first |
Where the assistant also drives an agent with tool access, that permission surface is the agent security review.
What the baseline usually catches.
- A secret removed from the file but still in git history.
- Personal accounts on company repositories, outside SSO.
- Assistant prompt logs kept in the vendor, never reaching the auditor.
- A project-level config file adding a tool nobody approved.
What this baseline excludes
- Not a review of the code the agent already wrote.
- Not a licence recommendation. We resell no assistant.
- Not a productivity assessment. This is about blast radius.
- Not an on-premise assistant deployment. No major vendor offers one.
- Not an audit opinion on your SOC 2 or ISO 27001 controls.
Framework and advisory versions above were read from the primary source on 17 September 2026.
Practical answers.
Which assistant is the most secure?
The controls that matter sit outside the assistant. Copilot, Cursor and Claude Code all expose identity, exclusion and logging. What differs is which ones you switched on.
Will our SOC 2 auditor ask about this?
Change management and access control are already in scope, and agent-written code sits inside both. The risk is not a new criterion. It is being unable to show who approved it.
Can we run an assistant on-premise?
Not with the major vendors. The controls live in identity, exclusion and logging. All three are yours to set wherever inference happens.
Do you review the code the agent already wrote?
Not as part of this. That is a separate code review engagement. This baseline changes the next change, which is the cheaper place to intervene.
How do we attribute an agent commit to a person?
Through the identity the session authenticated with, not the commit trailer. A trailer is easy to set and easy to forget. An SSO-backed session record survives an auditor.
Different trigger, different starting point. AI agent security review and AI buyer due diligence pack answer the other two questions, and all AI security services routes on the event. For adversarial testing of the feature itself, AI application security testing.
Scope a control baseline.
Send the assistants in use and the repository host.
Last reviewed: