MCP Gateway for Regulated Industries: A Control Guide

An AI agent that calls an internal MCP server reads and writes production records: patient charts, claims files, account ledgers, case management entries. In banking, healthcare, insurance, defense, and public sector environments, that traffic carries obligations a direct model-to-tool connection cannot satisfy, which is why an MCP gateway for regulated industries is now a deployment prerequisite rather than an optimization. Bifrost, the open-source MCP gateway written in Go by Maxim AI, sits between agents and MCP servers as the single place where network egress, tool authorization, credential custody, and audit capture are enforced. This post covers the deployment and control mechanics: offline installation, three stacked levels of tool filtering, and the records a review board will ask to see.

What Breaks When MCP Is Adopted Without a Gateway

Direct MCP adoption inside a regulated network fails in five specific ways: outbound egress to third-party MCP endpoints, credentials distributed onto engineer laptops, no per-tool authorization, no reconstructable trail of invocations, and unbounded spend. Each becomes an audit finding, and none is solved by the MCP client on a developer machine.

• Uncontrolled egress. A remote MCP server configured in a desktop client opens an outbound connection from inside the network to a vendor endpoint, carrying record identifiers and query fragments drawn from regulated systems.
• Credentials on endpoints. Connecting an MCP server usually means placing a bearer token or OAuth client secret in a local config file. Every engineer who connects then holds a credential to the underlying system.
• All-or-nothing tool access. An MCP server exposes its full tool list to whichever client connects. A server offering search_records also offers delete_record, and the protocol has no concept of granting one and withholding the other per consumer.
• No reconstructable trail. Tool execution happens between the client process and the MCP server, with no central record correlating an invocation to an identity, a tool name, arguments, and an outcome.
• Unbounded spend. Tool definitions inflate every prompt, and agent loops repeat that cost per turn with no per-team ceiling.

Routing MCP traffic through a gateway converts all five into configuration. The MCP gateway becomes the network boundary, the credential store, the authorization point, and the log source at once. That centralization is what the Govern function of the NIST AI Risk Management Framework assumes: a control living in a config file on 200 laptops cannot be governed at all.

Air-Gapped MCP Deployment and the On-Premise AI Gateway

An air-gapped MCP deployment runs the gateway, the MCP servers, and the model backends inside a network with no outbound internet route. Bifrost supports this because its routine external dependency, the pricing and model-parameter datasheets, can be read from the local filesystem instead of fetched over the network.

Bifrost normally retrieves those datasheets from getbifrost.ai on startup and periodically in the background, and in an isolated environment those fetches fail. Download the two files once on a connected machine, transfer them (or bake them into the container image or a Kubernetes volume), and point Bifrost at local file:// paths in config.json:

{
  "framework": {
    "pricing": {
      "pricing_url": "file:///opt/bifrost/pricing.json",
      "model_parameters_url": "file:///opt/bifrost/model-parameters.json",
      "pricing_sync_interval": 86400
    }
  }
}

Bifrost re-reads those files on every sync tick, governed by pricing_sync_interval (minimum 3600 seconds), so refreshing the datasheets is a file drop rather than a restart; the air-gapped deployment guide has the full procedure.

Pair that with the rest of the offline stack to get an on-premise AI gateway with no outbound dependency:

• Private image distribution. Enterprise container images are distributed through AWS ECR and GCP Artifact Registry, with on-premise Kubernetes and Docker deployment for clusters that cannot use cloud-native identity federation.
• Self-hosted model backends. Ollama, vLLM, and SGLang run inference inside the same network, so no prompt or tool result leaves it.
• Internal MCP servers only. The gateway connects outward over STDIO, HTTP, or SSE with automatic exponential-backoff retry, and in an air-gapped build those targets are all internal services.

Where full isolation is not required, the same controls apply to in-VPC installations across GCP, AWS, Azure, Cloudflare, and Vercel, with network isolation, data sovereignty, and a 99.95% monthly uptime SLA on core components. Bifrost Enterprise covers those topologies and the accompanying support terms.

Tool-Level Access Control at the MCP Gateway

Tool-level access control in Bifrost is enforced by three stacked filters that a tool must pass before it is exposed to a model. An omitted or empty list means no tools, so the default posture is deny-by-default rather than allow-everything.

• Client configuration. Each MCP client config carries tools_to_execute, the baseline set. ["*"] exposes everything from that server, [] or an omitted field exposes nothing, and a named list exposes exactly those tools.
• Per-request headers. x-bf-mcp-include-clients and x-bf-mcp-include-tools narrow the set for a single request, supporting clientName-toolName and clientName-* patterns.
• Per-virtual-key configuration. Each virtual key carries its own MCP client configuration and takes precedence over request headers. A key with no MCP configuration gets no tools.

The levels intersect, so the available set is what the client config, the request filter, and the virtual key all allow. The tool filtering model also drives what external MCP clients see: when Bifrost is exposed as an MCP server, each virtual key gets its own scoped server view, with clients authenticating via x-bf-vk, Authorization: Bearer vk_..., or X-Api-Key. Two teams pointing Claude Desktop at the same gateway URL receive different tool catalogs.

Virtual keys carry budgets, rate limits, routing rules, and MCP tool scope together, closing the spend gap alongside the access gap. For larger estates, Enterprise MCP Tool Groups define reusable bundles of tools drawn from one or more MCP servers and attach them across six dimensions: virtual keys, teams, customers, users, LLM providers, and API keys. Tool Groups resolve at request time from an in-process index rather than extra database lookups, matching groups merge and deduplicate, and a master enable/disable switch revokes access without deleting attachments.

Execution is separated from suggestion by default. Bifrost does not auto-execute tool calls returned by a model; running one requires an explicit call to POST /v1/mcp/tool/execute. That gap is where an approval workflow, an argument validator, or a four-eyes check belongs. Agent Mode, which performs autonomous multi-step execution with per-tool auto-approval, is an explicit opt-in.

Credentials belong at the gateway, not on endpoints. MCP authentication supports five types:

Per-user credentials are stored against an identity (virtual key, signed-in SSO user, or session ID) and surface on the MCP Sessions page, where an administrator can inspect status, re-authenticate a stale token, edit header values, or revoke a credential. Removing a virtual key's access to an MCP server automatically orphans the matching credentials.

MCP Audit Trail: Reconstructing Who Invoked Which Tool

An MCP audit trail comes from two record sets that answer different questions. Audit logs record administrative activity: who changed what configuration, when, and against which resource. Request and MCP tool logs record runtime traffic, meaning which invocations actually ran. A review board asks for both.

Audit logs in Bifrost Enterprise capture the administrative side with the properties compliance teams check for:

• Signed entries. Configure an HMAC key (minimum 32 bytes) so audit events can be verified rather than trusted.
• Configurable retention. retention_days controls how long entries are kept in the database; 365 is a common setting.
• Dashboard filtering. Filter by search text, action, outcome, and date range, across initiator, target, path, IP, and duration columns.
• Export. Users with download permission export the filtered result set as JSON, JSON Lines, or Syslog (RFC 5424) for SIEM ingestion.
• Object storage archival. A background job periodically copies audit events to S3 or GCS in time-windowed, size-bounded JSONL objects for retention that outlives the database.

The HHS HIPAA Security Rule requires covered entities to implement audit controls that record and examine activity in systems handling electronic protected health information. Signed, exportable, archived administrative records support that control alongside the runtime view.

For the runtime side, Bifrost keeps MCP tool logs next to LLM request logs, with tool-call volume histograms, cost histograms, and top tools by call count. Payloads can be offloaded through log exports so the logs database keeps searchable metadata while request and response bodies live in S3 or GCS under your own lifecycle rules. Native OpenTelemetry tracing and Prometheus metrics feed the same traffic into Grafana, Datadog, or an existing observability stack.

MCP Gateway Compliance Checklist for a Review Board

Take this checklist to an internal architecture or risk review. Each item maps to a control an assessor can test rather than a policy statement, and together they describe what an MCP gateway for regulated industries has to make demonstrable before an agent touches a production record.

• Egress. All MCP traffic terminates at the gateway; no workstation connects directly to an external MCP endpoint.
• Deployment mode. Air-gapped, on-premise, or in-VPC, with datasheets loaded from local file:// paths and models served by self-hosted backends where isolation is required.
• Tool authorization. Deny-by-default at the client, request, and virtual-key levels, with named allowlists rather than wildcards on any server that can write.
• Execution boundary. Tool calls treated as suggestions by default; Agent Mode auto-approval enabled only for tools that have been reviewed individually.
• Credential custody. Zero MCP credentials on endpoints; per-user OAuth or per-user headers held at the gateway with a documented revocation path.
• Identity and roles. SSO/OIDC with SCIM provisioning, fine-grained RBAC and access profiles, and data access control scoping what each operator sees.
• Audit. HMAC-signed entries, defined retention, and archival to a write-once bucket, with an export path into the SIEM your security team already runs.
• Spend. Hierarchical budgets and rate limits at virtual key, team, and customer level.

These controls support SOC 2, HIPAA, GDPR, and ISO 27001 programs, and they line up with the management-system expectations described in ISO/IEC 42001. They are controls you operate, not certifications the gateway holds.

Questions Regulated Teams Ask Before Approval

Can an MCP gateway run fully offline?

Yes. Point pricing_url and model_parameters_url at local file:// paths, pull the image from your private registry, connect only internal MCP servers, and serve models from Ollama, vLLM, or SGLang inside the network. Nothing in that stack needs an outbound route.

How do you prove which tool an agent called?

Through the runtime record rather than the administrative one. MCP tool logs on the MCP gateway capture invocations alongside LLM requests, with OpenTelemetry traces and payload offload to object storage for retention. Audit logs cover the separate question of who changed the configuration those invocations ran under.

Where should MCP server credentials live?

At the gateway. Server-level headers and OAuth credentials sit in the MCP client config, encrypted at rest; per-user credentials are keyed to an identity and managed from the MCP Sessions page. No engineer needs a laptop copy, and revocation is a single action.

Deploying an MCP Gateway for Regulated Industries

An MCP gateway for regulated industries is defined by what it makes provable: where traffic goes, which tools each consumer can reach, whose credential was used, and what a reviewer can reconstruct afterward. Bifrost implements those four properties as deployment configuration rather than process documentation, across air-gapped, on-premise, and in-VPC installations. To walk through a topology and control model against your own regulatory scope, book a demo with the Bifrost team.