Model Context Protocol Security for AI Agents in Open Banking Integrations

Why MCP is a security boundary in open banking

Model Context Protocol standardizes how LLM applications connect to external tools and data. MCP servers expose resources, prompts, and tools over a defined message interface, while hosts and clients run the agent. In open banking integrations, that design places parameterized tool execution between an autonomous or semi-autonomous agent and regulated financial APIs.

Open banking access aligned to PSD2-style models depends on strong customer authentication, OAuth 2.0 and OIDC authorization, and consent-bound scopes for account information services (AIS) and payment initiation services (PIS). Financial-grade API (FAPI) profiles further constrain high-risk flows with sender-constrained tokens, stronger client authentication, and hardened authorization patterns. MCP does not replace those controls. It introduces another hop where identity can be collapsed, scopes can widen, tokens can leak into model context, and audit trails can break.

Tool-enabled agents also inherit well-documented LLM application risks: indirect prompt injection, excessive agency, and insecure output handling. Those risks become material when a tool can read balances and PII or initiate payments. For fintech security engineers, the correct framing is not “chatbot with banking plugins.” It is a privileged integration path that must be designed, authorized, and monitored like any other high-assurance API broker.

Reference control architecture

Place an enterprise MCP broker or policy enforcement point between agent hosts and fintech MCP servers. Centralize tool discovery, authentication, scope reduction, token mediation, and logging so individual agent runtimes cannot self-expand capabilities. Enforce network egress so only approved MCP servers can reach open banking base URLs and administrative endpoints.

Keep identities separate for the human user, agent workload, MCP client, MCP server, and downstream open banking API client. Do not reuse a single long-lived bank token across agents or sessions. Prefer just-in-time, user-delegated, consent-bound credentials over standing secrets embedded in MCP server configuration. Token mediation from agent to broker to resource server must preserve sender constraints and must never pass refresh tokens, client secrets, or full account payloads into prompts or logs consumed by the model.

Identity and authentication requirements

Security depends on authenticating and authorizing both the MCP client identity and each tool invocation path. Authenticate client-to-server channels with mutual TLS or equivalent workload identity. Authorize tool registration and invocation with least-privilege roles so a compromised agent cannot register new high-risk tools or call tools outside its approved set.

Downstream open banking clients should remain first-class OAuth or FAPI clients. Agent identity is not a substitute for user consent identity, and MCP server identity is not a substitute for the API client registered with the account-servicing payment service provider. For payment initiation and other high-risk classes, require step-up or human-in-the-loop controls at policy thresholds such as new payee addition or amount limits. Those checks belong outside the model, at the broker or gateway, so prompt content cannot bypass them.

Limiting tool-call scopes to approved AIS and PIS endpoints

Enterprise MCP deployments require explicit allowlisting and scoping of tools rather than unrestricted acceptance of whatever a server offers. Map each MCP tool to a narrow open banking capability, for example read-balances or create-payment-intent, instead of a generic “banking API” proxy. Protection goals differ by class: AIS tools are confidentiality- and consent-sensitive; PIS tools are integrity- and non-repudiation-sensitive.

Constrain tool schemas with explicit endpoint allowlists, hard limits on payment amounts and beneficiaries, read-only defaults for AIS-style tools, and deny-by-default for PIS-style tools. Enforce account, consent, and scope checks on every discrete parameterized invocation at the broker. Treat each call that touches open banking APIs as a privileged action: authenticate, authorize against current consent and OAuth scope, validate normalized parameters, then execute.

Minimize what returns to the model. Strip or tokenize sensitive fields from tool results before they enter the context window. Context windows can retain PII, balances, and payment metadata across later turns, which amplifies data exposure and can influence subsequent high-risk calls after injection or confused-deputy conditions. Scope governance for MCP tools should be reviewed as an extension of open banking consent and OAuth scope governance, with change control when schemas expand.

Logging and provenance for audit and incident response

Open banking operational expectations commonly include API access logging sufficient for incident response, dispute handling, and regulatory investigation. AI-mediated paths are no exception. Auditability depends on correlating agent identity, user or consent identity, tool name and parameters, authorization decision, and downstream API transaction identifiers.

Emit structured logs for every tool call that can reach an open banking API. At minimum include timestamp, agent or application ID, user or consent ID, tool name, normalized parameters, policy decision, MCP session and tool-call IDs, correlation ID, downstream HTTP status, and open banking resource or intent identifiers where FAPI interaction IDs apply. Retain broker and gateway logs for periods consistent with financial fraud, dispute, and regulatory evidence requirements in the operating jurisdiction.

Do not write secrets or full raw account payloads into logs that operators, analytics pipelines, or agents can re-ingest. Provenance is useful only if it is complete, correlated, and protected at the same sensitivity tier as the financial events it describes.

Misconfigurations that expand MCP attack surface

Governance, limitations, and practical next steps

Treat MCP-mediated access as part of existing open banking threat models, fraud and authorized push payment operational controls, and third-party or outsourcing assessments when agents or brokers are external. Require change control for new MCP servers, tool schema updates, and scope expansions. Review periodically which agents may invoke which financial capabilities, exactly as you would review OAuth client scopes and consents.

Some uncertainty remains. MCP is evolving quickly, and there is not yet a single official MCP-fintech security profile. Public MCP-specific vulnerability statistics tied to open banking outages are limited, so current control baselines combine MCP architecture properties with established FAPI, OAuth security practice, and LLM tool-risk frameworks. Logging retention and strong customer authentication obligations also vary by jurisdiction and by whether the integrator acts as ASPSP, AISP, PISP, or technical service provider.

For an immediate engineering backlog:

• Inventory every MCP server and tool that can touch AIS or PIS endpoints.
• Insert a broker or gateway if discovery and authz are still local to agent hosts.
• Split identities and eliminate shared bank tokens.
• Encode deny-by-default tool policies with explicit amount and beneficiary constraints.
• Minimize tool results before model return.
• Verify that every successful and denied call produces correlated, retainable logs.

Those steps make MCP-mediated open banking access reviewable and enforceable without waiting for a specialized protocol profile.