Two supply chains, not one.
The packages you import are audited by everyone. The programs your agent launches are audited by almost no one.
Dependency scanning covers the packages your code imports. It says nothing about the second supply chain that arrived with agentic development: the MCP servers, launched by your agent with your agent's permissions, frequently via an unpinned fetch that resolves fresh on every start. Lucid Train audits both. The dependency half uses installed scanners over your manifests; the agent half parses your MCP configuration for unpinned launches, remote endpoints, plaintext transport and credentials being passed through.
The second supply chain is new and unguarded
Package managers grew lockfiles, signatures and advisory databases over two decades. Agent tooling arrived in about two years, and the common installation instruction is a command that fetches the latest version at every launch. The threat model is familiar and the controls have not caught up, which is the entire reason the agent-config half of this audit exists.
Why the same tab covers both
They are the same question asked about two inventories: what runs here, where did it come from, and could it change under you. Reporting them together means the answer is one report rather than a dependency scan and a gap where nothing looks at the agent configuration at all.
What it is and what it is not
Worth being exact about the boundary, because the category name is crowded. This reads dependency manifests and lockfiles, not your source code. It will tell you that a package you depend on has a known vulnerability. It will not find an injection flaw, a broken authorisation check or a hardcoded credential in a file you wrote, because it never opens those files. For that you want a static analysis tool, and the two are complements rather than substitutes.
Findings you can act on immediately
Both halves produce concrete, checkable actions: pin this package to a version, vendor this server, narrow this credential, upgrade this dependency to the version that carries the fix. The agent is in the same window with the repository open, so acting on one is an edit you review rather than a task you file.
Two inventories, one report
| Dependencies | Agent tooling | |
|---|---|---|
| What it covers | Packages you import | MCP servers your agent launches |
| Source of truth | Manifests and lockfiles | Agent config JSON |
| Needs a scanner installed | Yes | No |
| Needs the network | Depends on the scanner | No |
| Typical finding | Known advisory in a package | Unpinned launch or remote endpoint |
Questions
Related
- MCP Server Security ScanningAn MCP server is a program with your agent's permissions. Most people install one without reading what it launches.
- Dependency Vulnerability AuditReal scanners, run locally, with an agent that can then do the upgrades and show you the diff.
- Offline Dependency AuditFor the repositories that are the reason your team cannot use a hosted scanner.
- Security Audit Inside a Coding AgentScanning where the code is, rather than reporting to somewhere the code is not.
Last updated