Scan the MCP servers your agent is allowed to run.
An MCP server is a program with your agent's permissions. Most people install one without reading what it launches.
Every MCP server listed in your repository's agent configuration runs as a local process with your coding agent's file and network access. Lucid Train's audit reads .mcp.json, .cursor/mcp.json, .vscode/mcp.json and .claude/mcp.json and flags four things: a server launched with an unpinned fetch such as npx -y package, which executes whatever the registry publishes at the moment it starts; a server reached over a remote URL, since everything the agent sends it leaves the machine; the same over plaintext HTTP, which is graded higher; and credential-shaped environment variables being handed to a server, so you can confirm the scope is as narrow as it needs to be.
Why unpinned is the one that matters most
A configuration entry reading npx -y some-mcp-server resolves at launch time, every launch. You approved whatever the registry held the day you tried it; you get whatever it holds today. That is a supply chain with no version in it, running with the file and network access of the agent that spawned it. Pinning a version, or vendoring the server, converts an ongoing trust decision into a one-time one.
Remote servers move your context off the machine
A server declared with an http or https URL is not running locally, so everything the agent sends it, including file contents it decided were relevant, leaves your machine. That may be entirely fine and deliberate. The finding exists so it is a decision rather than a detail you did not notice, and plaintext HTTP is graded higher than HTTPS because the exposure is broader than the vendor.
Secrets handed to servers
Environment keys whose names look like credentials, tokens, passwords, API keys and private keys, are surfaced per server. The check is deliberately name-shaped rather than value-shaped: it never reads the values, so it can flag the arrangement without ever handling the secret. What you do with the finding is scope the credential down to what that server actually needs.
It runs offline against files
No registry lookup, no vendor service and no network call is involved in this part of the audit. It parses JSON that is already in your repository, which is why it works on an air-gapped machine and why it is checkable against a fixture rather than against whatever a remote database says today.
What the agent-config scan reports
| Finding | Severity | What triggers it |
|---|---|---|
| TRUST-MCP-UNPINNED | High | An unpinned fetch such as npx -y pkg |
| TRUST-MCP-REMOTE-PLAINTEXT | High | A server URL on http:// |
| TRUST-MCP-REMOTE | Medium | A server URL on https:// |
| TRUST-MCP-SECRET-ENV | Medium | Credential-shaped env keys passed to a server |
The four files it reads
Questions
Related
- 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.
- Software Supply Chain AuditThe packages you import are audited by everyone. The programs your agent launches are audited by almost no one.
Last updated