Because the risk often sits outside the repository. Extensions, skill files, rule sets and connected services can change an agent’s behaviour without any obvious code diff. That means a clean build can still produce unsafe outcomes if the surrounding agent stack has been altered, over-scoped or left unmonitored.
Why the repository can stay unchanged while the supply chain still drifts
Coding agents are not just executing repository contents. They also consume extension logic, instruction files, tool connectors, cached credentials, package sources and policy overlays. If any of those surrounding components change, the agent can behave differently even when the code diff is empty. The real security boundary is the whole agent stack, not only the committed source tree.
That is why a clean commit history does not guarantee a safe build or safe output. A malicious or over-broad extension, a poisoned skill file, a changed rule set, or a compromised connected service can alter what the agent reads, proposes, installs or runs. The repository may look stable while the effective runtime environment has already been reshaped.
For practitioners, the important distinction is between source integrity and execution integrity. Source integrity answers whether the repository changed. Execution integrity asks whether the agent’s behaviour, permissions, prompts, tools or dependencies changed in ways that affect what gets produced. Coding agents widen the gap between those two states.
What actually creates supply chain exposure in an agent workflow
The exposure usually comes from trust expansion. Once an agent can invoke tools, install packages, read local secrets or follow external instructions, it inherits new attack surfaces that are outside the version-controlled code path. An attacker does not need to edit application source if they can influence the agent’s inputs, dependencies or connected services.
That is why extension ecosystems and skill layers deserve the same scrutiny as libraries. A harmless-looking helper can carry excessive permissions, fetch remote content, alter prompts or inject build-time behaviour that is invisible in the repository diff. In practice, the agent stack becomes a supply chain of its own, with its own points of compromise, dependency drift and update risk.
This is especially relevant when the agent can act on behalf of a developer or CI pipeline. If the agent has broad access to repositories, package managers, cloud tokens or deployment tools, then any compromise in the surrounding stack can translate into code insertion, package swapping, secret exposure or destructive commands. AI Coding Agents Security Guide is a useful reference point for the kinds of controls that need to move with the agent, not just with the code.
How to judge whether an unchanged build is still unsafe
The relevant question is not “did the source change?”, but “did the agent’s trust perimeter change?” If the answer is yes, the build or output may no longer be equivalent even when the repository contents are identical. That includes newly installed extensions, revised instruction files, updated connector scopes, changed package sources and altered service credentials.
One practical test is to treat the agent environment as versioned infrastructure. You want to know which extensions are installed, which skills or rules were loaded, which tools were reachable, what permissions were granted and which external services were queried. If you cannot reconstruct that state, you cannot confidently say the agent produced the same security outcome as last week’s unchanged code.
It also helps to separate “compile succeeded” from “supply chain is trustworthy.” A build can be technically successful while still being influenced by a compromised plugin, a poisoned dependency source or an over-scoped token. That is why secure software practices and build provenance controls matter here, not just repository review. NIST SSDF (SP 800-218) and SLSA are both relevant because they force attention onto integrity, provenance and trustworthy build inputs.
Risk and Threat Considerations
Coding agents expand supply chain risk because attackers can target the surrounding tooling rather than the repository itself. A compromised extension, injected instruction file, poisoned dependency source or abused connector can redirect the agent toward unsafe actions without leaving an obvious code diff.
Failure mechanism: The agent trusts external or semi-external components, then executes altered instructions, tool calls or package actions with the developer’s or pipeline’s privileges. That breaks the assumption that unchanged source implies unchanged behaviour.
Impact: The organisation can ship malicious code, expose secrets, install tampered dependencies, or trigger destructive actions while believing the build path is clean. The result is a supply chain compromise that may be missed by reviews focused only on repository changes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Build provenance and artifact integrity are central when unchanged code can still be tainted by altered inputs. |
| Recommendation — Require provenance evidence for every build input and artifact before release. | ||
| NIST SP 800-53 Rev 5 | SA-12 — Supply Chain Protection | The question is about supply-chain compromise through agent tooling and dependencies. |
| CM-5 — Access Restrictions for Change | Agent stacks can change behavior through tools and configuration even when source is unchanged. | |
| IA-5 — Authenticator Management | The risk often involves exposed or over-scoped tokens, keys and other credentials used by agents. | |
| Recommendation — Apply supply-chain protection to extensions, skills, connectors and package sources. Restrict who can modify agent rules, extensions and connected services. Rotate and scope agent credentials tightly and revoke unused secrets promptly. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | Connected services and external tooling are part of the agent supply chain and can alter trust. |
| Recommendation — Review and govern third-party agent services and integrations continuously. | ||
Practitioner Guidance
What to verify: Verify the agent’s full execution context, not just the repo diff. That means extension inventory, skill and rule sources, connector scopes, package provenance and the set of secrets or tokens the agent can touch.
Common mistake: Treating “no source change” as a safe state. In agentic workflows, the more important control question is whether the agent’s authority, inputs and dependencies are still the ones you approved.
What good looks like: The agent environment is reproducible, least-privileged and observable, with explicit approvals for new tools, new connectors and any instruction source that can alter runtime behaviour.
Practitioner takeaway: If the agent can change its own inputs, tools or trust relationships, then repository immutability is only one control, not the control that decides safety.
Related resources from NHI Mgmt Group
- Why do AI coding agents increase supply-chain risk?
- Why do AI coding agents and MCP servers increase supply chain risk on developer endpoints?
- Why do autonomous coding agents increase the risk of secrets exposure and supply chain compromise?
- Why does AI-generated code increase software supply chain risk even when it compiles cleanly?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org