Your MCP Servers Are Your New Software Supply Chain

The Model Context Protocol made it trivially easy to give agents tools. That's the point — and the problem. An MCP server is code that runs with your agent's permissions, and its tool descriptions are read by the model as instructions. If that sounds like a supply-chain risk, it is.

Why this is different from ordinary dependencies

• Tool descriptions are part of the prompt. A poisoned description can steer an agent without any malicious code at all.
• Agents chain tools. The blast radius of one compromised server includes everything the agent can reach.
• Developers add servers casually, often from community registries, with no review step.

What we did

When we rolled out AI coding agents, MCP configuration was centrally managed alongside the rest of the tool settings — an allow-list, not a free-for-all. We also worked with Cyber to enable logging and attribution headers on MCP tool use, so every agent action could be audited and traced back to a user and session. Those logs fed sample detection patterns that Cyber turned into live SOC alerts.

If you can't attribute an agent's action to a human and a session, you can't investigate it.

A minimum viable MCP policy

• Maintain an allow-list of approved servers, pinned to versions.
• Review tool descriptions as carefully as code — they are code, for the model.
• Scope credentials per server; never hand an agent your full token.
• Log every tool invocation with user, session and arguments.
• Feed those logs to your SIEM and write detections before you need them.
• Rehearse an AI incident at least once a year.

None of this is exotic. It's the software supply-chain discipline we already know, applied to a surface most organisations haven't inventoried yet.