AI Coding Agents
A coding agent installs packages without anyone checking the name or the version. Dependency Firewall checks each install against the rules your security team sets, on every machine the agent runs on.
An agent chooses the package and the version
A coding agent with shell access runs npm install, pip install or cargo add as part of a task. The model wrote the name and the version, and the install ran before a person read the diff.
- The version an agent installs varies
- An agent does not always take the latest version. It can pin one it has seen before, pick the newest release, or follow a release age setting on that machine.
- Names that were never published
- Some of the names a model writes do not exist. Anyone can register such a name afterwards.
- A package manager setting covers one machine
- A minimum release age in a config file applies on that machine or in that repository. A developer can override it to get a newer version, and so can an agent told to make a failing install pass.
The rules an agent installs under
Every install ends in a request for a package. When that request goes through the firewall, the same rules apply on any machine, whether a person or an agent ran the command.
Set the rules where an agent cannot change them
Centralize firewall rulesGive the agent the newest version that has aged
Release delayRefuse a version with a critical vulnerability
Vulnerability blockingBlock a malicious package under any name
Malware blocking
- A token per agent
- Give agents their own access token, so the log shows which installs came from an agent.
- Configuration in the repository
- Commit the client configuration. Every clone and every agent workspace then installs through the firewall.
- Names that do not exist
- A name that was never published fails as not found. A name that someone registered yesterday is inside the delay window.
Only the registry URL changes for each package manager. Nothing is installed on developer machines.Supported ecosystems
Agents work with the bsfw CLI
An agent runs the Dependency Firewall CLI itself. It lists the blocked installs, follows the log live while an install runs and reads each entry as JSON. Before an install it can look up the vulnerability and malware findings for an exact version.
A blocked install comes with its reason
A blocked version fails the install with the same error a developer would get. The log records the package, the version, the rule and the token that asked.
Who works with it
- Security teams
- Set the delay, the vulnerability threshold and malware blocking once, on the baseline. They apply wherever an agent runs.
- Developers
- Commit the client configuration to the repository. Every clone and every agent workspace then installs through the firewall.
- Platform engineers
- Keep the token in an environment variable, and give agents a token of their own.
Questions
Do agents need a setup of their own?
No. Agents use the same package managers as developers, so they read the same client configuration. Commit it to the repository.
Can an agent switch the rules off?
No. The rules are set in the firewall, and an inherited rule cannot be removed on the firewall that inherits it.
Can an agent find out why an install failed?
Yes. With the bsfw CLI it reads the log entry for the blocked request, which names the rule. It can then pick a version that passes.
How do we tell an agent's installs from a developer's?
Give agents their own access token. The log records the token with every install.
More Dependency Firewall use cases
All use cases- Malicious PackagesBlock malicious packages and account-takeover payloads before anyone installs them.
- Vulnerable DependenciesStop packages with known CVEs at the firewall before they land in a build.
- CI/CD Pipeline ProtectionRoute CI/CD pipelines through Dependency Firewall and enforce the same rules on every build.
Try it on one registry
Point one package manager at Dependency Firewall and check the log after the next install. The trial runs 14 days.