When Your Tools Start Deciding

First, context, since not everyone tracks this space. MCP stands for Model Context Protocol. The name is literal: a protocol — a standard set of rules — for giving AI models context, meaning the data, tools, and systems they need to do real work. Anthropic released it as an open standard in late 2024. It gives AI systems one common way to connect to business tools and data, the way applications call APIs, instead of a custom-built integration for every system. Every major AI provider has since adopted it, which is why it's showing up everywhere at once.

In financial services, adoption has moved faster than most standards do. Banks have started shipping first-party MCP servers so agents can authenticate users, retrieve account context, and run workflows. Fintech vendors are wiring lending decisions, reconciliation, fraud review, and onboarding into it. Industry surveys already rank MCP among the top technology priorities at financial institutions — and inside most of them, adoption isn't a controlled, top-down program. It's individual teams connecting tools, one integration at a time.

That last part is where this article lives.

There's a specific way MCP integrations go wrong, and it's worth naming because it doesn't look like going wrong. It looks like being helpful.

Call it shadow logic — same family as shadow IT, and it spreads the same way: MCP tools that do more than expose capability. They orchestrate. They sequence calls in a required order. They apply rules — "only return accounts the caller should see," "reject amounts over the threshold," "always run validation before submit." They shape responses so the model gets a cleaner picture than the API actually gives.

Each of those choices is reasonable in isolation. Together they turn the tool layer into a second implementation of your business logic. Now the rules live in two places: the application, where they were designed, tested, and reviewed — and the tool layer, where they were reconstructed from memory by whoever wired up the integration.

Nothing forces the two to agree.

Drift is the failure, not the fork

The fork itself isn't the problem. Plenty of systems duplicate logic deliberately — cached validations, client-side checks that mirror server-side ones. The difference is that those duplications are usually acknowledged, and someone owns keeping them aligned.

Shadow logic drifts quietly. The application team ships a change to the approval threshold. The tool layer still enforces the old one — or worse, enforces nothing, because the person who wrote it assumed the app would catch it. Neither team broke anything. Neither team's tests fail. The behavior just diverges, and the first person to notice is the one reconstructing what happened after the fact.

That's the part that should bother anyone who thinks about decision governance: the divergence has no owner, no signal, and no record. It's a decision — "which version of the rule applies?" — that nobody made and nobody can reconstruct.

We've seen this class of risk before

If you've written a tenant-isolation architecture doc, you've already named this pattern for auth gates. When isolation is enforced at the application layer rather than the database, every code path is a place the gate can be missing. The doc says so plainly: the risk isn't that the gate is wrong, it's that enforcement is distributed, and distributed enforcement means every new path is a new chance to forget.

Orchestration in the tool layer is the same class of risk with a worse profile. An auth gate is at least binary — present or absent, and absence tends to surface loudly. Orchestration logic fails gradually. A sequencing assumption that no longer holds. A rule that's a version behind. A shaped response that hides a state the model needed to see. None of it throws an error. All of it changes outcomes.

The vendor version is worse

Everything above assumes you built the tool layer. Increasingly, you didn't. Vendors are shipping first-party MCP servers, and connecting one looks like a checkbox, not an integration project.

That convenience means the shadow logic is now someone else's. Whatever orchestration, rules, or response shaping lives inside a vendor's MCP server, you can't read it, can't diff it against your own policies, and won't be told when it changes. The layer you built drifts quietly; the vendor's layer you never saw to begin with. If their server decides what your agent sees, in what order, under what rules — that's third-party logic sitting inside your decision paths, with no change control on your side of the fence.

Financial institutions already have a discipline for this. It's called third-party risk management, and a vendor MCP server belongs in it. The diligence question is the shadow-logic question pointed outward: what does this server enforce, decide, or shape beyond exposing the API? A vendor who can't answer is asking you to accept logic you can't govern.

The test

A tool layer is thin when you can answer one question with a straight face: if we deleted every rule in the tools tomorrow, would the system behave the same?

If yes — the tools expose capability, and the application enforces policy — you have one source of truth and a wrapper. If no, you have two implementations, and you should be able to say who owns reconciling them, what tells you when they diverge, and where that divergence gets recorded.

Most teams can't answer any of the three. Not because they're careless, but because shadow logic never announced itself as a second system. It accreted, one helpful rule at a time.

Name it, and you can govern it. Leave it unnamed, and you'll meet it in an incident review — trying to explain why the system did the right thing according to one set of rules and the wrong thing according to the other.

Where we sit in this

DataVisuals builds Decision Governance™ for banks and credit unions. AI Decisions™ is the module that applies it to what your AI systems do: agent actions captured as decision records — signal, owner, decision, action, outcome — reconstructable the way an examiner expects any other decision to be.

If your tool layer is deciding things, that's how the decisions get on the record. The product page has the details.