AI coding agents and software supply-chain security

AI coding agents can edit code, install packages, run builds and open pull requests. Prompt injection in an issue or README can therefore become a supply-chain attack without an IDE vulnerability.

Treat dependencies as untrusted

Do not add a package merely because its name matches a suggestion. Require approved registries, pinned versions, lockfiles, licensing review and basic provenance. Disable install scripts unless required.

Separate coding from publishing

Agents work on dedicated branches without merge, release or registry permissions. CI uses ephemeral identities, while publishing requires approval and signed provenance.

Test changes, not explanations

Run SAST, tests, secret scanning, dependency scanning and diff review. Generated tests can be weakened with the code, so critical security tests need a separate owner.

Repository content is untrusted

Comments, fixtures and documentation may contain instructions. They must not change agent privileges. Store execution policy outside the repository or sign and approve it independently.

OWASP notes that coding agents can run shells, install dependencies and push code. Combine controls with software supply-chain security and Claude Code hardening.

Coding-agent privilege boundaries

Separate repository reading, file modification, test execution, dependency downloads, git writes and artefact publishing. An agent preparing a patch does not need permission to push to a protected branch or access a production key. Give each stage a separate short-lived identity with minimum scope.

The repository is untrusted input. Instructions in a README, comment, issue, test or filename may try to change the agent goal. Keep execution rules in trusted configuration outside the editable context and enforce them in the executor. The model cannot approve its own policy exception.

Dependencies and artefacts

Install in an isolated environment without default secret access. Prefer lockfiles, an internal package proxy and pinned versions, and show dependency changes as a separate diff. A new install script, registry or binary artefact should trigger additional review.

Build accepted code in clean CI, not inside the agent workspace. The pipeline emits provenance, inventories dependencies and binds output to a commit. A signature or attestation proves aspects of origin; it does not replace security testing of the content.

Change acceptance gate

Review the actual diff and results from build, tests, SAST, secret scanning and dependency checks. The agent summary is a lead, not evidence. Workflow, permission, release-script, policy and network changes require a code owner and independent approval.

Test injection in every file type, environment reads, a confusing package name, disabled tests and self-modification of rules. A successful control produces a safe refusal and a clear audit event.

High-risk change review

Automatically label changes to CI/CD files, dependency manifests, cloud permissions, database migrations, cryptography and authentication code. They require a reviewer with relevant ownership even when tests pass. The agent must not select its own approver or remove the risk label.

Review removed as well as added code. Disabling validation or a test can matter more than a new feature. Compare generated lockfiles and artefacts because a small manifest change may pull a large dependency tree.

Reversibility and deployment

Agent patches use a separate branch and the same gates as human code. Canary release, monitoring and rollback remain pipeline responsibilities. An agent cannot respond to a production alert by expanding its own privileges.

After deployment, link errors to commit, model version and agent session. This separates code defects from tool failures or repository misinterpretation and turns the case into a regression test.

Programme metrics include policy-rejected changes, manual exceptions, review time for high-risk files and rollbacks. Accepted patch count alone does not prove quality. Track defects and incidents associated with agent-generated or agent-modified code as well.

---

Trust the change, not the author

Agent-generated code passes the same gates as human code: review, tests, dependency, secret and policy analysis. The agent must not approve its own PR or change branch protection. Pin dependencies and CI actions to immutable identifiers, and review lockfile changes as part of the diff.

Build in an ephemeral environment with minimum credentials and no production secrets. Retain provenance for source, dependencies, builder and artefact; a signature or attestation matters only when deployment policy verifies it. Test prompt injection in issues, README files and dependency code, plus attempts to alter the pipeline.

Sources: OWASP Secure Coding with AI, SLSA Specification.