MCP Gateway
The governed control plane between your tools and your AI agents. One Model Context Protocol endpoint for the whole organization. Add integrations once, scope them once, and see every call every agent makes.
GatewayEngineeringWorkplaceGo-to-marketFinanceDataInfrastructure
What is an MCP gateway?
An MCP gateway is a governed control plane between an organization's tools and the AI agents that call them. The Model Context Protocol gave agents a standard way to reach external systems. It did not answer who is allowed to reach which system, under whose credential, or how anyone finds out afterwards.
Without a gateway, every agent client keeps its own copy of every integration. Its own API keys, its own server configuration, its own idea of what it may touch. For a single developer that is friction. For a business it is a governance failure: no shared audit trail, no approval before an agent gets write access to production, and no way to answer a vendor security questionnaire without reading config files by hand.
MCP Gateway replaces that with one endpoint per organization. Integrations are added once. Credentials live in a broker, not on laptops. Each calling principal. A person or an agent. Resolves to exactly the tools its scope allows, and every call is recorded.
The model, in six terms
Integration
An MCP server, API or internal system the gateway can reach. Defined once for the organization.
Connection
A credential for an integration, placed in a scope. The row holds a reference; the secret lives in the broker.
Scope
Where something sits: organization, team, or an individual member or agent. Scopes merge outer to inner.
Policy
Allow, require approval, or block. Attached to an integration or a single connection, optionally per tool.
Toolkit
A named, curated set of tools, served as its own endpoint. Pure curation: a toolkit carries no policy of its own.
Run
One append-only record per call or configuration change. Simultaneously the audit log, the approval record and the usage source.
What the gateway governs
Every control below is enforced in one place, on the call path. There is no second implementation in a console that could drift from what a live call actually resolves.
One endpoint, every client
Point Claude Code, Cursor, ChatGPT and your own agents at the same URL. Each principal sees exactly the tools its scope allows. One connection catalog instead of a config file per laptop.
Policy on every tool
Allow, require approval, or block. Set at organization, team or individual level. An outer block cannot be weakened further in; an inner scope can always tighten.
Approval that means something
A tool marked destructive parks until a named approver decides. Approvals are single-use, time-boxed, and never self-granted. The requester cannot approve their own call.
Agents are principals
An agent identity gets its own scope, its own credential and its own line in every audit record. It never borrows a human's token, so revoking an agent does not revoke a person.
Credentials the gateway holds, not your laptops
Connect an integration once. The credential lives in the broker and is resolved inside the request that needs it. Never stored beside the connection row, never returned to a caller.
The answer to the security questionnaire
Which agents can email customers? Who approved production write access, and when? Both are a report, not an afternoon reading config files.
How it works
Four steps, then it runs itself. Configuration changes are themselves recorded.
Connect
Add an MCP server, API or internal system once. The gateway indexes its tools and holds the credential.
Scope
Place connections at organization, team or individual level. Visibility is the union of every scope a principal holds.
Govern
Set allow, require approval or block per tool. Name who approves what. Tighten inward, never weaken outward.
Observe
Every call writes an append-only record: who, which tool, when, how long, what the policy said.
Before and after a gateway
| Question | Per-client configuration | MCP Gateway |
|---|---|---|
| Where do credentials live? | A copy on every laptop and in every agent config. | One broker. Resolved per call, never returned. |
| Which agents can email customers? | Read every config file and ask around. | An access report, computed by the live resolver. |
| Who approved production write access? | A Slack thread, if anyone remembers. | A named approver on an immutable record. |
| How do you revoke an agent? | Find every place its key was pasted. | Revoke its key. It has its own. |
| What did the agent actually call? | Whatever the client happened to log. | Every call, with policy, latency and outcome. |
| Adding a tool for the whole team? | Change every client, one at a time. | Add it to the toolkit. Every client sees it. |
PREVIEW · This page is unlinked and not indexed while the capability is in build.
MCP Gateway. Frequently asked questions
What is an MCP gateway?
An MCP gateway is a governed control plane that sits between an organization's tools and the AI agents that call them over the Model Context Protocol. Instead of each agent client holding its own credentials and its own idea of what it may touch, every client points at one endpoint. That endpoint resolves who is calling, decides what they are allowed to do, forwards the call, and records it.
Why not just configure MCP servers per agent?
For one developer, per-client configuration is an annoyance. For a business it is a governance failure: no shared audit trail, no approval gate before an agent gets write access to production, and no way to answer “which agents can email customers” without reading every config file by hand. There is also no central kill switch. Revoking access means finding every laptop that has the key.
How does policy resolution work across teams?
Scopes merge outer to inner: organization, then team, then the individual member or agent. Visibility is a union. You see everything placed in any scope you hold. Policy is a deny-union that the outer scope wins: an organization-level block cannot be relaxed by a team or an individual, but either can add a stricter rule the organization never set. Configuration overrides work the other way. Your own credential for a shared integration beats the team default.
Are agent identities separate from user accounts?
Yes, and this is not optional. An agent gets its own principal record, its own scope placement and its own credential. It never executes under a person's token. That means an agent's access can be revoked without touching the human who deployed it, and every audit line names the agent rather than the person it was configured by.
Where are connection credentials stored?
Not in the connection record. That row holds a reference; the credential lives in a separate broker and is resolved inside the single request that needs it. It is never logged, never returned to a caller, and never written into an error message. Rotating a credential is one change in one place, not a sweep across every client that had a copy.
Can the gateway be configured by an agent?
Yes. The admin surface is itself an MCP toolkit, so an operator's own agent can list connections, propose a policy change or pull a usage report conversationally. Write-sensitive actions still route through the same approval chain, and credential issuance is deliberately excluded: an agent that could mint itself a new key would survive revocation of the one it arrived on.
Is MCP Gateway sold separately?
No. It is a capability of the Software Engineering Orchestration Platform, included in the one bundled Platform subscription alongside every other capability. There is no separate MCP Gateway licence to buy.
One platform. One subscription.
MCP Gateway included.
MCP Gateway isn't a product you buy separately. It's one capability of the Software Engineering Orchestration Platform, bundled with every other capability.