Enterprise MCP Governance: How to Control, Audit, and Secure MCP Server Access at Scale

Ask your security team how many MCP servers are running across your organization right now. If they can answer with confidence, you are ahead of most enterprises. If they cannot, you have a governance problem that is already in production.

MCP adoption moved fast. Teams connected agents to GitHub, Slack, internal databases, and third-party APIs through MCP servers, often without IT review, without a credential policy, and without any way for the security team to see what those servers could access. The protocol is useful precisely because it makes tool connections easy. That ease is also what makes ungoverned MCP deployments a real security exposure.

MCP servers are not passive APIs. They give AI agents direct, programmatic access to sensitive systems. Those agents act on autonomous reasoning, not reviewed code paths. As one enterprise security leader at Medtronic put it: "MCP opens a lot of opportunities to do a lot of damage very quickly." Gartner projects that 70% of software engineering teams building multimodal applications will use AI gateways by 2028, up from 25% in 2025. The teams building governance now are the ones that will be able to scale safely.

This guide covers what enterprise MCP governance requires, why standard security tools fall short, how to build the four-pillar framework that compliance teams can rely on, and how TrueFoundry implements all of it inside your own cloud.

What Enterprise MCP Governance Requires

Enterprise MCP governance is the complete operational framework for managing which MCP servers exist in your organization, who can access them, what they are permitted to do, and what gets recorded when they are used. It is not a policy document. It is enforced infrastructure.

Most teams underestimate the scope. Governance covers every MCP server in the environment: third-party tools developers connected without IT review, internal tools product teams built and deployed, and MCP servers embedded inside IDE configurations in Cursor, Claude Code, and similar tools. If an MCP server can reach a production system, it is in scope.

MCP governance is also different from standard API governance in a way that matters for how you build it. A REST API call executes a deterministic code path that a developer wrote and reviewed. An MCP tool invocation is an autonomous decision made by an AI agent at runtime based on its reasoning. The threat model, the audit requirements, and the controls needed to maintain accountability are all different. Treating MCP like a conventional API integration is how organizations end up with audit gaps they cannot explain to a regulator.

• Scope: All MCP servers. That includes internal servers built by product teams, servers running in CI/CD pipelines, and anything a developer configured locally in their IDE.

• Mechanism: A centralized gateway between all clients and all MCP servers. The gateway enforces policies. Individual MCP servers do not implement their own access controls, which is what makes this approach scalable across hundreds of servers.

• Outcome: Every tool invocation is authorized against a verified identity and logged in a structured, queryable format that holds up to compliance review and incident investigation.

MCP Security Risks Enterprises Cannot Ignore

MCP servers operate inside the reasoning loop of an AI agent. A traditional API call is triggered deterministically by application code. An MCP tool invocation, by contrast, is triggered when an agent determines at runtime that a tool is appropriate for a given task. That decision is influenced by model reasoning rather than explicitly defined control flow, which reduces the visibility that developers typically have into how and why a tool is invoked. In this model, reasoning effectively becomes part of the control path, yet it is not directly observable through standard application security tooling.

Security researchers have documented this in production. Prompt injection attacks delivered through MCP tool descriptions redirect agent behavior without touching a line of code. Credential exposure through poorly configured MCP servers creates access paths that perimeter controls were never designed to monitor. These are not theoretical attack scenarios from research papers. They are documented incidents from real enterprise deployments.

Shadow MCP Server Deployments Can Bypass Standard Access Control

When developers deploy or connect to MCP servers without IT review, they skip every control that normally applies to a new system integration: vendor security assessment, data access classification, and access provisioning workflows. The server enters production with none of the documentation, monitoring, or restrictions that every other enterprise system carries.

Without a central registry, basic security questions have no reliable answers. Which MCP servers are running? What credentials do they hold? Which databases can they query? Which external services can they call? That invisibility keeps these servers out of vulnerability assessments, vendor risk reviews, and penetration testing scope entirely.

A single unapproved MCP server with read access to an internal CRM or code repository is an unaudited data path that perimeter controls will not catch. The traffic originates from inside the network, from a developer machine that is supposed to be there.

Tool Description Poisoning Bypasses Network-Layer Defenses

When an agent connects to an MCP server and calls tools/list, the server responds with tool names, descriptions, and parameter schemas. The agent uses that metadata to decide which tools to invoke and how to call them. Manipulate that metadata and you redirect the agent's behavior without exploiting any code vulnerability.

Tool description poisoning embeds malicious instructions inside tool metadata that cause the agent to take unintended actions: exfiltrating data, invoking tools outside its intended scope, or bypassing safety checks while appearing to execute its assigned task. The malicious content travels inside the HTTP response body from the MCP server, specifically within the tools/list payload. Standard web application firewalls and API security tools do have visibility into HTTP response bodies, but they cannot catch this attack because the malicious content is semantically embedded natural language, not a syntactic anomaly like a known exploit signature or a malformed header. The attack succeeds at the reasoning layer, where the agent interprets tool descriptions as legitimate instructions and acts on them.

TrueFoundry's MCP Pre Tool guardrails inspect tool parameters and call arguments before execution using model-based Prompt Injection detection. If tool call arguments contain redirected instructions, execution is blocked before the tool runs and the detection is logged in the request trace.

Shared MCP Server Credentials Eliminate Compliance Accountability

MCP servers using shared API keys or service account tokens cannot produce the attributable audit records that compliance frameworks require. If ten agents share one credential set, there is no way to link a specific tool call to a specific user, agent instance, or team. In a regulated environment that gap is not an inconvenience. It is a direct compliance failure.

HIPAA requires audit trails attributable to an identifiable user or service for every access to protected health information. SOC2 CC6 requires access controls with evidence of enforcement. GDPR's accountability principle requires organizations to demonstrate that data processing was authorized and documented. Shared-credential MCP deployments cannot satisfy any of these. TrueFoundry replaces shared credentials with Personal Access Tokens tied to individual users and Virtual Account Tokens for application-level access, so every tool call carries a verifiable identity.

The Four Pillars of Enterprise MCP Governance

A complete enterprise MCP governance framework requires four capabilities that work together: a centralized catalog, identity-based access controls, structured audit logging, and real-time policy enforcement. Each depends on the others. You cannot enforce access policies before you know what servers exist. You cannot build an audit trail without identity attribution. And post-hoc audit logs without real-time enforcement are forensic records, not security controls.

Four Pillars: Core Function, TrueFoundry Implementation, and Compliance Coverage

Pillar 1: A Centralized MCP Server Catalog

The catalog is the authoritative registry of every approved MCP server in your organization. Each entry carries the information security teams need to assess risk: server name, owner team, data access scope, authentication method, approval status, connection parameters, and any usage restrictions such as approved user groups or rate limits.

New servers enter through a vetting workflow. Tool description review screens for poisoning risks before the server reaches developer environments. Data access assessment determines what the server can reach. An explicit approval sign-off gates distribution. None of this requires changes to the MCP server itself. It happens at the catalog layer, and individual server implementations stay untouched.

The catalog also handles distribution. Developers pull pre-approved server configurations directly into their IDE integrations rather than configuring servers manually. Only catalog-approved servers reach developer machines. TrueFoundry's Virtual MCP Server feature extends this: platform teams compose curated subsets of tools from multiple registered servers, exposing only what a specific team or use case requires, without deploying new infrastructure.

Pillar 2: SSO and MCP Server Access Control at the Gateway Layer

MCP access needs to go through the same identity provider that governs everything else in the organization. TrueFoundry supports OAuth2 two-legged and three-legged flows, SAML 2.0, and direct integration with Okta, Azure Active Directory, Auth0, Cognito, and any JWKS-compatible IdP. MCP access is provisioned and deprovisioned through the same onboarding and offboarding workflows that cover email, repositories, and cloud consoles. When a developer leaves, MCP access goes with them automatically.

The gateway supports three inbound authentication methods depending on who is calling. Personal Access Tokens (PATs) are generated from Settings > API Keys in the TrueFoundry UI, tied to individual users, and are the standard choice for development workflows. Virtual Account Tokens (VATs) are service accounts with defined permissions, appropriate for production agents and server-to-server workflows. External IdP tokens allow users without TrueFoundry accounts to authenticate using their own identity provider, covering B2B SaaS and customer-facing agent deployments.

For outbound authentication to downstream MCP servers, TrueFoundry manages the full credential lifecycle across six patterns. OAuth Authorization Code flows handle per-user access to services like GitHub and Slack, with the gateway managing consent, token storage, and automatic refresh. OAuth Client Credentials flows handle server-to-server access. Shared and individual API key modes cover simpler cases where the gateway injects the right credential per request. Token Passthrough forwards the inbound token unchanged when the MCP server can validate it directly. Token Forwarding via the x-tfy-mcp-headers header handles scenarios where the MCP server uses a separate credential system.

MCP Server Access Control: Authentication Patterns Across Common Enterprise Scenarios

RBAC policies determine which teams or individuals can invoke which servers and tools. These policies live at the gateway, not within individual MCP servers, so a policy update takes effect across all clients immediately without server redeployment. A data science team gets access to analytics tools but not deployment servers. A security team gets read-only access to all servers for audit purposes.

Pillar 3: Structured Audit Logging Tied to Every Tool Call

Every MCP tool call needs a log entry that captures the full invocation context: timestamp, caller identity, MCP server identifier, tool name, input parameters, response summary, policy decision with reason, guardrail results per hook showing execution time and findings, and total latency. These fields need to be structured JSON so that SIEM systems and compliance reporting tools can query them.

TrueFoundry controls logging at two levels. At the request level, the X-TFY-LOGGING-CONFIG header with enabled: true captures the full request. At the gateway level on self-hosted deployments, the REQUEST_LOGGING_MODE environment variable sets global behavior: ALWAYS logs every request regardless of headers, which is the right setting for regulated production environments. HEADER_CONTROLLED defers to per-request settings. NEVER suppresses all logging for environments where that is appropriate.

Request logs are visible in the TrueFoundry UI under AI Gateway > Monitor > Requests. Individual guardrail execution spans appear in AI Gateway > Monitor > Request Traces, showing which guardrails ran on which hook, pass/fail status, execution time, and mutations applied. For organizations routing logs to their own infrastructure, TrueFoundry exports via OpenTelemetry to Grafana, Datadog, Splunk, and any OTLP-compatible destination. On self-hosted deployments, log data is written to your own AWS S3, GCS, or Azure Blob storage in Parquet format, queryable via Spark, DuckDB, or Athena.

HIPAA requires the retention of security-related documentation for six years. In practice, audit logs are often retained for a similar duration to support compliance and incident investigation. Many financial records follow a seven-year retention standard. Logs must be tamper-evident, with access controls that prevent modification by the teams that generate them. TrueFoundry’s self-hosted deployment options keep all log data within the customer’s cloud account, supporting both retention and tamper-evidence requirements.

Pillar 4: Real-Time MCP Policy Enforcement Before the Tool Runs

Logging what happened is not the same as preventing it. Policy enforcement needs to act at invocation time, before the tool call reaches the MCP server, so unauthorized access is blocked rather than documented after the fact.

TrueFoundry's guardrail system implements two hooks per tool call. MCP Pre Tool guardrails run before the tool executes. If any of them fail, the tool never runs, avoiding the cost, side effects, and data exposure of a bad call entirely. Built-in pre-tool guardrails include: SQL Sanitizer, catching DROP, TRUNCATE, DELETE and UPDATE without WHERE, and string interpolation patterns indicating injection risk; Prompt Injection detection using model-based analysis for jailbreak and injection attempts in tool call parameters; Secrets Detection catching API keys, AWS credentials, JWT tokens, and private keys before they reach backend services; and Cedar and OPA policy guardrails for declarative, fine-grained access control down to specific tool arguments.

MCP Post Tool guardrails run after the tool returns, before the result reaches the agent. Built-in post-tool guardrails include Code Safety Linter, flagging eval, exec, os.system, subprocess calls, and dangerous shell commands in tool output; PII Detection, finding and redacting personal information with configurable entity categories; and Regex Pattern Matching for custom patterns covering payment cards, internal identifiers, and domain-specific sensitive data. External providers including AWS Bedrock Guardrail, Azure Content Safety, Azure Prompt Shield, CrowdStrike, and Google Model Armor all integrate through the same hook system.

Enforcement strategies are configurable per guardrail. Enforce blocks on violation and on guardrail error. Enforce But Ignore On Error blocks on violation but lets requests through if the guardrail provider is unavailable, which is the recommended default for production. Audit logs violations without blocking, the right mode during initial rollout. The recommended sequence is Audit first, then Enforce But Ignore On Error, then full Enforce as confidence grows.

Deploying an Enterprise MCP Gateway: A Four-Step Implementation Plan

MCP governance is a sequenced program. Each step builds on the last. You cannot enforce access policies before you know what servers exist. You cannot build a meaningful audit trail before identity attribution is in place.

Step 1: Inventory All Existing MCP Deployments

Start with a full audit of every running MCP server across developer environments, CI/CD pipelines, production agent deployments, and IDE configurations. This includes servers developers configured locally in Cursor or Claude Code without IT involvement. Combining automated scanning of cloud environments with a self-reporting process for local developer configurations gives the most complete picture for large organizations.

Record for each server: name and purpose, owner team, data access scope, authentication method if any, and how long it has been running. The goal is an accurate picture of what exists before governance was in place, not a curated list of things already approved.

Step 2: Build the Approved MCP Server Catalog

Before migrating any servers, define the metadata schema and approval workflow. Key decisions: who has approval authority for different risk tiers, what the review checklist covers, and what findings block catalog registration. Establish these criteria before categorizing servers so they apply consistently.

Work through the inventory and categorize each server as approved for catalog, pending review, or blocked pending remediation. Set a hard date by which all production servers must be catalog-registered and communicate clearly that uncatalogued servers will be blocked at the gateway after that date. The deadline creates the urgency that gets teams to engage.

Step 3: Deploy the MCP Gateway and Enforce SSO

Route all MCP traffic through the gateway before enforcing blocking policies. Start with REQUEST_LOGGING_MODE set to ALWAYS. All traffic passes through, all invocations are recorded, nothing is blocked yet. Running in this mode for two to four weeks gives you a baseline of real traffic patterns before enforcement begins.

Integrate the gateway with your enterprise IdP through Access > External Auth > Identity Provider in the TrueFoundry UI. For Okta using the default authorization server, the JWKS URI is https://your-org.okta.com/oauth2/v1/keys. Organizations using a custom Okta authorization server should use https://your-org.okta.com/oauth2/{authServerId}/v1/keys instead. For Azure AD, it is https://login.microsoftonline.com/your-tenant-id/discovery/v2.0/keys, with tenant ID and client ID configured as issuer and audience. Verify that every invocation in the audit log shows a specific user or agent identity before moving to enforcement. Shared service account identities in the logs mean identity attribution is incomplete.

Step 4: Enable Enforcement and Configure Alerting

After the baseline period, enable policy enforcement: block uncatalogued MCP servers, activate RBAC policies, and apply rate limits. Communicate the enforcement date to developer teams with enough lead time to fast-track legitimate tools through catalog registration.

Set up alerting on the exported OpenTelemetry data for anomalous patterns: unusual call volumes from a single agent identity, access to high-sensitivity tools outside approved hours, policy violations from identities that should not have MCP access. The guardrail results in AI Gateway > Monitor > Request Traces give you the detail needed to tune thresholds over time. Review alert rules quarterly as your MCP deployment grows.

MCP Security Enterprise Requirements by Industry

Three requirements appear consistently across all regulated environments: attributable access records linked to verified identities, data residency controls keeping sensitive data within defined boundaries, and vendor risk documentation for the governance infrastructure itself.

• Healthcare (HIPAA): Any MCP server that can receive protected health information in parameters or responses requires a VPC-isolated gateway. Tool invocations involving PHI need logs with patient identifiers replaced by reference tokens, and access must be provisioned through clinical identity management. TrueFoundry's self-hosted deployment on AWS GovCloud supports HIPAA-aligned workloads. Innovaccer processes approximately 17 million clinical AI inference requests per month entirely within their AWS GovCloud boundary using TrueFoundry, with OpenTelemetry feeding Grafana dashboards and no sensitive data leaving their cloud perimeter.

• Financial Services (SOC2, FINRA): MCP governance infrastructure is in scope for SOC2 Type II audits if it handles financial data or has access to systems of record. Controls required include encryption in transit and at rest, quarterly access reviews with documented evidence, and incident response procedures covering MCP-specific failure modes. TrueFoundry holds SOC2 Type II certification and exports structured MCP audit logs in the format auditors require to produce CC6 control evidence.

• Insurance and Global Enterprises (GDPR, Data Residency): GDPR-covered organizations must maintain a Record of Processing Activities under Article 30 that covers AI-assisted processing, including MCP tool invocations. This record is a structured compliance document describing processing purposes, data categories, transfers, and safeguards. MCP gateway audit logs provide the underlying event data that feeds this record, but the RoPA itself must be maintained separately by the organization's data protection function. Gateway logs also need to capture sufficient metadata to support data subject access requests and to document any cross-border transfers that occur through tool invocations. Data residency requirements may prohibit MCP traffic from leaving specific geographic regions, requiring regional gateway deployments.

How TrueFoundry Delivers Enterprise MCP Governance

TrueFoundry's MCP Gateway delivers all four governance pillars from a single control plane deployed inside the customer's own cloud account. Platform teams manage the complete governance stack through one interface without modifying individual MCP server implementations. No MCP traffic leaves the enterprise perimeter.

Enterprises including NVIDIA, Zscaler, Siemens Healthineers, and Automation Anywhere use TrueFoundry to move from ad-hoc MCP deployments to controlled, governed environments. For enterprises running AI agent workloads at scale, TrueFoundry's policy-enforced cost controls, budget limits, and caching layer have delivered material reductions in monthly inference and tool invocation spend. Contact TrueFoundry for case-specific figures based on your actual invocation volume and model mix.

• Centralized MCP catalog with vetting workflow: The TrueFoundry control plane maintains the authoritative registry of approved MCP servers with metadata, approval status, and connection parameters. New servers enter through a vetting process that includes tool description review for poisoning risks before distribution to developer IDE configurations. The Virtual MCP Server feature lets platform teams compose curated tool subsets from multiple registered servers, exposing only what a specific team needs without deploying new infrastructure.

• OAuth2 and RBAC on every tool call: Every MCP invocation is authenticated via OAuth2 with the caller's enterprise identity. The gateway handles all six outbound authentication patterns and manages the full token lifecycle for Authorization Code flows, Client Credentials flows, and API key injection. RBAC policies enforced at the gateway apply immediately across all clients when updated, with no server redeployment required.

• Configurable metadata policies per invocation: TrueFoundry applies data masking via PII Detection and Regex guardrails, rate limits per team, cost caps per agent session, and blocking rules for restricted tool categories via Cedar or OPA policies. All configured in the management interface. No changes to MCP server code required.

• Audit logs streamed to your SIEM: Structured JSON audit logs for every MCP invocation export via OpenTelemetry to Grafana, Datadog, Splunk, or any OTLP-compatible destination. On self-hosted deployments, logs are written to your own AWS S3, GCS, or Azure Blob storage in Parquet format, queryable via Spark, DuckDB, or Athena. REQUEST_LOGGING_MODE: ALWAYS ensures complete capture for regulated environments.

• VPC-isolated deployment with four options: Fully managed SaaS with no infrastructure overhead; SaaS gateway with customer-owned data storage; self-hosted gateway plane with TrueFoundry control plane at approximately $600 per month in infrastructure cost; full self-hosted control plane plus gateway at approximately $800 to $1,000 per month. The last two options ensure that no MCP invocation traffic leaves your perimeter to reach TrueFoundry infrastructure.

‍