Treat a dependency added by an AI agent like any other change: scan it at the pull request, apply the same policy gates, require human review, and record who approved it. The risk is not that the agent is careless. It is that it adds packages faster than a person would check them.
Why agent changes need the same gate
An agent often suggests a package from memory, which can be outdated, abandoned, or a near match to a real name. Typosquatting is a known attack pattern. Sigstore's overview lists typosquatting packages with similar names among the risks of unsigned software. An agent has no instinct that a name looks off, and a busy reviewer may not either.
The fix is not to ban agents. It is to make sure their changes pass through the same checks, with the evidence recorded.
A checklist for agent made dependency changes
- Detect the change. The pull request check flags any new or changed entry in a manifest or lockfile.
- Verify the package exists and is the intended one. Check name, publisher, and age.
- Check known risk. Scan for known vulnerabilities and look for the package in exploited catalogs.
- Check policy. Is the license allowed, and is the source approved?
- Check need. Could an existing dependency do the job? Fewer dependencies mean fewer risks.
- Require a human approver. The approver is accountable, not the agent.
- Record it. Keep who requested, which agent, and who approved.
What to set in policy
| Rule | Why |
|---|---|
| New dependencies need review | Agents add packages quickly |
| Allow only approved registries | Blocks lookalike sources |
| Pin exact versions in lockfiles | Reproducible installs |
| Block packages below an age threshold you choose | Slows fresh malicious uploads |
| Limit what agent credentials can do | Agents should not publish or merge |
Identity and permissions
Give agents their own identity, separate from a human developer's account, so logs show what the agent did. Scope its token to the repository it works in, with no right to merge to protected branches. If a tool connects through MCP, review which servers it can call and what each can access.
Keep the loop short
An agent that gets fast, specific feedback fixes its own mistakes. A pull request comment that names the rule and the safe alternative lets it retry before a human spends time.
A worked example
Take a hypothetical developer who asks a coding agent to add CSV export to a service. The agent opens a pull request that adds a library to the manifest and updates the lockfile.
The pull request check fires. It notes a new direct dependency and three new transitive ones. It looks up the package: published eight months ago, one maintainer, modest download history. The name is close to a more established library. The check posts a comment flagging the similarity and asking the author to confirm the intended package.
The reviewer looks, realizes the agent chose the lookalike, and asks the agent to use the established library. The agent updates the pull request. The check runs again: the package is old enough, from an approved source, with no known issues, and the license is allowed. The reviewer approves. The record shows who requested the change, which agent made it, and who approved it.
No ban was needed. The gate caught the issue in minutes, and the audit trail shows the decision.
Policy rules for agent changes
| Rule | Suggested stage |
|---|---|
| New dependency flagged for review | Advise, then soft gate |
| Lookalike name check | Soft gate |
| Package age below your chosen threshold | Soft gate |
| Unapproved registry source | Hard gate |
| Known exploited vulnerability | Hard gate |
| Forbidden license | Hard gate |
Choose thresholds that match your risk, and review overrides monthly.
Agent identity and logging
Give each agent its own account or service identity. Log the repository, the branch, the files changed, and the prompt or task reference where your tooling allows. That makes an incident review possible. If an agent's token leaks, you can revoke exactly that identity without disrupting humans.
Tool access through MCP
Agents often reach tools through MCP servers. Inventory the servers each agent can call and what each can read or change. Apply a guardrail that limits calls to approved servers and flags unusual requests. Treat a new server like a new dependency: review it before enabling it.
Teaching the agent
Add a short instructions file to each repository that lists preferred libraries, banned ones, and the process for adding a dependency. Agents that read these files make fewer mistakes. Pair this with the pull request check, because instructions reduce errors but do not enforce anything.
Review habits
Reviewers should look at manifest changes first, before the code that uses them. Make that a norm. A small diff in a lockfile can hide the biggest risk in the pull request.
Try it yourself
Click through it at your own pace, or open it full screen. Look at where a guardrail sits between the agent and the tools it can call.
Safeguard provides agent identity, MCP Guardrail, and policies and gates, together with dependency scanning and reachability analysis, so agent changes follow the same path as human ones. A free scan at gold.safeguard.sh/scan shows your current dependencies.
Quick check
Should agents be allowed to add dependencies?
Yes, if the change passes the same pull request checks and a person approves it.
Is a lockfile enough protection?
It makes installs repeatable but does not tell you the package is safe. You still need scanning and review.
Do we need a separate policy for agents?
Usually the same rules apply, plus agent identity, scoped credentials, and a record of who approved each change.
Sources
Last reviewed: 19 October 2026.
