The MCP server you approved is not the MCP server you're running.

Somewhere in your organization there is a spreadsheet, a ticket, or a wiki page that records the decision: this MCP server was reviewed and approved for use. Someone looked at the tools it exposed, judged the risk acceptable, and signed off. That artifact has a date on it.

Here is the uncomfortable question: what has the server done since that date?

MCP servers are live services. The tools, resources, and prompts they expose are whatever the operator says they are right now — not what they were when your security team looked. There is no version pinning in the protocol, no lockfile, no "hold at the reviewed release" option. When the vendor ships a change, every connected client gets it on the next tools/list call. Your approval described a snapshot. You are running the stream.

Approval is a snapshot. The surface is a stream.

Traditional software dependencies earned decades of tooling precisely because they change: version ranges, lockfiles, dependency review bots, staged rollouts. An npm package cannot silently become a different package under your running application — you have to take the update, and the ecosystem gives you a dozen places to notice.

An MCP connection has none of that. The capability surface is resolved fresh at runtime, server-side, on the vendor's schedule. In practice that means:

• A new tool is a new privileged action, live immediately. The read_records server you approved can add bulk_export on a Tuesday, and by Wednesday your agents can call it.
• A widened schema is a widened blast radius. An optional recipients parameter added to a send-report tool changes who data can reach — without a single new tool appearing in any list.
• A rewritten description is a rewritten instruction. Tool descriptions and server-registered prompts are text the model reads and follows. A vendor editing a description is, functionally, a vendor editing your agents' behavior. This is also exactly where a compromised server would hide an injection.

None of these events produces a notification. Not to the developer who configured the connection, not to the security team that approved it, not to anyone. The change simply is, from one conversation to the next.

What drift looks like in practice

Map the changes above onto the change-management vocabulary your organization already uses, and the gap becomes obvious. A new tool is a new API endpoint with production access — in any other context, that goes through review. A schema change is an interface change — that gets a diff and an approver. A description rewrite is a behavior change in a production system — that gets, at minimum, a changelog entry.

For MCP surfaces, most organizations today have: nothing. The review that happened in March is treated as permanently valid, the way a firewall rule review might be — except firewall rules don't rewrite themselves, and this surface does.

The result is a quiet inversion of your security posture. You believe your AI agents can do the set of things you approved. What they can actually do is the set of things your vendors currently expose, which drifts away from the approved set at whatever rate those vendors ship. The longer since the review, the larger the gap — and the gap is invisible by default.

Treat review expiry like certificate expiry

The fix is not heavier one-time reviews. It is accepting that for a mutable surface, a review has a shelf life of exactly one upstream change — and building the machinery to know when that shelf life ends.

That machinery is small and unglamorous:

1. Snapshot the surface at approval time. The raw output of tools/list, resources/list, and prompts/list is the canonical record of what you actually approved. Attach it to the approval artifact.
2. Diff continuously. Re-fetch the surface on a schedule and compare. Any delta between the running surface and the approved snapshot means your approval no longer describes reality.
3. Route changes by severity. Not every delta deserves a full re-review. A workable triage: new tools and schema changes trigger re-approval; description and prompt changes trigger a quick human read; cosmetic changes get logged. The point is that something is triggered — the current default is that nothing is.
4. Make the re-review cheap. If re-approval takes a committee, teams will route around it. A side-by-side diff of before and after, in front of one accountable reviewer, closes most cases in minutes.

Organizations already run this exact loop for TLS certificates, for IAM key rotation, for dependency updates. Nobody considers "we checked the certificate once in March" a control. The same instinct just hasn't reached the AI tool surface yet — mostly because the surface is new, and partly because nothing breaks visibly when it drifts. Certificates expire loudly. MCP approvals expire silently.

The question worth asking your team this week is not "did we review our MCP servers?" You probably did. It's "if one of them changed last night, when would we find out?" If the honest answer is at the next annual review — or never — then what you have is not an approved supply chain. It's an approved memory of one.