--- title: "How Software Trusts Software: MCP, A2A, & the Registries Agents Use" date: 2026-10-19T17:16:25Z modified: 2026-10-19T17:41:09Z permalink: "https://redmonk.com/kholterhoff/2026/10/19/mcp-a2a-registries-agents/" type: post status: publish excerpt: "" wpid: 603 categories: - AI - security timestamp: 2026-10-19T17:41:09Z tags: - AI - security --- ![](http://redmonk.com/kholterhoff/files/2026/10/2007_09_23_bos-lax_003.JPG_1437514992-scaled.jpg) There is growing concern among security professionals that developers are treating protocols for connecting AI agents such as Model Context Protocol (MCP) and Agent2Agent (A2A) as though they were trust services, when neither was designed to vouch for what it connects, or is connecting to. A recent [USENIX Security study](https://arxiv.org/abs/2406.10279), for example, found that roughly twenty percent of AI-generated package references pointed to packages that did not actually exist, with the same hallucinated names recurring predictably enough to make them attractive attack targets. New paradigms built for AI agents create unique challenges setting them apart from the registries and marketplaces that I discuss in previous articles for my series concerning why [Modern Software Registries are a Trust Service](http://redmonk.com/kholterhoff/files/wp-mfa-exports/post/modern-software-registries-trust-service.md) and why, in our era of cheap code, vendors now give away artifacts and sell [Assurance](http://redmonk.com/kholterhoff/files/wp-mfa-exports/post/the-artifact-is-free-assurance-is-the-product.md). Agents pick their tools from catalogs, so a poisoned listing is a direct line into the agent. The problem comes when a locally installed malicious MCP server runs as an ordinary process with the user’s file and credential access, and its tool descriptions are read by the model as instructions, which lets it steer the agent into misusing other tools. An example of this is the 2025 [postmark-mcp npm package exploit](https://thehackernews.com/2025/09/first-malicious-mcp-server-found.html), which added a single line that BCC’d every email the agent sent to the attacker. In this post I start by discussing MCP, whose official registry verifies who published a server but not what the server does. I then turn to the A2A protocol, which has no standard registry at all. I then close with the shift that ties them together: the prevalence of agents acting autonomously to decide whether or not to trust a listing. ## MCP: A “Metaregistry” That Holds No Code Where does MCP fit into the idea of registries as a trust service? The official MCP Registry does not host software at all. It hosts metadata, a server.json record that says what the server is called and where to get it. A weather-mcp server, to use the registry’s own example, might be [listed in the MCP Registry but live as a package on npm](https://modelcontextprotocol.io/registry/about#:~:text=metadata%20that%20points%20to%20those%20packages). This makes the registry a discovery layer above npm, PyPI, and Docker Hub, and organizations can run their own curated public and private sub-registries against the same API. When MCP’s maintainers announced the project in May 2025 they called it a “[metaregistry](https://github.com/modelcontextprotocol/registry/discussions/11#:~:text=hence%20this%20is%20a),” a registry of other registries, explaining that its records point to where code is published elsewhere. MCP’s architecture splits trust across layers. Server names follow a reverse DNS format tied to a verified GitHub account or domain, and [publishers must prove ownership of that namespace through GitHub, DNS, or HTTP challenges](https://modelcontextprotocol.io/registry/about#:~:text=Namespace%20authentication%20requirements). What the registry does not do is look at the code. By its own description, the registry handles namespace authentication and metadata hosting while “[relying on the broader ecosystem for security scanning of actual server code](https://modelcontextprotocol.io/registry/about#:~:text=relying%20on%20the%20broader%20ecosystem).” It [delegates security scanning to two other parties](https://modelcontextprotocol.io/registry/about#:~:text=delegates%20security%20scanning): the package registries underneath it, which run their own malware detection, and the downstream aggregators and marketplaces built on top of it, which can add ratings, curation, or additional checks. MCP describes its own metadata as “[deliberately unopinionated](https://modelcontextprotocol.io/registry/about#:~:text=deliberately%20unopinionated).” Getting listed requires proving you own a name. Nothing more. One way to understand this distinction is by way of layers: | **Layer** | **Example** | **What it verifies** | **What it leaves to someone else** | | --- | --- | --- | --- | | Metaregistry | Official MCP Registry | The publisher owns the namespace | What the server code does | | Package registry | npm, PyPI, Docker Hub | The package came from its authorized publisher; reactive malware scanning | Whether an authorized release is safe | | Aggregator or marketplace | Glama, PulseMCP, Smithery | Whatever curation it chooses to add | What the code does, unless the operator scans it | | Enterprise MCP registry | JFrog MCP Registry, GitHub MCP Registry | Which servers the organization has pre-approved, and who may use them | Whether an approved server’s next release is still safe | | Private artifact registry | Cloudsmith, JFrog Artifactory | Only policy-approved versions of the packages behind MCP servers reach developers, e.g. by minimum package age | What the server does once it runs | | Vetted container catalog | Docker MCP Catalog | Servers ship as container images, isolated by default | Whether the tool behaves as described inside its container | [Part one](http://redmonk.com/kholterhoff/files/wp-mfa-exports/post/modern-software-registries-trust-service.md) of this series showed that package registries now verify origin well and behavior poorly, and that their malware scanning is reactive: it catches bad packages after publication, not before installation. So the MCP Registry delegates its hardest problem to a layer that has not solved that problem either. Each layer is upfront about its own scope, but the trouble is that each one’s scope stops where it assumes another begins. In the article “Securing the Model Context Protocol (MCP): Risks, Controls, and Governance,” authors Herman Errico, Jiquan Ngiam, and Shanita Sojan [explain](https://arxiv.org/pdf/2511.20920#:~:text=does%20not%20require%20code%20review) that listing does not require code review, security audit, or malware scanning, yet users may incorrectly assume registry presence implies vetting. The metaregistry vouches for who, the package registry vouches for where the bytes came from, and the question of whether to run them falls to whoever reads the listing. For an MCP server, that reader is increasingly an agent configuring its own tools. ## A2A: [This is Not A Registry](https://en.wikipedia.org/wiki/The_Treachery_of_Images) Unlike MCP, A2A has no ambitions to serve as a metaregistry, but as an open communication standard that lets agents built by different vendors discover one another and delegate tasks, A2A is still positioned within the auspices of catalog discoverability. A2A opted not to build a centralized authority by design. Discovery runs through Agent Cards, JSON documents [describing](https://a2a-protocol.org/latest/topics/agent-discovery/) an agent’s identity, capabilities, and skills. An agent publishes a card on its own domain, so ownership is proven by the same DNS and TLS that secure the rest of the web. The protocol lets users configure discovery based on environmental needs: public agents host their cards at public URLs, enterprises or marketplaces can curate registries, and tightly coupled systems can directly configure. An Agent Card is self-asserted. The agent describes itself, and the client’s main assurance is that it fetched the description from the domain it meant to reach. The spec defines [Agent Card signing](https://a2a-protocol.org/latest/specification/#84-agent-card-signing), so a card can carry a JWS signature. But the card’s signatures field is [optional](https://a2a-protocol.org/v1.0.0/specification/#441-agentcard), and a valid signature only means something if the client already knows which key to trust for that agent. A signature proves the card came from whoever holds the key. It says nothing about what the agent will do with the task it is handed. A2A also does not standardize a central place to prove you own a name like MCP does, and instead leaves that to the hosting environment. A2A’s own guide to agent discovery describes [curated registries](https://a2a-protocol.org/latest/topics/agent-discovery/#2-curated-registries-catalog-based-discovery), central catalogs where an organization lists the agents it has approved, as one way for clients to find agents, and it credits them with the benefits you would expect: centralized governance, capability-based search, and access controls. But it stops short of defining one. [The current A2A specification does not prescribe a standard API for curated registries](https://a2a-protocol.org/latest/topics/agent-discovery/#:~:text=does%20not%20prescribe%20a%20standard%20API), so every registry has to be built from scratch. In practice, enterprises end up running an internal registry or developer portal to catalog agent capabilities, and the major platforms have built registries tailored to their own ecosystems. Within the past year, AWS launched an [Agent Registry in Bedrock AgentCore](https://aws.amazon.com/about-aws/whats-new/2026/04/aws-agent-registry-in-agentcore-preview) that registers A2A Agent Cards directly, Microsoft shipped [Agent 365](https://learn.microsoft.com/microsoft-agent-365/overview) alongside Entra Agent ID, Google introduced an Agent Registry in its [Gemini Enterprise Agent Platform](https://cloud.google.com/blog/products/ai-machine-learning/introducing-gemini-enterprise-agent-platform), and Salesforce’s MuleSoft [added one](https://www.salesforce.com/in/news/stories/mulesoft-agent-fabric-automated-agent-discovery/) to Agent Fabric. Each promises curation and approval workflows for registries for AI agents, and are scoped to their own platform. Neither MCP nor A2A answers the question an agent actually needs answered: “should I use this?” MCP stops at “this publisher owns this name.” A2A mostly stops at “this card came from this domain.” Even [AGNTCY](https://www.linuxfoundation.org/press/linux-foundation-welcomes-the-agntcy-project-to-standardize-open-multi-agent-system-infrastructure-and-break-down-ai-agent-silos), which joined the Linux Foundation in July 2025, mostly extends the same layer. Its directories make A2A agents and MCP servers discoverable across vendors and give them verifiable identities, which is useful, but knowing exactly who an agent is still doesn’t tell you whether to trust it. The open efforts are converging on identity and discovery and leaving judgment to someone else. My bet is that someone else will end up being a vendor, and the answer ends up being a product, not a spec. ## Who Reads the Registry Now? The gaps in trust alluded to in this post have similar causes. Each layer assumes someone will read the listing carefully, and that reader is increasingly an agent. For decades, registries were optimized around deliberate human action. A developer searched for a package, read documentation, perhaps skimmed the GitHub repository, and eventually typed npm install. Today that workflow increasingly belongs to coding agents, which generate code, resolve dependencies, install packages, and execute builds at a pace no human can match. In April, GitHub CTO [Vlad Fedorov](https://www.linkedin.com/in/vladimir-fedorov-b2a9302/) wrote that the company now [needs to design for 30 times its current scale](https://github.blog/news-insights/company-news/an-update-on-github-availability/#:~:text=30X%20today), up from an earlier 10x plan, because agentic development workflows have accelerated so sharply since December 2025. The primary consumer of registries is no longer a developer. Increasingly, it’s another piece of software, and that helps explain a pattern running through this series: registries that grew up separately, serving different languages and kinds of artifacts, have started building the same features. npm, PyPI, RubyGems, crates.io, and NuGet all adopted trusted publishing, swapping long-lived tokens for short-lived credentials tied to a verified build pipeline. Hardened image vendors and Open VSX both now sell service-level agreements. The MCP Registry verifies namespace ownership much as package registries verify publishers. Each is a trust claim a machine can check without a person in the loop. The biggest story of the past two years isn’t any single security feature. It’s that so many separate registries have converged on the same ones. It also explains why every trust signal in this series is machine readable. Nobody sits down and reads an SBOM, a Sigstore signature, a SLSA attestation, or an Agent Card. Those documents exist so that a scanner, a policy gate, or another agent can evaluate them without asking a person. The signals built for humans work differently. Download counts, verified-publisher badges, and star ratings describe a publisher’s track record, not the release in front of you. When an attacker takes over a legitimate publisher’s account, the malicious version inherits all of that reputation. In the [Nx Console breach](https://nx.dev/blog/nx-console-v18-95-0-postmortem), the trojanized extension shipped with its verified badge and its 2.2 million installs intact. That is why hijacking a trusted publisher is worth so much more to an attacker than creating a new one: the human-facing signals vouch for the account, and the account is what gets stolen. > GitHub’s report today confirms that the compromised Nx Console extension was used as the initial access vector in this attack. > > This is a difficult thing to read as the CEO of Nx, and I want to be direct about it: we take responsibility for the role our software played in this… > > — Jeff Cross (@jeffbcross) [May 20, 2026](https://x.com/jeffbcross/status/2057236396658811020?ref_src=twsrc%5Etfw) Which brings this series back to where it started. I asked last year [whether npm was enough](http://redmonk.com/kholterhoff/files/wp-mfa-exports/post/is-npm-enough.md), and spent three posts arriving at the conclusion that it was the wrong question. For years, software registries primarily solved distribution. Today they increasingly solve trust. Tomorrow they may become the discovery layer for software itself. The defining question is becoming how software finds software, and, harder still, how it decides what to believe. **Disclaimer:** AWS, Docker, Google, Salesforce/MuleSoft, and Microsoft/GitHub are RedMonk clients. Header image: Doc Searls, [“Logan control tower along with Continental Airlines and Cape Air aircraft (September 2007)](https://en.wikipedia.org/wiki/Logan_International_Airport#/media/File:2007_09_23_bos-lax_003.JPG_(1437514992).jpg).” Wikipedia.