Agent Skill Marketplaces and Third-Party MCP Servers: The Supply Chain Vetting Discipline Most Mid-Market Buyers Have Not Built

What the marketplace data shows Through late 2025 and the first months of 2026 the third-party component ecosystem for autonomous agents matured from a hobbyist surface into a production substrate that mid-market buyers' engineering functions and individual workforce members are already pulling from. The data on what the substrate looks like, in security terms, is sobering. The security firm Snyk audited nearly four thousand skills published to a single open-source agent platform's community marketplace and found that seven point one percent mishandled secrets through LLM context windows, credentials, API tokens, and system identifiers flowing into model prompts where they could be exfiltrated through prompt injection or surfaced through normal model responses. Independent researchers including Zenity have published evidence of indirect prompt injection vectors in third-party MCP servers, the agent gets a tool-call response that contains adversarial instructions, the agent treats the response as context, the agent acts on the instructions. The Reuters reporting on the adjacent agent-network breach surfaced a database that exposed six thousand operator emails and over a million credentials. The component class is broader than the skill marketplaces. Browser extensions that act as agents inside the workforce member's browser, plugin connectors that integrate agents into messaging platforms, MCP servers that expose third-party SaaS as tool surfaces, and the agent-side adapters that wrap commercial APIs in agent-callable form all belong to the same supply chain. The supply chain is the agent class's npm: a vast public ecosystem of components the buyer's workforce can pull into the agent's tool surface in minutes, with quality and security characteristics that vary widely and frequently are not documented. For a regulated mid-market buyer the implication is that the package-vetting discipline the buyer's engineering function applies to npm, Maven, PyPI, or NuGet packages now applies, with extensions, to the agent component class. Most mid-market buyers we audit have not yet made the extension. The class is unfamiliar; the discipline is not. What is structurally different about the agent supply chain Three structural features distinguish the agent component supply chain from the package supply chains the buyer's engineering function already vets. The component runs against context, not just code. A traditional package contributes code that executes in a defined context the engineering function controls. An agent component, a skill, a plugin, an MCP server tool, contributes a behavior that runs against the agent's context window. The component's behavior depends on the agent's surrounding context in ways the component's documentation cannot fully describe. A skill that "summarizes the current document" is a different security object when the document is a public webpage versus when it is a clinical note containing PHI versus when it is a contract subject to attorney-client privilege. The vetting question is not just what does this component do but what does this component do across the contexts the buyer's agent will encounter. The component receives untrusted output as input. A traditional package's inputs come from the application's controlled call sites. An agent component's inputs include the outputs of other tool calls, retrieved documents, web pages the agent fetched, messages from external collaborators, any of which can contain text that, when the agent reads it, looks like an instruction. The indirect prompt injection class, the email the agent fetched contained instructions that the agent then acted on, is a category of attack the package supply chain did not have a direct analog for. The vetting question includes what untrusted-input surfaces the component creates and how the agent's policy layer handles instructions that arrive through them. The component frequently holds credentials. A traditional package executes against credentials the application provides at call time. An agent component frequently holds credentials, an MCP server with stored OAuth tokens for the workforce member's accounts, a skill with a cached API key, a plugin with an embedded service-account credential. The credential storage is, by Snyk's measurement, the most common security failure mode in the marketplace. The vetting question includes where the component stores credentials, how the storage is protected, and how the credentials are revoked when the component is uninstalled or when the workforce member's credentials are rotated. The three structural features compound. A component that runs against unbounded context, that receives untrusted output as input, and that holds credentials is a component whose security envelope cannot be characterized by reading its README. The vetting discipline has to extend to the component's behavior, not just its source. The five-criterion vetting screen The Adopt-AI-Safely Diagnostic now produces a five-criterion vetting screen that we run against any third-party agent component a regulated mid-market buyer's workforce or engineering function intends to install. The screen is not exotic; it is the package-vetting discipline extended to the new component class. Criterion one, provenance. Who published the component? Is the publisher a known organization with a verifiable identity, a known individual with a long-running reputation in the ecosystem, or an anonymous handle? Has the publisher published other components, and what is the security record on those components? A component from an anonymous publisher with no other published work and no community signal warrants either a heavyweight code review or a categorical disallow. Criterion two, secret handling. Does the component handle credentials, and where does it store them? Does it pass credentials into the LLM context window, the Snyk-measured failure mode, or does it call out to an authentication surface the agent's context never sees? Is the component's secret-handling pattern documented or has it been reverse-engineered from the source? The vetting answer is structurally different for components that pass secrets through context than for components that handle secrets out-of-band. Criterion three, input provenance. Does the component receive untrusted output as input? An MCP server that wraps a web-fetch tool, an email-reading skill, a calendar integration, a document-retrieval skill, these all receive content from surfaces the agent does not control. The vetting answer documents the component's input surfaces and the policy layer that should handle instructions arriving through them. The agent control layer covered in the agent control layer briefing is the architectural answer; the component vetting confirms the input surfaces are within the policy layer's scope. Criterion four, permission scope. What permissions does the component request, and what permissions does it actually use? The two are frequently different, components commonly request broader permissions than their stated function requires, against the case the publisher anticipates a future feature. The vetting answer documents the over-permissioning and either accepts the over-permissioning with mitigations, requires the publisher to issue a permission-scoped variant, or disallows the component. The principle of least privilege from the trust architecture briefing applies directly. Criterion five, observability. What audit-log surface does the component produce? Can the buyer's security function pull a log of the component's tool calls, parameter values (or hashes), and outputs? Components that do not expose an audit-log surface are observability gaps that require the buyer to add logging at the orchestration layer; components that expose unstructured logs require the buyer to invest in parsing. The vetting answer is the operational decision about how the buyer will satisfy the §164.312(b) audit-controls requirement against the component class. A component that passes all five criteria is a component the buyer can sanction with appropriate documentation. A component that fails one or two is a conditional approval with documented mitigations. A component that fails three or more is a disallow until remediated by the publisher or replaced by a sanctioned alternative. The MCP server class specifically MCP, the Model Context Protocol, became, through 2025 and into 2026, the standard interface for connecting agents to third-party tool surfaces. The standard solves a real problem: agents need a structured way to discover and call tools, and the protocol provides one. The structural risk is that the protocol does not, by itself, address the supply-chain question. An MCP server is a piece of software that exposes tools to an agent; it is published, installed, and run on the same trust assumptions as any other piece of software. The protocol is the integration; the security envelope is the component's responsibility. The mid-market buyers we audit are encountering three patterns in MCP server adoption. The first is the engineering-function adoption: an engineering team installs an MCP server to connect an internal agent to a SaaS surface (Salesforce, ServiceNow, GitHub, Linear). The vetting discipline applies; the buyer's engineering security review extends. The second is the workforce-member adoption: a workforce member installs an MCP server to connect their personal agent (frequently the open-source class covered in the shadow agent discovery briefing) to their workforce-credentialed accounts. The vetting discipline does not apply because the install is outside the IT function's view. The third is the vendor-bundled adoption: a sanctioned SaaS vendor ships an MCP server as part of their AI integration story, and the buyer's existing vendor relationship is the implicit vetting answer. The third pattern is the safest of the three; the second is the most exposed. For each of the three patterns the buyer's posture is different. The first pattern fits the engineering supply-chain discipline. The second pattern fits the shadow-agent governance discipline. The third pattern fits the existing vendor-management discipline with an extension to confirm the bundled MCP server's security envelope matches the vendor's stated scope. None of the three is novel; all three require the discipline to be deliberately extended to the MCP class. What we recommend A regulated mid-market buyer whose engineering function or workforce uses any third-party agent component should treat the supply-chain vetting discipline as the next AI governance posture update. First: publish the buyer's component-vetting policy. The policy names the categories of agent components in scope (skills, MCP servers, plugins, browser extensions), the vetting screen each requires, the responsible function (engineering, security, IT), and the disposition pathway for vetted, conditionally-approved, and disallowed components. Most mid-market buyers do not yet have this policy as a written artifact. Second: run the five-criterion screen against the existing inventory. The shadow-agent discovery audit produces the inventory of installed components; the screen produces the per-component disposition. Components that fail the screen are remediated, replaced, or removed. Third: integrate the screen into the engineering function's existing supply-chain process. The screen is an extension of the package-vetting discipline the engineering function already runs against npm, PyPI, Maven, or NuGet packages. The integration is light; the discipline is familiar. Fourth: integrate the screen into the buyer's workforce acceptable-use policy. The policy names the components workforce members may install on workforce-credentialed devices, the vetting status of common components, and the disclosure requirement when a workforce member installs a component the policy does not yet cover. Fifth: treat MCP server vendor selection as a procurement event. When a sanctioned SaaS vendor ships an MCP server as part of their AI integration, the procurement file captures the MCP server's security envelope as part of the vendor relationship, with the screen run as part of the vendor's annual review. The Adopt-AI-Safely Diagnostic now treats third-party agent component vetting as a standing component for engagements involving any agent class with a third-party tool surface. The component class is new; the discipline is not. The buyers who extend the supply-chain vetting discipline to the component class before a 2027 audit reaches it are the buyers whose component supply chain becomes a documented surface rather than an exposure surface. The class is the agent's npm. The discipline is the buyer's existing one, applied with appropriate extensions.