Capability
Coding agent security
A coding agent holds repository access, CI credentials and often the ability to open and merge changes. The security question is not whether the code it writes is good — review already handles that. It is that the agent is a non-human identity with commit rights inside your software supply chain, and it reads untrusted text all day.
Why this is a supply-chain problem
A coding agent sits at a junction most controls were not designed for: it has write access to the artefact that becomes production, and its instructions come from text nobody validated.
The inputs are untrusted by construction
Issue descriptions, pull-request comments, code review threads, dependency README files, error output. Any of these can contain instructions, and a coding agent's job is to read them and act. That is not a misconfiguration — it is the design.
The credentials are strong
Repository write, CI triggers, package registry tokens, sometimes deployment keys. These were scoped for a human who uses them a handful of times a day.
The output path is trusted
Once a change is merged, everything downstream treats it as reviewed. If review is itself under time pressure — and agent-generated volume puts it there — the trusted path is doing less work than it appears to.
The controls that matter, in order
| Control | Why it is high value |
|---|---|
| Its own identity, never a human's | An agent committing as a person destroys attribution, and attribution is the only way to answer "what did it touch" after an incident |
| Branch-only, never direct to main | Keeps every change on a reviewable path. Cheap, and the single highest-value rule |
| No secret read access | A coding agent rarely needs to read production secrets, and frequently is granted them because they sit in the same environment |
| Dependency additions flagged | Adding a package is the most consequential thing a coding agent can do in one line, and it looks like a routine diff |
| CI scoped separately | Triggering a build is not the same permission as publishing an artefact, and they are often the same token |
| Rate ceiling on merges | Catches the runaway case that individual-change review will not, because each change looks fine |
Branch-only plus its own identity gets most of the value for almost no friction. Start there.
What this is not
This does not compete with the coding assistant. The model writing the code and the controls around what its identity may do are different layers, and a good deployment has both. Nothing here argues for using a coding agent less.
This is not code review. Static analysis, tests and human review already address whether a change is correct. They do not address whether the agent should have been able to make that change at all, which is a permissions question.
This is not a substitute for supply-chain scanning. Flagging that a dependency was added is not the same as knowing the dependency is safe. The controls here narrow who can add one; existing tooling still has to assess it.
And it does not fix review capacity
The uncomfortable second-order effect of a productive coding agent is that it generates changes faster than people can read them. No permission control addresses that. If review is the thing standing between agent output and production, and review throughput has not changed, then the trusted path is carrying more than it was designed for — and every control described above assumes that path still works. Worth measuring review latency before and after deployment, because it is the number that quietly moves.
Where Agent Trust Cloud fits
| Need | What the platform does |
|---|---|
| Give the agent its own identity | Machine Identity, so commits and API calls are attributable to the agent rather than to whoever created it |
| See what it actually reaches | Discover surfaces the repositories, registries and CI systems the identity touches — usually more than expected |
| Constrain the consequential actions | Access Governance and Policy Engine hold what it may do; merges and publishes are the ones worth a condition |
| Reconstruct an incident | Forensics and the Audit Ledger answer what the identity did and when |
| Judge whether the code is good | No, and it should not try. Review, tests and static analysis own that |
| Vet a new dependency | No. The platform can make adding one visible and constrained; assessing it is your existing supply-chain tooling |
Common questions about coding agent security
Is coding agent security about the quality of generated code?
No. Whether a change is correct is handled by review, tests and static analysis, and those are mature. Coding agent security asks a different question: should this identity have been able to make that change at all? That is a permissions question, and it is the one with no existing owner in most engineering organisations.
Should a coding agent commit under its own identity?
Yes, always, and it is the highest-value single control here. An agent committing as a human destroys attribution, which is the only way to answer "what did it touch" after something goes wrong. It also means revoking the agent's access means revoking a person's, which nobody wants to do at speed.
Why is adding a dependency singled out as high risk?
Because it is the largest consequence available in the smallest diff. One line pulls in code you did not write, from a source you did not choose, that runs with your build's privileges. In a review queue under time pressure it looks like routine housekeeping, which is exactly why it deserves to be flagged rather than left to catch the reviewer's eye.
Do coding agents need production secrets?
Rarely, and they are frequently granted them anyway because the secrets happen to live in the environment the agent runs in. Read access to production credentials is worth auditing for specifically, because it is usually an inheritance rather than a decision.
What is the smallest useful set of controls?
Its own identity, and branch-only with no direct push to main. Those two cost almost nothing, need no new tooling, and make everything after them possible — including being able to reconstruct what the agent did. A rate ceiling on merges is a close third, because it catches the runaway case that per-change review will not.