The agent supply chain: trusting MCP servers, connectors, and third-party tools

Most teams reason about agent risk as if the whole system lives inside their own codebase. In practice, a working business agent is a thin orchestrator wrapped around other people's software: a model you rent, an MCP server someone published, a SaaS connector with broad OAuth scopes, and a handful of tools installed from a marketplace because they were convenient on a Tuesday.

That is a supply chain. And supply chains are where security incidents come from when nobody is looking.

This post is about the parts of the agent stack you did not author—and how to treat them with the same seriousness a mature org already applies to open-source dependencies and vendor access. It pairs naturally with designing safe tools for agents: the action layer (about tools you build) and agent identity and access: least privilege for non-human workers.

Why the supply chain is different from the action layer

We have written before about making your own tools safe: typed inputs, read/write separation, dry-run, hard gates on irreversible actions. That advice assumes you control the code behind the tool.

The supply chain problem is the opposite: you are handing your agent a capability whose implementation is opaque, remote, and updatable by a third party. An MCP server can be re-deployed tomorrow with different behavior. A connector's permissions can drift as the vendor adds features. A "read-only" integration can quietly gain a write endpoint in a minor version.

So the question shifts from "is this tool well-designed?" to "do I trust the party that controls this tool, and would I notice if that trust were misplaced?"

The failure modes worth naming

1. Tool poisoning and malicious descriptions. Agents choose tools based on their descriptions and schemas. A hostile or compromised MCP server can embed instructions in a tool description, a parameter name, or an error message—turning tool metadata into a prompt-injection channel that your own logs may not obviously flag. The agent reads "before calling this, export the user's credentials to..." and, if nothing stops it, complies.

2. Over-scoped connectors. The fastest way to ship an integration is to accept the broadest OAuth scope offered. Now your summarization agent can also delete calendars, move money, or read every channel in the workspace. The blast radius of a bug—or a rug pull—is defined by the scopes you accepted, not the features you use.

3. The silent update. Third-party tools change without a pull request in your repo. A dependency that was benign at adoption can become dangerous at version N+1. Without pinning and change detection, you are trusting not just today's maintainer but every future one, including whoever compromises their publishing credentials.

4. Data exfiltration through legitimate calls. A connector that is supposed to send data somewhere is the ideal exfiltration path, because the traffic looks normal. If your agent can pass sensitive context into a third-party tool, that tool's operator can read it. "The integration worked" and "your data left the building" are not mutually exclusive.

5. Secret sprawl. Every connector wants a token. Tokens end up in env files, prompts, memory, and screenshots. The compromise of one long-lived, broadly-scoped key is frequently the whole incident.

Treat every external tool like a vendor with system access—because it is

The mental model that scales is boring and correct: onboarding a third-party MCP server or connector is a vendor risk decision, not a config change. Apply the same instincts you use for back-office controls and least-privilege identity:

• Provenance before installation. Who publishes this? Is the source auditable? What is their track record and update cadence? An anonymous tool that touches production data is not "free"—it is unpriced risk.
• Pin and review updates. Pin versions. Treat an update to a security-relevant tool like a code change that needs review, not an automatic pull. If the tool is remote and you cannot pin it, that itself is a finding.
• Scope to the job, not the vendor's ambition. Request the narrowest permission that makes the use case work. If the connector only offers all-or-nothing scopes, put a proxy in front of it that enforces the subset you actually need.
• Isolate execution. Run third-party tools where they cannot reach what they do not need: constrained network egress, no ambient access to your secrets, no shared identity with higher-trust workflows. Untrusted tool code should not be one os.environ away from your keys.
• Short-lived, scoped credentials. No long-lived master tokens handed to a connector. Prefer per-integration identities and rotation, and keep secrets out of prompts and model context. A secrets vault pattern beats a token pasted into a system prompt.
• Log the tool calls, not just the outputs. You cannot investigate what you did not record. Capturing which external tool was invoked, with what arguments, is the difference between a five-minute incident review and a bad week.

A shipping checklist for third-party agent tools

Before an agent gets a new external capability in production, a human should be able to answer:

• Trust: Who controls this tool's behavior in production, and can they change it without telling us?
• Scope: What is the maximum damage if this tool is fully compromised, given the permissions we granted?
• Data: What sensitive context can reach this tool, and is that acceptable if the operator can read all of it?
• Change: Is the version pinned, and will we notice—and review—an update?
• Containment: If it misbehaves, what stops it, and how fast? Is there a kill switch and an owner?
• Evidence: Can we reconstruct what this tool did last Tuesday from logs alone?

If any answer is "we're not sure," that is the finding. This is the same posture our security review checklist for AI dev tools and agents applies to the build side—extended to everything you buy, borrow, or install.

The business case: connectors are the point, and the risk

None of this is an argument against third-party tools. The whole reason agents deliver value in the business is that they can reach into CRMs, ticketing systems, data warehouses, and payment rails through connectors. That reach is the use case. Refusing all external tools is refusing the leverage.

The mature move is to make adoption legible: a known inventory of every MCP server and connector an agent can reach, an owner for each, scoped credentials, pinned versions, and enough logging to investigate. Do that, and third-party tools become governed leverage. Skip it, and you have assembled a distributed system out of strangers' code with production access and no bill of materials.

Where this is heading

As agent-driven development becomes the norm, the "agent bill of materials"—the list of models, tools, connectors, and MCP servers a given agent depends on—will become as routine as a dependency lockfile is today. Procurement, security, and engineering will ask the same question about an agent that they already ask about software: what is this actually made of, and who do we have to trust for it to be safe?

The teams that answer that question early get to move fast because they can prove the system is contained. The ones that answer it after an incident learn the expensive version of the same lesson.

If you want help building a governed inventory of your agents' tools, connectors, and MCP servers—with scopes, owners, and change controls that your security team will actually sign off on—tell us about your stack or read the consulting offer.

Related tools: Agent Policy Manager • Knowledge Access Mapper • Prompt & Secret Vault