For thirty years, enterprise software followed the same pattern. A system of record sits in the backend — a core banking system, a CRM, an ERP. An application sits in the middle — handling business logic, access control, validation. A user sits at the front — interacting through the interface the application provides.
The application layer was never just a UI. It was a control point. It validated inputs, enforced permissions, logged actions, and prevented the backend from being accessed in ways it wasn't designed to handle. The app was where governance lived.
MCP — the Model Context Protocol — is systematically removing that control point. And most enterprises haven't noticed yet.
What MCP actually is
Model Context Protocol is an open standard that allows AI agents to connect directly to tools, data sources, and systems through a standardized interface. Instead of an agent calling a rigid API endpoint, MCP allows any system to expose its capabilities as a set of tools that an agent can discover, call, and chain together dynamically.
The practical implication is significant. Any system that implements an MCP server becomes directly addressable by any agent that speaks the protocol. No custom integration. No middleware. No application layer required.
For developers, this is an enormous acceleration. Building an agent that interacts with your CRM, your database, your internal knowledge base, and your communication tools used to require custom integrations for each. With MCP servers, the agent connects to all of them through a single protocol.
For enterprises, this creates a governance problem that most are not yet equipped to handle.
Why banks are building MCP servers
Financial institutions are among the earliest serious adopters of MCP infrastructure — and for understandable reasons. Banks operate some of the most complex, fragmented system landscapes in any industry. Core banking systems, risk engines, compliance databases, trading infrastructure, customer data platforms — each built in a different era, each with its own integration pattern.
AI agents that can navigate this landscape directly — retrieving account data, checking compliance rules, executing transactions, generating regulatory reports — represent an enormous operational efficiency gain. MCP makes that possible without rebuilding the underlying systems.
The vision is straightforward: expose your core systems as MCP servers. Deploy agents with the right capabilities. Let the agents handle the workflows that currently require human navigation across a dozen different interfaces.
The app layer doesn't get rebuilt. It gets bypassed.
What disappears with the app layer
This is where the governance problem becomes concrete.
Traditional enterprise applications weren't just interfaces. They were implicit governance infrastructure. When a relationship manager opened a customer record in the CRM, the application enforced their access level, logged the access, validated any updates they made, and prevented them from doing things outside their permitted scope. The application was the policy enforcement point.
When an AI agent accesses the same customer record through an MCP server, none of that implicit governance applies — unless it has been explicitly built into the MCP server itself, or unless a governance layer sits between the agent and the server.
Most MCP servers being built today are not being built with that governance layer. They're being built for capability and speed. The governance question is being deferred.
That deferral is a significant risk. Every MCP call an agent makes is an action taken in the name of the organization — against real systems, with real consequences. A customer record updated. A transaction scoped. A compliance check triggered. A document retrieved and summarized.
The application layer that used to validate, log, and scope these actions is gone. Something needs to replace it.
Every MCP call is a legal event
In Moffatt v. Air Canada, a tribunal held the airline liable for incorrect information its chatbot provided — rejecting the argument that the bot was a separate entity with its own policies. The principle established is clear: your agents act on your behalf. You are accountable for what they do.
That principle applies with full force to MCP-mediated actions. When an agent calls a core banking system through an MCP server and scopes a payment, that authorization is legally attributable to the organization that deployed the agent. When an agent retrieves personnel data through an HR system MCP server and uses it to make a recommendation, that retrieval and that recommendation are subject to GDPR, to EU AI Act obligations, to whatever regulatory framework governs that data.
The absence of a human in the loop — the fact that no application interface was involved, no employee clicked a button — does not create a legal shield. It removes one.
Regulators don't ask whether a human approved each action. They ask whether the organization had governance infrastructure in place. Whether actions were logged. Whether the record can be verified. Whether the organization can demonstrate what its agents did, why, and under what authority.
An MCP call with no governance layer is an undocumented organizational action.
The scale of the exposure
Consider what a mid-size bank's MCP infrastructure might look like in 2027. Core banking system exposed as an MCP server. Compliance database. Risk engine. Customer data platform. Document management system. Trading infrastructure. Communication tools.
Each of these systems is now directly accessible to any agent that has been granted access. Each call is a potential audit event under DORA, under the EU AI Act, under GDPR. Each call needs:
- An identity — which agent made it
- A scope — was this agent scoped to call this server with these parameters
- A record — what exactly was called, what was returned, in what context
- A tamper-evident trail — proof that the record hasn't been modified since the call was made
That's not a logging configuration. That's a governance architecture.
Where the governance layer needs to sit
The lesson from the application layer's disappearance is that governance cannot be embedded in the thing being governed. Apps worked as control points because they sat between the user and the system. When the app goes away, the control point needs to move — not disappear.
A governance proxy that sits between agent and MCP server occupies exactly that position. Every call from every agent to every MCP server routes through it. Identity is verified. Scope is enforced. The call is signed and chained into a tamper-evident record before it reaches the target system.
The MCP server doesn't need to be rebuilt. The agent doesn't need to be modified. The governance layer intercepts, governs, and forwards — invisibly, at under 100ms.
The window before this becomes a crisis
MCP adoption is accelerating. The enterprises building MCP infrastructure today are mostly focused on capability — what their agents can do, how fast they can move, how many systems they can connect. Governance is a secondary consideration.
That will change. It always does. The question is whether it changes proactively — as enterprises design their MCP infrastructure with a governance layer from the start — or reactively, after an incident that makes the absence of governance undeniable.
Banks that are building MCP servers today are building the critical infrastructure of their next operating model. The governance layer that protects that infrastructure needs to be designed alongside it — not retrofitted after the first agent does something it shouldn't have.
The app layer is going away. The control point it represented is not optional. It just needs to live somewhere else.
↳ KYDE
Kyde governs not just LLM calls but every tool your agents invoke — including MCP servers. Every call is intercepted, traced to an agent identity, checked against role-based scope, and written into a tamper-evident audit trail. The app layer disappears. The governance layer doesn't.