Financial institutions should put a strict authorization layer between the model and the systems it touches. MCP is useful when it delegates only the permissions needed for a specific user, task, and tool, while keeping tokens and credentials out of the language model. The safest pattern is least privilege, tool level scoping, audit trails, and revocation rules that change as the business context changes.
Why MCP Needs a Policy Boundary, Not Just a Connector
MCP becomes risky when it is treated as a direct pipe from a model to real systems. The design goal should be to let the model request an action, while a separate authorization layer decides whether that action is allowed, under which user context, and with what scope. That keeps credentials, tokens, and keys out of the model’s context and makes the control point auditable.
In practice, the model should never be the component that holds durable access. It should operate as a requester that can only reach a tool through a broker, gateway, or policy enforcement layer that can enforce task-level limits, revoke access, and distinguish one session from another.
That distinction matters because MCP is not just a transport pattern. It is an access pattern, and access patterns fail when they collapse authorization, delegation, and credential handling into the same runtime path. Model Context Protocol: Authorization specification is the clearest reference point for keeping OAuth-based authorization and audience-bound tokens on the server side rather than inside the model loop.
How to Keep Credentials Out of the Model Path
The safest implementation separates three things: the user’s authority, the agent’s task, and the credential used to reach the downstream tool. The model can express intent, but the broker must translate that intent into a narrow, time-bounded authorization decision. Where a tool call can be made with delegated access, use short-lived tokens, per-action policy checks, and explicit scoping instead of handing the model a reusable secret.
That means the model should not see API keys, refresh tokens, private certificates, or other secret material unless there is no other viable architecture, and even then the exposure should be tightly bounded and monitored. If a system needs secret material to operate, store and retrieve it in a controlled execution layer, not in prompts, memory, or tool descriptions.
For financial institutions, the key implementation question is not whether MCP can connect to a protected system. It is whether the MCP path can prove that every action is still constrained by business context, approval state, and least privilege. NHIMG’s AI Agent Authorisation Guide is useful here because the same design rule applies: task-scoped access and per-action decisions are safer than broad standing access.
Operationally, this also argues for separate controls around token issuance, token exchange, and revocation. A bank should be able to revoke an agent’s access without changing the model, and it should be able to change policy without redeploying the model. That separation is what makes MCP governable at scale.
What Good Looks Like in a Financial Institution
Good MCP implementation has a narrow trust boundary. The model proposes, the policy layer authorizes, the tool layer executes, and the audit layer records what happened. The institution should be able to answer four questions for every tool call: who asked, what context justified it, what permission was granted, and how the access can be revoked later.
The architecture should also assume that user context changes. A request that is acceptable during one workflow step may become inappropriate after a role change, a session timeout, a fraud signal, or a market-sensitive event. That is why revocation and re-authorization need to be dynamic rather than static. NHIMG’s Zero Trust for AI Agents fits this pattern because it treats every action as a fresh authorization decision rather than a one-time grant.
There is also a governance angle that matters in regulated environments. If a bank cannot show a clear audit trail from user request to tool action to token use, then MCP is being operated too loosely for production use. The safest deployment uses scoped delegation, explicit approvals for sensitive actions, and rapid offboarding when an agent or workflow is retired. NHIMG’s AI Agent Observability, Audit and Incident Response Guide supports that approach because observable action trails and revocation are core controls, not optional extras.
Risk and Threat Considerations
MCP implementations fail when the model is allowed to carry reusable credentials or when a tool gateway blindly trusts whatever the model asks for. That creates a direct path from prompt compromise, tool misuse, or authorization confusion to real system access, which is especially dangerous in financial environments where one overbroad token can reach payment, customer, or trading systems.
Failure mechanism: The model or one of its tools becomes a confused deputy, or a stolen token is reused outside the intended task, because authorization was not separated from request generation and secret handling.
Impact: Attackers or misconfigured workflows can exfiltrate data, trigger unauthorized transactions, or expand access beyond the intended business task, turning a productivity feature into a privilege escalation path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | MCP tool calls need least-privilege scoping to limit what an agent can do. |
| IA-5 — Authenticator Management | The question is about keeping credentials out of the model and controlling their lifecycle. | |
| AU-2 — Event Logging | Banks need audit trails for model-to-tool actions and delegated access decisions. | |
| Recommendation — Enforce least privilege for every MCP tool and token scope. Store, rotate, and revoke credentials outside the model path. Log each MCP authorization decision and tool invocation. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | MCP tool access depends on correctly authenticating and binding tokens to the right actor. |
| API5 — Broken Function Level Authorization | The core risk is letting an agent invoke functions beyond its allowed business role. | |
| Recommendation — Bind MCP tokens to the correct principal and session. Authorize each tool function independently before execution. | ||
Practitioner Guidance
What to verify: Confirm that the model never receives long-lived credentials in prompts, memory, or tool metadata, and that every sensitive tool call is mediated by an external policy decision. If the same secret can be reused across tasks or sessions, the design is too permissive.
Decision rule: If a tool action can affect money movement, customer data, or privileged infrastructure, require task-scoped authorization and separate human or policy approval before execution. If the action is low-risk and reversible, keep the scope narrow but avoid granting the model broad standing access.
Practitioner takeaway: The real control is not “using MCP safely,” but proving that MCP never becomes the place where authority is stored, expanded, or reused.
Related resources from NHI Mgmt Group
- How should security teams implement MCP access for AI agents in Dropbox without exposing regulated data?
- How should security teams implement credential access for browser-based AI agents without exposing secrets to the model?
- How should teams connect an AI agent to an MCP gateway without exposing downstream credentials to the model context?
- How should financial institutions implement AI agents without creating shared-credential security gaps?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
