What Is an MCP Gateway?

Most of the writing about the Model Context Protocol is aimed at developers.

• How to build an MCP server?
• How to connect Claude to your database?
• How to write a tool definition?

That's useful content — but it's not the conversation that needs to happen in enterprise IT and security teams right now. Because by the time an IT or security team is formally asked about MCP, something is usually already deployed. Claude Code connecting to internal APIs. Cursor reaching the Jira instance. An agent running an overnight workflow against a system IT wasn't fully aware of.

This piece is for the people who will be asked to govern this infrastructure. Not how to build it — what it is, what it means, and what you're actually responsible for.

Start Here: What MCP Is in One Paragraph

The Model Context Protocol is an open standard, introduced by Anthropic in late 2024 and now adopted across the AI tool industry, that gives AI tools a standardised way to connect to external systems. Before MCP, every AI integration was custom — a specific connector between one tool and one system. MCP makes any AI tool compatible with any system that has an MCP server, the same way HTTP made any browser compatible with any web server.

It's now supported by Claude Code, GitHub Copilot, Cursor, Windsurf, and a growing list of enterprise software vendors.

In practical terms: your employees' AI tools can now connect and query your internal databases, read from your SaaS applications, create records, send messages using Slack or Gmail, and execute workflows — through a single, standardised interface. The AI tools didn't get more powerful in a vacuum. They got connected.

What an MCP Gateway Is

An MCP gateway is the infrastructure layer that sits between employees' AI tools and all the MCP-connected systems in your environment.

Without a gateway, the connection model looks like this: each employee configures their own AI tool to connect directly to each MCP server they want to use. Developer A has six MCP servers in their Claude Code config. Developer B has four different ones. The sales team's Copilot instance is connecting to Salesforce via an MCP server someone in sales ops set up last month. IT has no central record of any of this.

With a gateway, the model is simpler: all MCP traffic routes through one managed endpoint. IT configures which systems are available, who can access them, and what they're allowed to do. Every employee adds a single URL to their AI tool of choice. That's the only configuration they need. The gateway handles everything downstream — auth, policy enforcement, logging.

The cleanest analogy is Okta, but for AI agent access. Okta manages which humans can access which applications. An MCP gateway manages which AI agents — acting on behalf of which employees — can access which systems, and what they're permitted to do there.

That analogy breaks down in one important way: Okta operates at the application level. An MCP gateway operates at the action level. That distinction matters, and it's worth understanding clearly.

Application Access vs. Action Access: Why It's Different

This is the governance gap that IT and security teams need to understand.

When a user authenticates to Salesforce through Okta, your IAM system knows they have access to Salesforce. What it doesn't know — and has no mechanism to control — is what they do once they're in. That's enforced by Salesforce's own permission model, and for humans it's usually fine. A sales rep with CRM access exercises judgment. They don't accidentally export 50,000 records.

AI agents don't exercise judgment in the same way. When an agent acts on behalf of that user through MCP, it can potentially do anything the user can do manually, at machine speed, without the natural hesitation that governs human behaviour.

Here's a real example of why this matters:

A sales engineer connects Salesforce's MCP server to their AI tool and asks it to "prepare context for my top 20 accounts." The agent interprets this broadly. It queries all account records the user has access to — not just 20. It pulls associated contacts, opportunity history, and support tickets. It formats everything into a summary document. Nothing about this is malicious. The agent just doesn't have the same mental model of "appropriate scope" that the human does.

Action-level access control is the answer. Not just "this team can access Salesforce via AI" but "this team can read and update records for accounts in their region, but cannot run bulk queries, export data, or access records outside their assigned segment." This is a materially different kind of access control than what IAM gives you — and it lives in a materially different place.

How the Gateway Works in Practice: Two Scenarios

Scenario A: Developer setting up Claude Code

Without a gateway:

The developer goes to GitHub, generates a personal access token, adds it and the GitHub MCP server URL to their Claude Code config. They're now connected. Claude Code has access to everything that token allows — which, for a senior developer, might include pushing to protected branches and accessing secrets.

With a gateway:

The developer adds one URL — the company gateway — to their Claude Code config and authenticates via SSO. The gateway presents them with the GitHub tools IT has approved for engineers: create PR, review PR, list branches, read file contents. The tools for deleting branches, pushing to main, and accessing secrets aren't shown. They don't exist in this employee's context. The developer gets a better setup experience (no credential management, pre-approved tools) and IT gets actual control over what the agent can do.

Scenario B: Sales team using Copilot with Salesforce

Without a gateway:

Sales ops set up a Salesforce MCP server and sent around instructions. Some reps followed them, some didn't. The ones who did connected Copilot directly to Salesforce with their own OAuth tokens. IT doesn't know which reps are connected. The tools they can call include bulk export, which nobody thought to restrict.

With a gateway:

Sales ops configures the Salesforce connector in the gateway — available to all reps in the "Account Executive" Entra group, with read and update access for records in their region, bulk export and delete disabled. Every rep gets access automatically. Access is governed. When a rep leaves the company, their Entra offboarding disables their gateway access. Salesforce access revoked. No orphaned OAuth tokens.

The Two Roles the Gateway Creates

In practice, an MCP gateway establishes two distinct operational roles.

Manages the gateway at the organisation level:‍

• Decides which MCP servers get registered (the application inventory)
• Sets the outer boundary of what's possible per team (which tools, which actions)
• Configures DLP policies (what happens when a tool response contains a credit card number or SSN)
• Sees the full audit log of everything that flows through the gateway
• Receives alerts when something unusual happens — off-hours access, unauthorised tool attempts, anomalous data volumes
• Manages delegation — which tool-level decisions get handed to team leads vs. managed centrally
  

Interacts with the gateway through whatever AI tool they already use:‍

• Adds one URL to Claude Code, Copilot, or Cursor during onboarding
• Authenticates through SSO — the same login they use everywhere
• Sees exactly the tools they've been granted access to — nothing more, nothing less
• Never configures individual MCP servers
• Never manages credentials for downstream systems
• Just works, through familiar tools, with fewer setup headaches than the alternative
  

The split matters because it creates a governance model that doesn't require IT to be the bottleneck for every decision. IT sets policy. Employees work within it. In many organisations, delegation goes one level further: IT decides which applications are available company-wide, and team managers — sales ops for Salesforce, engineering leads for GitHub — decide the tool-level access within their domain. IT sees everything. They don't make every decision.

Recommended Reading: MCP Security Risks for Enterprises

What the Security Team Is Actually Responsible For

The arrival of MCP creates accountability in four specific areas:

• ‍The application inventory.
  Which systems are reachable through AI agents? This is an asset question — the same category as your API gateway inventory or SaaS application registry. Without a gateway, this question has no good answer. With one, it's the registry the gateway maintains automatically.‍
  ‍
• Permission design.
  What should agents be permitted to do, per system, per team? This is a policy question that intersects with your existing IAM and data governance frameworks. Think of it as extending your access review process — you already review human access to applications annually. You're now designing the equivalent policy for agent access at the action level.‍
  ‍
• The audit trail.
  Agent activity needs to be logged the same way human activity is logged: what tool was called, by whose agent, at what time, what the response contained. This is both an operational monitoring requirement and a compliance artifact. It doesn't exist by default in most environments. A gateway creates it.
  ‍
• ‍Incident response.
  When something unexpected happens — an agent calling a tool it wasn't supposed to reach, an unusual pattern of data access, a tool execution that triggers a DLP alert — IT needs to be able to identify what happened, terminate access if necessary, and trace the activity back to a specific user session. Without central infrastructure, this is extremely slow. With a gateway, it's the same investigation process as any other access event, pulling from the same audit log.

FAQs

Is an MCP gateway the same as an API gateway?

Related concept, different scope. An API gateway manages HTTP-based API traffic — authentication, rate limiting, routing. An MCP gateway manages AI agent tool calls specifically. They speak the MCP protocol, apply AI-specific policy (per-action RBAC, DLP for model context), and integrate with AI tool clients like Claude Code or Copilot. You might run both — the API gateway handles direct integrations, the MCP gateway handles agent-initiated tool calls.

Do we need an MCP gateway if we only have a handful of developers using these tools?

The governance need scales with usage, but the infrastructure investment doesn't vary much. The main risk with low adoption is that it grows fast. Engineering teams adopt MCP tools quickly once a few developers demonstrate the productivity gain. Getting the gateway in place before adoption scales is significantly easier than retrofitting governance after dozens of connections are already established.

How does the gateway affect the employee experience — does it slow things down?

For the employee, a gateway typically improves the setup experience: one URL to configure, SSO authentication instead of per-system credential management, and a curated tool set that IT has approved and tested. Performance-wise, a well-built gateway adds minimal latency since it's mostly handling routing and policy checks. The dynamic tool discovery (responding to model queries about available tools rather than dumping all tools into context) actually improves response speed for agents.

What DLP capabilities should an MCP gateway have?

At minimum: configurable policies per data pattern (credit card, SSN, email, IP addresses), with configurable actions (log, redact, block). The policy should apply bidirectionally — to tool call inputs (what the agent sends to the tool) and tool call outputs (what the tool returns to the agent). Alerts for high-severity patterns (unredacted financial data in a response, PII in an unexpected context) should land in your existing security event workflow, not a separate queue.

How does this connect to our SIEM?

Gateway audit logs should be exportable to your SIEM via standard mechanisms — webhooks, log forwarding, API integration. The log format should be queryable and include: user ID, timestamp, tool name, MCP server, input parameters (sanitised), response summary, and policy decisions (any DLP redactions or blocks applied). This gives your security team the same investigation workflow for agent events as for any other access event.