The MCP Server You Just Installed: A Supply-Chain Problem Wearing a Tool Icon

Adding an MCP server to an agent takes one line in a config file and a restart. That ease is the point of the protocol — any tool, any data source, any internal system can expose itself to an agent in minutes. It is also the problem. Every MCP server an agent connects to is a piece of third-party code, often maintained by someone you’ve never vetted, running with whatever access the agent’s login handshake hands it. Treat that install line as trivial and you’ve quietly added a supply-chain dependency with a direct line to your credentials — no code review, no package signature, no audit trail.

The failure: trust gets granted at install time, not at call time

Software supply-chain risk is a familiar story for packages: a compromised maintainer account, a typosquatted name, a dependency that ships malicious code in a minor version bump. MCP recreates the same shape with a twist that makes it worse. A malicious npm package still has to get past whatever the runtime lets it do. A malicious or compromised MCP server doesn’t need to escape a sandbox — it’s designed to be handed live credentials and invoked autonomously, and most agent setups grant that access once, at connection time, then never revisit the decision.

That single point of trust is the vulnerability. An MCP server that behaved correctly during evaluation can change behavior after a version bump — the rug-pull pattern — or it can have been malicious from the start, published under a plausible name to a registry with no verification of who’s behind it. Either way, the agent that connected to it in good faith keeps calling it in good faith, because nothing in MCP’s login handshake asks “is this server still the one I evaluated” on every call — only “does this client hold a valid token for this server.”

Why this is worse than a poisoned tool description

We’ve written before about tool poisoning and the confused deputy — a malicious instruction hidden in a tool’s own description, steering an otherwise trusted agent into acting against its owner’s intent. Supply-chain risk is the layer underneath that one. Tool poisoning assumes the server is who it claims to be and attacks through content the agent reads. A compromised server doesn’t need to poison anything it exposes — it already holds whatever the agent’s session grants it, and it can exfiltrate, over-collect, or misuse that access silently, with no injected text for anyone to spot in a log.

It compounds in a multi-agent setup. An agent that connects to five MCP servers to do its job has five separate points where a compromised dependency reaches live credentials — and in an A2A chain, the blast radius extends to whatever that agent is itself trusted to do on behalf of the agents that called it. One unvetted server, three hops upstream, becomes everyone’s problem.

Why “only install servers you trust” doesn’t scale

The honest advice — vet every MCP server before connecting it, pin versions, review diffs on updates — is correct and also not how teams actually adopt agentic tooling. The whole appeal of MCP is that a developer can point an agent at a new server in an afternoon to unblock a task. Requiring a formal security review before every connection either doesn’t happen, or happens once and is never repeated when the server updates. Registries that list MCP servers today provide discovery, not provenance guarantees — there is no protocol-level signature chain that lets a client prove a server is the same code, from the same publisher, that was there yesterday. Vetting at install time is a control that decays the moment nobody’s looking.

Where the fix actually has to live

• Credentials handed to an MCP server should be scoped to what that specific server needs, not to what the agent as a whole is trusted to do. A compromised weather-lookup server should never be in a position to touch the payments API just because the same agent also happens to hold a payments credential elsewhere in its session.
• Every credential should be short-lived and minted per call, not handed over once at connection time. A server that goes bad after today’s install shouldn’t still be holding a standing key it was issued weeks ago — the next call should require a fresh grant evaluated against current policy, not a cached one from the day trust was assumed.
• Every call an MCP server makes with a brokered credential needs to be logged against that server’s identity, not folded into an undifferentiated “the agent did something” entry. Reconstructing “which of our five MCP servers made this call” needs to be a lookup, not a forensic project.
• Policy needs to be able to say what a given server is allowed to touch, and enforce it on every call — including the thousandth call from a server that behaved perfectly on the first nine hundred ninety-nine. Good history is not a substitute for evaluating the call in front of you.
• Revocation has to reach every credential a compromised server was ever issued, immediately, the moment it’s flagged — not “until its current token happens to expire.”

The business case: don’t trust the server, trust the broker

None of the above requires solving supply-chain provenance for the entire MCP ecosystem — that’s a registry and tooling problem for the protocol community. What it requires is not routing your credentials’ fate through that unsolved problem in the first place. Fullmakt sits as the broker between every agent, every MCP server, and every credentialed call, which changes what a compromised or malicious server can actually do with the access it’s given:

• No MCP server ever holds a standing credential. Fullmakt mints a short-lived, narrowly scoped token per call, so a server that turns malicious after an update inherits nothing from its history of good behavior — its next call is evaluated on its own merits, against current policy, with the same scrutiny as its first.
• Scope is attached to the server’s identity, not the agent’s. A workspace can grant one MCP server access to a read-only reporting API and a different server access to nothing beyond its own narrow function, even when both are wired into the same agent.
• Every call is written to a tamper-evident audit trail identified by which server made it, which credential it used, and what it touched — so if a server is later found to be compromised, the incident review is “show me everything this server ever did,” not a log-correlation exercise across five different tools’ own inconsistent logging.
• Revocation is instant and total. Flag a server and every credential Fullmakt ever issued to it stops working on the next call, without waiting for a token to expire or coordinating a config change across every agent that connects to it.
• The same policy engine that already governs A2A delegation and tool poisoning defenses covers this too — supply-chain risk isn’t a separate control to bolt on, it’s the same “scope every call, log every call, revoke on demand” discipline applied to one more source of untrusted input: the server itself.

The pattern is the same one that runs through this whole series: you cannot fully solve trust at the edge — who published this server, whether this version is the one you reviewed, whether this agent’s next action is the one you’d have approved. What you can do is make sure that whatever gets through the edge is scoped so tightly, and watched so closely, that a bad answer at the edge stops being a catastrophic one.

FAQ

Isn’t this the registry’s problem to solve, not ours? Registry-level provenance (signed publishers, verified maintainers) would help and doesn’t exist yet in any enforced way across the MCP ecosystem. Until it does, the practical mitigation is architectural: don’t let a compromised server’s blast radius exceed the narrow thing it was supposed to do.

We only install MCP servers from vendors we trust — does this still apply? A trusted vendor’s account can still be compromised, and a trusted vendor still ships bugs and unreviewed version bumps. “We trust the publisher” is a reasonable input to a risk decision; it isn’t a substitute for scoping what that publisher’s server can actually reach.

How is this different from the MCP rug-pull pattern? Rug-pull is one specific mechanism — a server changing its tool description after approval. Supply-chain risk is broader: the server itself can be malicious or compromised from any point in its lifecycle, with or without ever changing what it tells the agent it does.

What should a governance review ask about MCP servers already in production? For each server: what credential scope does it hold, is that scope the minimum the server’s actual function requires, and could this team answer “show me everything this server did in the last 30 days” in under five minutes. If the answer to the last one is no, that’s the traceability gap that turns a compromised server from a contained incident into a prolonged one.

A login handshake proves an MCP server is who its connection string says it is, once, at connection time. It says nothing about whether that server should still be trusted with the credential it’s about to receive on call number one thousand — that has to be a decision made fresh, at the broker, every time.