AI coding agents can now do much more than generate a few lines of code. They can inspect repositories, install dependencies, run commands, modify files, execute tests, and sometimes interact with external services.
That makes an AI coding agent part of the software development environment.
It also means that the security questions we already ask about CI/CD systems should be applied to AI coding agents.
A CI runner can access source code, dependencies, build tools, credentials, and deployment systems. An AI coding agent can potentially access many of the same resources.
The difference is that an AI agent can also make decisions about which tools to use and which commands to execute.
That combination makes supply-chain security particularly important.
What Is Software Supply-Chain Security?
Software supply-chain security focuses on the components, tools, dependencies, processes, and infrastructure used to build software.
A typical application supply chain may look like:
Developer
|
v
Source Code
|
v
Dependencies
|
v
Build System
|
v
Tests
|
v
Artifact
|
v
Deployment
Each stage introduces potential risks.
For example:
A dependency can contain a vulnerability.
A package can be compromised.
A build tool can be tampered with.
A CI credential can be exposed.
A malicious script can execute during a build.
AI coding agents interact with many of these same components.
Why AI Coding Agents Change the Risk Model
A traditional developer might manually run:
dotnet add package SomePackage
An AI coding agent may be capable of deciding that a package is required and executing the command itself.
The workflow can become:
Developer Request
|
v
AI Agent
|
+--> Search Code
|
+--> Choose Dependency
|
+--> Install Package
|
+--> Modify Code
|
+--> Run Tests
The agent is now participating in the software supply chain.
This does not mean AI coding agents are inherently unsafe. It means their permissions and actions need to be governed like other development infrastructure.
CI Systems Already Have Similar Risks
A CI runner often has access to:
Source Code
Build Tools
Package Registries
Secrets
Artifacts
Deployment Systems
For example:
Git Repository
|
v
CI Runner
|
+--> Restore Dependencies
+--> Build
+--> Test
+--> Publish Artifact
+--> Deploy
If the CI environment is compromised, an attacker may be able to affect the software build or obtain sensitive credentials.
An AI coding agent can have a similar access footprint.
The difference is that an agent may dynamically decide which development tools or commands to invoke.
The Agent Should Be Treated as a Privileged Tool
Consider this environment:
AI Agent
|
+--> Repository
+--> Terminal
+--> Package Manager
+--> Git
+--> Test Runner
+--> Network
+--> Credentials
Giving one component access to all of these resources creates a broad trust boundary.
A better approach is to ask:
What does the agent actually need for this task?
For a simple C# code change, it may need:
Read source Yes
Modify source Yes
Run tests Yes
Install packages Maybe
Production access No
Deployment No
Cloud credentials No
This is the principle of least privilege applied to AI development.
Dependency Installation Is an Important Boundary
One of the most obvious supply-chain risks is package installation.
A developer might ask:
Add JSON serialization support.
An agent could potentially search for a package and modify the project file.
For a .NET application, that may result in a change such as:
<ItemGroup>
<PackageReference Include="Example.Json" Version="1.0.0" />
</ItemGroup>
Before accepting such a change, developers should verify:
The agent should not become an automatic approval mechanism for third-party dependencies.
Package Confusion Is Still a Risk
Suppose a project uses:
Internal.Logging
An attacker might publish a similarly named package to a public registry.
If an automated tool selects the wrong package, the result could introduce malicious or unexpected code into the project.
The problem is not unique to AI.
However, an agent that can search for and install dependencies can increase the importance of having explicit package policies.
Use approved package sources where appropriate.
For example, an organization may define:
Approved Sources
|
+--> Internal Registry
+--> Approved Public Registry
and prevent development tools from freely selecting arbitrary sources.
AI Agents Can Execute Build Scripts
Consider a repository containing:
build.ps1
setup.ps1
scripts/
An agent may need to execute one of these scripts.
But scripts can perform actions beyond compiling source code.
They may:
Create files
Install packages
Modify configuration
Access the network
Read environment variables
Execute other programs
Therefore:
Agent
|
v
Build Script
|
+--> File System
+--> Network
+--> Environment
+--> External Tools
Running a script is not a trivial operation.
The same principle used for CI runners should apply: understand what the command can do before granting unrestricted execution.
Secrets Make the Problem More Serious
CI systems commonly use secrets for:
Package registries
Cloud providers
Deployment systems
Signing services
Databases
AI agents should not automatically receive those credentials.
For example, this is unnecessarily broad:
AI Agent
|
+--> Source Code
+--> Build
+--> Production Credentials
+--> Deployment
A safer architecture separates development permissions:
AI Agent
|
+--> Source Code
+--> Build
+--> Tests
while keeping deployment credentials behind separate controls.
Don't Give the Agent Production Access
A coding agent should generally not need direct access to production infrastructure simply to modify application code.
For example, avoid a workflow like:
AI Agent
|
+--> Repository
+--> Production Database
+--> Production Cloud Account
Instead:
AI Agent
|
v
Development Environment
|
v
Review / CI
|
v
Controlled Deployment
This preserves a separation between code generation and production operations.
Dependency Changes Should Be Reviewable
A useful workflow is:
Agent
|
v
Dependency Proposal
|
v
Review
|
v
Package Installation
|
v
Build + Tests
The exact workflow can vary by team.
The important point is that dependency changes should remain visible and auditable.
For example, a pull request should clearly show changes to:
.csproj
packages.lock.json
Directory.Packages.props
or the equivalent dependency-management files used by the project.
Lock Files Matter
Dependency lock files can help make dependency resolution more predictable.
For example, a project may use a lock file to record resolved package versions and related dependency information.
This helps reduce unexpected changes between builds.
However, lock files are not a complete security solution.
Teams should still review:
Direct dependencies
Transitive dependencies
Package sources
Vulnerability findings
Version changes
AI-Generated Code Needs the Same Security Checks
Supply-chain security is not limited to dependencies.
AI-generated code can introduce insecure patterns.
For example:
public string BuildQuery(string username)
{
return "SELECT * FROM Users WHERE Name = '" + username + "'";
}
The code may compile successfully.
It may also introduce SQL injection risk.
Security tooling should therefore continue to run after AI-generated changes.
A typical pipeline might include:
AI Change
|
v
Build
|
v
Unit Tests
|
v
SAST
|
v
Dependency Scan
|
v
Review
The AI agent should not be treated as a replacement for these controls.
Code Signing and Artifact Integrity Still Matter
If an AI agent can build or package software, the resulting artifacts should pass through the same integrity controls as manually developed code.
For example:
Source
|
v
Build
|
v
Artifact
|
v
Integrity Verification
|
v
Release
The fact that the source was modified by an AI agent does not change the need for artifact verification.
CI Should Remain an Independent Control
One useful design principle is to avoid allowing the AI agent to approve its own work.
For example:
AI Agent
|
v
Code Change
|
v
Pull Request
|
v
CI
|
+--> Build
+--> Tests
+--> Security Scan
+--> Dependency Scan
The CI system provides an independent verification layer.
This is similar to separating code generation from code validation.
Repository Permissions Should Be Reused
If a developer cannot access a private repository, the AI agent operating on that developer's behalf should not become a mechanism for bypassing the restriction.
Access should remain tied to appropriate identity and authorization controls.
A simplified model is:
User
|
v
Authorization
|
v
AI Agent
|
v
Allowed Repository
The agent should not have broader repository access merely because it is an automated tool.
Review Agent-Installed Tools
AI coding environments may support extensions, plugins, command-line tools, or additional agents.
Each component can expand the attack surface.
For example:
AI Agent
|
+--> Extension A
+--> Plugin B
+--> CLI C
+--> External API
Before installing an extension or tool, review:
Publisher
Source
Permissions
Update mechanism
Network access
File-system access
Credential access
Maintenance status
Treat development extensions as software dependencies.
Compare AI Agents With CI Runners
Area | CI Runner | AI Coding Agent |
|---|
Source access | Usually required | Usually required |
Build tools | Common | Common |
Package installation | Common | Possible |
Shell execution | Common | Often possible |
Secrets | Sometimes required | Should be minimized |
Network access | Common | Should be controlled |
Automated decisions | Limited by pipeline | Potentially broader |
Code modification | Usually limited | Often central to the task |
Security scanning | Common | Should still use CI/security tools |
The important similarity is access.
The important difference is that an AI agent can make dynamic decisions while operating those tools.
Common Mistakes
Trusting the Agent's Package Choice
An AI-generated dependency should be reviewed like any other dependency.
Giving Production Credentials to the Agent
Development tasks rarely require direct production access.
Allowing Unrestricted Network Access
Network access can expand the agent's ability to interact with external services.
Running Arbitrary Scripts
Shell and script execution should be treated as privileged capabilities.
Skipping CI Checks
AI-generated code still needs automated validation.
Ignoring Transitive Dependencies
A safe direct dependency can still bring additional packages into the project.
Treating AI Tools as Ordinary Editor Extensions
An agent with shell, file-system, and network access has a much larger security footprint.
Allowing Automatic Dependency Installation
Package changes should remain reviewable and subject to organizational policies.
Best Practices for Secure AI Coding Agents
Apply Least Privilege
Start with the smallest permission set:
Read Repository
Write Workspace
Run Tests
Add additional capabilities only when required.
Restrict Package Sources
Use approved registries and package sources where possible.
Separate Development and Production
Do not expose production credentials or deployment capabilities to an agent unnecessarily.
Keep CI Independent
Build, testing, dependency scanning, and security analysis should continue to run independently.
Review Dependency Changes
Treat AI-generated package additions like changes from any other developer.
Sandbox Command Execution
Where appropriate, run agent commands in an isolated environment.
Control Network Access
Allow only the external services required for legitimate development.
Audit Agent Activity
Where supported, retain useful logs for commands, file changes, and important actions.
Protect the Git Workflow
Use pull requests, branch protections, required checks, and appropriate review policies.
Advantages of Applying Supply-Chain Controls to AI Agents
Reduces unnecessary permissions
Makes dependency changes easier to review
Limits exposure of credentials
Preserves existing CI security controls
Makes agent activity more auditable
Reduces the impact of a compromised tool or dependency
Provides a consistent security model across development automation
Disadvantages and Trade-Offs
Strong controls can introduce friction.
For example:
Package installation may require approval.
Network restrictions can affect development workflows.
Sandboxed environments require additional configuration.
Strict permissions can prevent an agent from completing some tasks automatically.
Additional logging and review increase operational effort.
These trade-offs should be balanced against the sensitivity of the repository and the permissions available to the agent.
A Practical Security Checklist
Before allowing an AI coding agent to operate in a development repository, verify:
[ ] Repository access is limited
[ ] File-system access is restricted
[ ] Shell execution is controlled
[ ] Network access is reviewed
[ ] Production credentials are unavailable
[ ] Package sources are approved
[ ] Dependency changes are reviewable
[ ] Lock files are used where appropriate
[ ] CI remains an independent validation layer
[ ] SAST/security scanning remains enabled
[ ] Dependency scanning remains enabled
[ ] Extensions are reviewed
[ ] Agent activity is auditable
[ ] Pull-request protections remain active
Troubleshooting an Unexpected Dependency or Tool Change
If an AI coding agent introduces an unexpected package or tool:
Check the project files for newly added dependencies.
Review the dependency's source and version.
Inspect the complete dependency tree.
Check the package registry being used.
Review lock-file changes.
Run the normal vulnerability scanner.
Check whether the agent executed an installation script.
Review shell or terminal activity.
Remove unnecessary dependencies.
Run the complete CI validation process before merging.
If a credential or sensitive system was potentially exposed, follow the organization's security incident process rather than treating the change as an ordinary code review.
Summary of the Article
AI coding agents should be treated as part of the software supply chain because they can interact with source code, dependencies, build tools, scripts, package registries, and other development infrastructure.
The security principles already used for CI systems are therefore highly relevant. Least privilege, controlled network access, dependency verification, secret isolation, sandboxing, auditability, and independent CI validation should remain part of an AI-assisted development workflow.
An AI agent should not automatically receive production credentials or unrestricted access simply because it needs to modify source code. Dependency installation and tool execution should also remain subject to the same review and security controls applied to other software-development automation.
The key idea is simple: an AI coding agent may be helping write the software, but it is also operating inside the software supply chain. Secure it accordingly.
Join the conversation! Your thoughts help the community grow.