How to Govern AI Agents in Financial Services
An AI agent in a financial services workflow does not only generate text: it calls tools, and those tools read customer records, move data between systems, and in some designs initiate actions. That shifts the control question from what the model said to what the agent did, on whose authority, and with what record, and a firm that wants to govern AI agents in financial services has to be able to answer all three for any request months later. Bifrost, the open-source AI gateway written in Go by Maxim AI, is built for regulated enterprises that need those answers enforced on the request path rather than reconstructed after an incident. This post covers the obligations that already apply, the controls that satisfy them, and the deployment posture examiners expect.
The Regulatory Expectations Behind AI Governance in Banking
No US regulator has published an agent-specific rulebook. AI governance in banking is therefore carried by rules that already exist: FINRA supervision and books-and-records obligations, model risk management guidance, EU AI Act transparency duties for firms with European exposure, and the NIST framework most US institutions map their internal controls to.
FINRA Regulatory Notice 24-09 states that existing FINRA rules apply to member firms' use of generative AI and large language models. Supervision, communications with the public, and books-and-records requirements are not suspended because the text was produced by a model. A broker-dealer deploying an agent that drafts client-facing material or touches order data inherits all three obligations on day one.
Interagency model risk management guidance sets expectations for model validation, ongoing monitoring, documentation, and a maintained model inventory. The Federal Reserve issued the revised version as SR 26-2 in April 2026, alongside OCC Bulletin 2026-13, replacing the long-standing SR 11-7 and OCC Bulletin 2011-12; those core expectations carry over. Agentic systems complicate the inventory question directly: one user request can invoke several models across several providers, and the set that actually ran depends on which routing rule matched and whether a fallback chain fired. An inventory built from design documents will not match the models that served production traffic.
Firms with EU exposure also face the EU AI Act. Article 50 transparency obligations for AI-generated content apply from 2 August 2026. Under the Omnibus agreement, which is agreed and pending formal adoption, stand-alone Annex III high-risk obligations move to 2 December 2027 and Annex I embedded high-risk obligations to 2 August 2028. The NIST AI Risk Management Framework organizes AI risk work into four functions (Govern, Map, Measure, and Manage) and is the structure most US firms use to organize internal controls.
Each obligation maps to a specific technical control that produces evidence:
| Obligation | What it expects | Control that produces the evidence |
|---|---|---|
| FINRA Notice 24-09 | Supervision, communications review, and books and records for generative AI use | Per-identity credentials on every AI call, retained request and tool logs, signed administrative audit records |
| Model risk management guidance (SR 26-2, OCC 2026-13) | Model validation, ongoing monitoring, documentation, and a current model inventory | Routing rules that pin workflows to approved models, per-model usage telemetry, recorded fallback events |
| EU AI Act Article 50 (from 2 Aug 2026) | Transparency for AI-generated content and AI interaction | Centralized policy enforcement and configurable content logging at a single egress point |
| NIST AI RMF | Documented controls across Govern, Map, Measure, and Manage | Role-based access, budgets and limits, guardrail profiles, exportable evidence |
The pattern across all four is the same: what satisfies an examiner is a system that applied the policy and kept a record of doing so, which is why AI governance controls increasingly sit in infrastructure rather than in a control document.
Model Risk Management for AI Agents: What Actually Changes
Model risk management for AI agents differs from validating a scoring model in one respect that drives every control decision: the agent takes actions. Validating the underlying model remains necessary but not sufficient, because the risk moved from the prediction to the tool call and the authority behind it.
Five concrete gaps show up in production financial services deployments:
- The tool surface is the real permission boundary. A model constrained by a system prompt is constrained by a suggestion. What an agent can actually do is defined by the tools it can call and the credentials behind them.
- A single request becomes many actions. Agents chain calls, so one prompt from a wealth advisor can produce a dozen reads and writes across CRM, custody, and document systems. Approving the request does not approve the chain.
- Tool credentials accumulate on developer machines. MCP server configurations with production API keys sit in local config files, outside any entitlement review, which is the failure mode the OWASP Top 10 for LLM Applications describes as excessive agency.
- Token spend is non-deterministic. An agent that retries, expands context, or loops through tool results can consume several times its expected budget on a single unusual input.
- The record has to reconstruct a trajectory. Supervision requires the full sequence (prompt, tools offered, tools called, arguments, results, model responses), not the final completion.
None of these are solved by choosing a better model. They are solved at the layer every request and tool call passes through, which is why the MCP gateway pattern has become the control point for agent deployments in regulated firms.
Agent Tool Access Control at the Gateway
Agent tool access control means deciding, per identity and per request, which tools an agent can see and which it can actually execute. Bifrost implements this as layered filtering plus an explicit execution step, so exposure and execution are separate decisions rather than one implicit grant.
- Three stacked filtering levels. Tool filtering applies at the client configuration (
tools_to_execute), at per-request headers, and per virtual key. A tool must pass every applicable filter. An empty list or an omitted list means no tools are available, so the default is deny rather than allow. - Virtual-key-scoped server views. Each virtual key gets its own MCP server view with its own filtered tool set, configured through per-key MCP tool filtering. A wealth-management agent and a claims agent authenticating against the same gateway see different tool catalogs, and a key with no MCP configuration sees nothing.
- Named, reusable tool bundles. MCP Tool Groups in Bifrost Enterprise are curated collections of tools attachable across six dimensions: virtual keys, teams, customers, users, LLM providers, and API keys. Groups resolve at request time from an in-process index, merge and deduplicate when several match, and can be disabled centrally to revoke access without unpicking attachments.
- Execution is a separate call. Tool calls returned by a model are treated as suggestions. Executing a tool requires an explicit call to the execution endpoint, and Agent Mode auto-execution is an opt-in configured per tool. A firm can allow an agent to read positions autonomously while requiring an approval step before anything writes.
- Credentials belong to the gateway, not the laptop. MCP authentication supports none, static headers, OAuth 2.0 with automatic token refresh and PKCE, per-user OAuth, and per-user headers. MCP Sessions let administrators inspect, re-authenticate, edit, and revoke per-user MCP credentials, which is what makes an entitlement review possible.
MCP with federated auth in Bifrost Enterprise turns existing internal APIs into MCP tools without integration glue, and per-user OAuth or per-user headers keep each tool call bound to the individual who made it rather than to a shared service account.
Identity, Entitlement, and Spend for Financial Services AI Compliance
Financial services AI compliance depends on binding every AI call to a real principal. In the Bifrost AI gateway, that principal is a virtual key, and the key carries the model scope, tool scope, budget, and rate limit that apply to its holder.
- Keys bound to identity. Virtual keys are the primary governance entity, holding access permissions, budgets, rate limits, routing behavior, and MCP tool filters for a single consumer.
- Provisioning through the existing IdP. SSO and OIDC with SCIM user provisioning covers Okta, Microsoft Entra, Keycloak, Zitadel, Auth0, Google Workspace, and generic OIDC, so joiners, movers, and leavers flow through the same process as every other entitlement.
- Fine-grained authorization. RBAC with custom roles and Data Access Control determine who can view logs, change policy, or read request content. Access Profiles package provider, model, budget, rate-limit, and MCP policy into reusable templates that allocate virtual keys at scale.
- Hierarchical spend limits. Budgets and rate limits apply at the virtual key, team, and customer levels, alongside model limits, which is the practical answer to non-deterministic agent token consumption.
- Approved-model enforcement. Routing rules pin regulated workflows to specific models, providers, and keys with weighted strategies and fallback chains, so a validated workflow cannot silently drift onto an unapproved model.
The AI Audit Trail for Banks: Evidence and Supervision
An AI audit trail for banks has two distinct halves, and conflating them causes problems during examination. Administrative activity (who changed a policy, a key, or a tool group) is recorded by audit logs. Request-level and tool-level activity (what the agent actually did) comes from request logs, MCP tool logs, and telemetry.
Audit logs in Bifrost Enterprise record administrative changes with the actor, action, resource, and outcome. Entries can be signed with an HMAC key so they can be verified later, retained for a configurable number of days, and filtered in the dashboard by search text, action, outcome, and date range. Matching entries export as JSON, JSON Lines, or Syslog, and can be archived periodically to S3 or GCS in time-windowed, size-bounded JSONL objects for long-term, off-box retention.
Activity evidence comes from the logging and telemetry layer. MCP tool logs record tool calls with call-volume and cost histograms and top tools by call count, which is how a supervisor sees that an agent started calling a document-retrieval tool 40 times per session. Log payloads can be offloaded to S3 or GCS object storage while searchable metadata stays queryable, and OpenTelemetry (OTLP) tracing plus native Prometheus metrics feed the same SIEM and APM stack a firm already runs. These governance and observability capabilities support SOC 2, GDPR, and ISO 27001 programs by producing the retained, exportable evidence those programs require.
Deployment Posture for Regulated Environments
Where the control plane runs matters as much as what it enforces. Bifrost Enterprise supports in-VPC deployments on GCP, AWS, Azure, Cloudflare, and Vercel with network isolation, data sovereignty, and a 99.95% monthly uptime SLA on core components.
For firms that cannot use a managed control plane at all, private container image distribution supports on-premise Kubernetes and Docker. Air-gapped operation is supported by pointing the pricing and model-parameter datasheet URLs at local file:// paths, which removes the dependency on outbound internet access; combined with self-hosted models, that produces a fully offline stack.
Availability determines whether the control actually holds. Clustering with gossip-based synchronization, automatic service discovery, and zero-downtime deployments keeps the policy plane running through upgrades, while circuit breakers and automatic fallbacks handle provider degradation. A control plane that fails open stops being a control.
Common Questions About Governing AI Agents in Financial Services
Do existing financial services rules already cover AI agents?
Yes. FINRA Regulatory Notice 24-09 confirms that existing supervision, communications, and books-and-records rules apply to generative AI use by member firms, and interagency model risk management expectations, revised as SR 26-2 in April 2026, apply regardless of how a model is packaged. The obligations are not new; the evidence they require is harder to produce for a system that takes multi-step actions.
How do you keep an agent from calling a tool it should not?
Filter the tool surface rather than instructing the model. Layered governance controls restrict tools at the client, request, and virtual key levels with deny-by-default when no list is configured, and execution requires an explicit call rather than following automatically from the model's output.
What does an examiner ask for?
Typically three things: which identity made the request, what the system was permitted to do under that identity at that time, and the retained record of what it did. Signed audit entries cover policy and configuration changes, while request logs, MCP tool logs, and traces cover activity.
Start Governing AI Agents in Financial Services
The controls that govern AI agents in financial services are specific and testable: per-identity credentials, a filtered tool surface, explicit execution, enforced budgets, approved-model routing, and a retained record that survives an examination. Bifrost applies all of them on the request path, in your own VPC or on your own hardware.
To see how these controls map to your firm's supervision and model risk management requirements, book a demo with the Bifrost team.