What happens when an MCP tool changes after you approved it

An MCP server is a list of tools an AI agent can call — read an issue, open a pull request, query a table, delete a branch. When an admin approves one of those tools, they're approving what that tool does today. The awkward question is what happens to that approval tomorrow, when the server's maintainer ships a new version.

The gap nobody reviews

MCP servers change the way any dependency changes: new parameters, renamed tools, broader behaviour behind the same name. A tool that once took a single issue ID might start accepting a query that touches every issue in a project. Nothing about the tool's name tells you that happened.

In most setups the agent simply sees the new definition on its next connection and carries on. The security review happened once, against a definition that no longer exists. That's not a hypothetical failure of any one product — it's what “approve once” means when the thing you approved can change underneath you.

What an approval actually covers

We treat an approval as a decision about a specific definition: this tool, with this input schema, at this risk tier, for these people. If any of that changes, the decision should be made again by a person — not inherited silently. That principle drives three pieces of how Kryex handles MCP.

Fingerprinting every tool

When an admin registers an MCP server in Kryex Admin, Kryex reads the server's tool list and stores a SHA-256 hash of each tool's input schema alongside it. Nothing is usable yet: every discovered tool starts in quarantine. The hash is the fingerprint of exactly what the admin is about to review.

Tiers, and a floor the AI can't lower

A server can expose dozens of tools, so Kryex helps sort them. An AI suggests a tier for each tool — READ, WRITE or ADMIN. On its own, that would be a weak control: a model can be wrong, and a tool can be described to sound more harmless than it is.

So the suggestion sits on top of a deterministic floor. Keywords set a minimum: a tool that signals deleting, executing, running or SQL starts at ADMIN; one that creates, updates, adds or sends starts at WRITE. The final tier is the higher of the two. The AI can raise a tool's risk; it can never lower it below the floor. Then an admin decides, and only approved tools become callable — granted per person, per tool, at READ, WRITE or ADMIN.

When the fingerprint changes

Every later discovery compares each tool's schema hash with the one that was approved. If it differs, the tool goes straight back to quarantine, for everyone, until an admin looks at the new definition and approves it again. Unchanged tools keep working; only the changed one stops.

The agent doesn't need to know any of this. Calls go through Kryex Server, which holds the server's credentials and checks the person's grant before each call — so a quarantined tool simply isn't available, whatever the agent tries. Each decision is written to the hash-chained audit log, with the call's arguments stored only as a hash.

What to ask of any MCP setup

• Is an approval tied to a specific tool definition, or just to a name?
• What happens when that definition changes — does the tool keep working, or come back for review?
• Can automated risk scoring only raise risk, or can it talk a dangerous tool down?
• Where are the server's credentials — on the laptop, or behind something that decides?

We wrote up the full design in MCP Connectors: Architecture, Security & Governance, and the controls checklist in Securing MCP servers in the enterprise.