When I started monitoring the AI agent ecosystem, the goal was straightforward: continuously watch for emerging threats. Track what MCP servers and skills are being published, what they can do and flag anything that looks suspicious.
What we got was a window into how the AI agent ecosystem is actually evolving. Here is what we've learned, and the review model that came out of it.
What is public agent tooling, exactly?
Two different things get lumped together under "agent tools", and they carry different risks.
A skill is instructions plus files that an agent loads into its context. In the Agent Skills format, a skill is a folder containing a SKILL.md file with metadata and instructions that tell an agent how to perform a task, optionally bundling scripts, reference material and templates. The risk is that the agent reads and follows whatever the folder says, and may execute the scripts it ships with.
An MCP server is a running process that exposes tools to an agent over a transport, either as a local stdio child process or as a remote HTTP endpoint. The agent calls those tools at runtime with arguments the model produces. The risk is the authority behind each tool: the filesystem, the network, the credentials the server holds. Authorization for MCP is optional by specification and defined only for HTTP transports, so an exposed server may have none.
The review model below applies to both. Where a check differs between the two, I say so.
Reviewing a growing ecosystem
When the Linux Foundation announced the Agentic AI Foundation in December 2025, the release counted more than 10,000 published MCP servers, which describes ecosystem size, not the security quality of those servers. New registries are appearing. Existing ones are expanding. The variety of what agents can now do (from database management to email to code deployment to financial transactions) keeps widening.
Assess maintenance, duplicate implementations and clarity of tool descriptions for each dependency. The count of published servers alone does not establish the proportion abandoned, vulnerable or inadequately reviewed.
Established package-security practices remain relevant: verify provenance, pin versions and review the privileges of install scripts and runtime code.
MCP changes after the scan
Point-in-time scans can become stale because an MCP server may change: what you approved is not necessarily what runs next week. One of the most important things we track is change over time. MCP servers aren't static. They update their tool definitions, add new capabilities, modify their behavior. Sometimes these changes are improvements. Sometimes they're not.
The documented case is the rug pull. Invariant Labs showed in April 2025 that a malicious server can change the tool description after the client has already approved it, and that a poisoned description can exfiltrate data reachable through other, trusted servers. Beyond that documented case, I have also seen tool descriptions change in ways that subtly alter agent behavior, tool lists grow beyond the original scope and authentication options loosened between versions in the name of developer convenience. I report those as observations from review work, not as measurements.
This is why point in time security assessments aren't sufficient. A server you scanned and approved last month might be materially different today.
How agent tooling differs from npm
The agent supply chain adds model-facing instructions and dynamic tool selection to familiar package-security risks. The AI agent supply chain looks like this: a developer searches a registry, finds an MCP server that does what they need, adds it to their agent configuration and moves on. It's the same pattern that created the JavaScript dependency crisis, with two key differences.
Agent tools expose capabilities through a model-driven interface. An npm package can already execute code inside an application or build process. MCP adds a different risk shape: tools expose remote or business capabilities and a model may select and invoke them dynamically. A package can execute during installation, import or runtime. A vulnerable MCP tool can be invoked by an agent based on its own reasoning. There is also no universal lockfile or pinning model across MCP clients. An unpinned remote server can change without a client update; local package pinning and host approval policies can limit this.
A few categories of supply chain risk keep showing up. There's typosquatting and namesquatting, where servers are published with names similar to popular ones, hoping to catch developers (or agents) that make a typo. We see scope creep: servers that start with a narrow, useful capability and gradually expand their tool set to include more sensitive operations. And we see dependency chains, where MCP servers depend on other services, creating transitive trust relationships that no one maps or monitors.
The review checklist: what to check and how
These are the signals that, in my review work, most reliably separate tooling I would let an agent depend on from tooling I would not. Each item says what to look at and how.
- Permissions. Read the tool schemas (for a server) or
SKILL.mdand its scripts (for a skill) and list what they can touch: filesystem paths, network destinations, shell, credentials; reject anything broader than the job, such as a file tool that can escape the approved directory or a database tool that can exceed the account’s intended query scope. - Provenance. Identify the publisher and the source repository, confirm the registry entry points at that repository and that the published artifact matches it at the tagged commit, and investigate a name that resembles a popular server under a different publisher before trusting it.
- Install path. Read what the install command actually runs (install scripts, remote fetches, downloaded binaries) and where the result executes: a stdio server inherits your environment variables, a remote server runs someone else's code with your data and a skill's scripts run with the agent's permissions.
- Exposure and authentication. For any server reachable over HTTP, confirm it requires authorization and validates the token audience, because the specification makes authorization optional and a reachable endpoint without application-level access checks may expose tools to unauthenticated callers.
- Pinning. Pin the server or skill to a version or commit hash, record a hash of every tool definition and description you approved and refuse to load a tool whose description differs from the approved hash, which is the direct defense against the rug pull.
- Versioning and changelog. Check that the project publishes version numbers and a changelog; without them every change is silent, and a production dependency that cannot tell you what changed should not be a production dependency.
- Input typing. Check whether each tool's inputs are typed and validated in the schema; untyped free text inputs that flow into paths, queries or commands are far more likely to be exploitable.
- Change over time. Fetch the tool list and descriptions again on a schedule, diff them against what you approved and treat frequent undocumented changes as a signal on their own: acceptable in early development, concerning in production.
- Dependency chain. List the services the server or skill calls out to (APIs, databases, other MCP servers) and give each of them its own trust decision, because its reach depends on the credentials, data and network access passed to it.
These checks become detection rules teams can run before adding new tooling to their agent configurations, and again on every update.
Choosing and managing MCP servers
Treat each MCP server as a vendor with autonomous access to your systems: vet it before adopting, pin and review its versions and monitor it continuously. If you're building with AI agents today, here's what that review work suggests.
Treat MCP server selection like vendor selection. Don't just evaluate functionality. Evaluate maintenance, security posture, update history and scope. This is a dependency with autonomous access to your systems.
Pin and review. If your MCP framework supports version pinning, use it. If it doesn't, monitor for changes. Don't let your agent's capabilities change without your knowledge.
Monitor continuously. The ecosystem changes daily. What was safe last week might not be safe today, so monitoring and repeat reviews help detect changes that affect the original approval.
Contribute to the ecosystem's security posture. Report suspicious servers. Share security findings. The AI agent ecosystem is young enough that community norms are still forming. We can shape them toward security first if enough people push in that direction.
Setting security practices early
The closest precedent is the early days of mobile app stores and package registries. The teams and communities that established security norms early in those ecosystems (npm audit, Google Play Protect, App Store review, PyPI malware detection) shaped how millions of developers work today.
We have the same opportunity with AI agents. The monitoring infrastructure and security patterns we establish now will define how the agent ecosystem operates for years.