Why AI agents are becoming a control problem for banks
/
Andrew George is managing director of 3forge, an enterprise software platform purpose-built for financial institutions.
Model Context Protocol (MCP) is attracting attention as banks consider more seriously how agentic AI will operate in live environments. MCP is defined as an open-source standard for connecting AI applications to external data sources, tools and workflows. It’s less of a technical curiosity and more of a control issue. The challenge is introducing a new AI interface without creating gaps in governance, visibility, or oversight. If left ungoverned, MCP can quietly bypass existing entitlement controls, audit trails, and oversight frameworks — creating a backdoor into regulated systems.
Why should banks care about MCP? Because agents operating through MCP are not passive data consumers — they chain actions, call internal functions and persist across workflows. In a regulated industry, that creates real exposure if access accelerates faster than the architectural safeguards meant to contain it. Banks deploying agentic AI cannot afford to treat MCP as someone else's problem. How institutions govern it — or fail to — will determine whether AI expands their capabilities or quietly erodes the control environments they are required to maintain.
MCP changes more than the user experience. It gives agents a cleaner path to discover data, invoke tools, and execute logic across production environments. Much like how REST changed application integration, MCP is starting to reshape how models connect to live systems. But MCP is not simply another AI integration standard, it represents the emergence of a new interface layer between intelligent systems and enterprise infrastructure, shifting the architectural conversation from model capability to how access to data and operations is governed.
In a regulated industry, that shift carries real consequences, as agents are not passive data consumers. They chain actions, call internal functions, and persist across workflows. MCP servers can also connect directly to data repositories, sometimes relying on implicit trust or extension-based controls instead of deeply embedded entitlement models. What happens when access accelerates faster than the architectural safeguards meant to contain it?
The stakes are bigger than another integration project
Banks do not need another reminder that AI is moving fast. What matters is if infrastructure and governance fail to keep up. One example, from McKinsey's Global Banking Annual Review, tied to this debate warns that if banks do not adapt their business models to third-party agents, global bank profit pools could decline by $170 billion, or 9%, over the next decade.
The implementation side is just as telling. The roadmap many financial institution CTOs are working toward is not a single release, but a progression. Virtualized legacy access first, then a governed AI gateway, then AI-native development inside trusted guardrails. Within that progression, MCP naturally becomes part of the governed gateway layer, where agent access to enterprise systems is centralized, permission-aware, and auditable rather than distributed across ad hoc integrations. Much of the infrastructure supporting that progression already exists in production environments across major financial institutions. The next stages are closer than many teams assume.
How MCP turns into a governance problem
MCP is not a problem on its own. The problem starts when banks treat it as a lightweight integration tool rather than recognizing it as a new entry point into governed systems. If it functions as a special access tier, agent-based interactions can quietly bypass existing user permissions and expand access pathways that were intended to operate outside existing entitlement and audit controls, creating a “backdoor effect.”
The safer approach is to govern MCP using the same entitlement, authentication, and audit mechanisms that already govern dashboards, APIs, queries, and reports. That keeps agent-based access from becoming an exception to the rules. In practice, that requires anchoring MCP inside a centralized application layer that governs how agents interact with enterprise systems, rather than allowing standalone tool servers or orchestration layers to emerge outside the bank’s control environment.
AI works best when it runs on proven infrastructure where data access, entitlements, and auditability are governed from the start rather than retrofitted later. A single permission-aware access point and a single control plane make AI-driven activity much easier to audit, contain, and explain. For regulators and security teams, the goal is not only visibility, but determinism: agent-driven actions must execute within controlled runtimes where every interaction is permitted, logged, and reproducible.
The warning signs are already visible
Banks do not have to wait for a breach or outage to know when MCP governance is slipping. Some of the early warning signs are operational. One is MCP servers appearing outside the organization’s core platform or identity infrastructure. Another is agent-to-agent interaction being enabled without clear restrictions, allowing systems to exchange data in ways that were never intended. Security teams may also see unusual volumes of automated queries or a drop in traffic through traditional application channels, suggesting that AI systems are accessing data and functionality via side channels rather than established ones.
Those signs matter because they point to the same underlying problem, which is interoperability moving faster than centralized control. Even small configuration mistakes can create outsized exposure when agents are chaining actions across multiple services and legacy environments.
What responsible adoption requires
MCP can’t be treated as a one-off integration standard. Responsible adoption rests on four requirements:
Protocol agility: Treat MCP as a plugin rather than a foundation, so governance remains intact as standards shift.
Unified entitlement enforcement: Apply authentication, authorization, and audit trails consistently across every access path, including agent-driven ones.
Virtualized system access: Place a controlled abstraction layer between agents and legacy systems to protect brittle infrastructure from destabilizing integrations.
Security by architecture: Keep executable logic inside a governed runtime, with strict limits on filesystem access, custom script injection, and external library loading in high-security environments.
That same logic extends into the next phase of AI deployment. This is not only about assistants retrieving information more efficiently. It is also about preparing for environments where agents generate workflows, layouts and full applications inside auditable runtimes. Banks that build only for today’s narrow use cases will be underprepared for where this access model is headed next.
The real test for banks
Banks should treat MCP as part of the control environment, not as something separate from it. Any new interface layer needs to fit within durable governance frameworks and align with the same standards for entitlements, auditability, and oversight that already apply elsewhere. That approach gives institutions a clearer path to expand agent-based capabilities while maintaining control.
