What public agent tooling reveals about ecosystem trust

When I started monitoring the AI agent ecosystem, the goal was straightforward: continuously watch for emerging threats. Track what MCP servers are being published, what tools they expose, and flag anything that looks suspicious.

What we got was a window into how the AI agent ecosystem is actually evolving. It's moving faster and more chaotically than most people realize.

Here's what we've learned from monitoring 58,000+ skills across the major registries.

Is agent tooling growing faster than its quality?

Yes: the number of MCP servers and agent tools being published is growing quickly, and curation is not keeping pace. 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.

But growth without curation creates noise. A significant portion of published tools are duplicative: multiple implementations of the same capability with wildly different quality levels. Many are abandoned, published once and never updated, drifting into insecurity as dependencies age. And plenty are poorly specified, with tool descriptions that are ambiguous, incomplete, or misleading, which directly affects agent reliability and security.

This is the npm circa 2015 problem, except the stakes are higher because agents act autonomously.

Why do point-in-time security scans fail for MCP servers?

Point-in-time scans fail because an MCP server is a moving target: 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.

We've observed servers that silently add new tools outside the original scope. Tool descriptions that change in ways that subtly alter agent behavior. Authentication mechanisms that get removed in updates (presumably for "developer convenience"). Dependency updates that introduce new vulnerabilities.

This is why point-in-time security assessments aren't sufficient. A server you scanned and approved last month might be materially different today. Continuous monitoring isn't a premium feature. It's the minimum viable approach.

How is the agent supply chain problem different from npm?

The agent supply chain repeats the npm pattern with two dangerous differences: agent tools carry far broader capabilities, and agents invoke them autonomously. 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. Sound familiar? It's the same pattern that created the JavaScript dependency crisis, with two key differences.

Agent tools have broader capabilities than npm packages. 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 vulnerable library needs to be called by your code. 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. When a server updates, your agent gets the new version immediately. No review step, no changelog, no approval.

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.

What patterns predict a risky MCP server?

After months of data, a few signals reliably predict higher risk: no version numbers, overly broad scopes, untyped inputs, and frequent undocumented changes.

Servers without version numbers or changelogs change unpredictably and silently. Tools with overly broad scopes (a "file management" tool that accepts arbitrary paths, a "database" tool that accepts raw SQL) carry proportionally broad attack surfaces. Tools that accept untyped, unvalidated inputs are far more likely to be exploitable. And servers that push frequent changes without documentation are either iterating fast (acceptable in early development) or behaving unpredictably (concerning in production).

These patterns become detection rules teams can use to evaluate new MCP servers before adding them to their agent configurations.

How should teams choose and manage 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 the ecosystem data 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 continuous visibility is the only way to keep up.

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.

Why does establishing agent security norms now matter?

What we're really watching is the birth of a new software ecosystem. It's messy, fast-moving, and full of both potential and real risk. The last time something like this happened was 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.

That's why we keep watching. And building.