Yes, in principle. An MCP server or an AI agent is ordinary software with a package manifest, so SCA can inventory and scan its dependencies like any other project. What SCA does not do is judge what the server's tools do at runtime or what an agent is allowed to call. That needs a separate control layer.
What SCA can see
An MCP server written in Python or JavaScript pulls in libraries, and those libraries pull in more. SCA reads the manifest and lockfile and matches the versions against advisories. This is no different from scanning a web service, so existing SCA practice carries over.
Practical steps:
- Treat each MCP server you run or install as a project with its own repository or directory.
- Commit the lockfile, so the scan sees exact versions.
- Scan on every change, and rescan on a schedule, since new advisories arrive after you install.
- Record which servers are approved, who owns them, and which version is deployed.
What SCA cannot see
| Question | SCA answers? | What does |
|---|---|---|
| Is a library in this server vulnerable? | Yes | SCA |
| Does a tool description contain hidden instructions? | No | Review and guardrails |
| Which agent may call which tool? | No | Identity and access controls |
| Is this server the one we approved, not a lookalike? | Partly, via inventory | Registry and allow list controls |
| What data left through a tool call? | No | Runtime guardrails and logging |
SCA tells you about the code you imported. It does not tell you whether a server's behavior is acceptable.
Where other controls fit
Safeguard's MCP Guardrail and agent identity capabilities address the runtime side, and its asset discovery can help you learn which servers and agents exist in the first place. These sit beside SCA, they do not replace it. If you evaluate any platform, ask which layer each feature belongs to, so you do not assume a dependency scan covers tool behavior.
A short checklist
- Inventory: list every MCP server and agent in use, including ones developers installed locally.
- Scan: run SCA on each, including the dev dependencies of local tooling.
- Pin: use exact versions for servers you install from a registry.
- Review: read tool descriptions and requested permissions before approving.
- Monitor: rescan, and log which agent used which tool.
A worked example: four servers on one team
A team uses four MCP servers. One is an internal server the team wrote in Python. Two are open source servers installed from a public registry. The fourth is a hosted server from a third party with no source available.
For the internal server, SCA applies fully: commit the lockfile, scan on every pull request, rescan on a schedule. For the open source servers, vendor the installation into a repository or record the exact version, and scan its manifests. For the hosted server, there is nothing to scan on your side. You rely on the provider's assurances, a review of what the tools do, and access controls limiting which agents can reach it.
The mix shows why one control is not enough. SCA fits three of four, and for all four you need a decision about who may use it and what it may do.
Step by step: bring MCP servers into your SCA program
- Discover. Ask each team to list every MCP server in use, including local ones. Asset discovery can help find what you did not know about.
- Classify each by source: internal code, open source you install, or hosted by a third party.
- For internal and installed servers, add the repository or directory to your SCA tool with its lockfile.
- Pin versions, and record the version you approved.
- Review tool descriptions and requested permissions before approval, and record the reviewer.
- Decide which agents may call which tools, and apply identity based controls for those agents.
- Turn on logging of tool calls so there is a trail.
- Rescan on a schedule and when an advisory lands for a package in any server.
Special risks to keep in mind
MCP servers run with the access of whoever runs them. A server installed on a laptop can touch whatever that user can touch. A malicious or compromised package in a server's tree can read files and credentials. These are reasons to scan dependencies, and to constrain what the server can reach.
Tool descriptions and tool outputs can carry instructions meant for the model. That is a behavior question, and no dependency scan will see it.
Related controls at a glance
| Control | Purpose |
|---|---|
| SCA and SBOM | Know and check the libraries in each server |
| MCP Guardrail | Constrain tool calls at runtime |
| Agent identity | Know which agent did what |
| Asset discovery | Find servers and agents you did not register |
| Policies and gates | Block unapproved servers or versions from deployment |
Keep the list current
An inventory of servers goes stale quickly, since developers add them as needed. Schedule a monthly review, and make adding a server to the approved list an easy process, so people use it rather than avoid it.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch the steps for connecting a server, and mark which ones involve code you would want to scan and which involve permissions you would want to review.
Quick check
Is a dependency scan enough for an MCP server?
No. It covers imported libraries. You also need review of what the tools do and controls over which agents can use them.
Do locally installed MCP servers count?
Yes. A server on one developer laptop still runs code with that person's access, so include it in your inventory and scans.
How do I scan an MCP server I only run through a package runner?
Find the package's published manifest and exact version, add it to your inventory, and scan it. Prefer pinning the version rather than running whatever is newest.
Last reviewed: 19 October 2026.
