Autonomous Security

An MCP gateway your security team governs

An MCP gateway sits between AI agents and the MCP servers they call: one place to decide which servers and tools agents may use, whose account each call runs as, and who called what.

Autonomous MCP Gateway runs your organization's MCP servers in isolated sandboxes instead of on laptops. An administrator adds each server once from a vetted catalog and allows or blocks its tools for everyone. People connect from Claude, ChatGPT or Microsoft 365 Copilot, each signing in with their own account where the app supports it; credentials stay in a token vault, and every connection is audited.

Book a demoStart a free trial →

One app on the gateway

What an administrator sees for one app on a gateway, and the path a call takes: from the AI platform, through the gateway's tool policy, to the MCP server, with the member's own token added only at that moment.

AI platforms

  • Claude
  • ChatGPT
  • Microsoft 365 Copilot
  • Cursor
Each call to the endpoint URL

Acme Gateway

GitHubVerified (github.com)Remote app · each member signs in

Endpoint URL https://<your gateway>/github/mcp

Read-only · 3 tools

  • get_file_contentsAllowed
  • list_issuesAllowed
  • search_codeAllowed

Write / Delete · 3 tools

  • create_issueAllowed
  • merge_pull_requestBlocked
  • delete_fileBlocked

Connected · each as themselves, scopes by their group

  • Dana via Claude · full scopes
  • Omer via ChatGPT · read-only preset
  • Lee via Microsoft 365 Copilot · read-only preset
Allowed calls only, with the member's token

Token vault

Dana's GitHub token, added at the call. The agent never holds it.

GitHub's MCP server

A remote app runs at its provider.

A hosted app runs in an isolated sandbox of its own, one per server.

One app on a gateway: GitHub's MCP server, reached by Claude, ChatGPT, Microsoft 365 Copilot and Cursor at its endpoint URL. Its read-only tools and create_issue are allowed; merge_pull_request and delete_file are blocked for everyone. Three people are connected, each signed in with their own GitHub account, with the scopes their identity-provider group is given. An allowed call goes on to GitHub with that person's token, added from the vault only at that moment.

Why MCP servers need a gateway

MCP is how AI agents reach real systems: it picks the tool, carries the data and makes the call. MCP servers often run on developers' laptops, in containers or in browser clients, outside any provisioning, each holding its own live credentials.

  • Nobody has a list of which servers run, or which of their tools agents call.
  • API keys and tokens sit in config files on laptops, where an agent can read them.
  • A server's code is installed and run before anyone has looked at what it does.
  • Every tool a server offers is open to the agent, the destructive ones included.

A gateway moves those servers to one governed endpoint: provisioned once, vetted before they are offered, and watched every time an agent connects.

MCP servers that stay on laptops are found by the endpoint agent, and can be blocked there. More in Shadow AI.

From MCP Is Where AI Risk Becomes Real

How to use it

  1. Set up a gateway

    One click creates it, named after your organization. Most organizations need one; a second is for a separate set of apps, or the same app under another account.

  2. Add apps and choose their tools

    Add an MCP server from the vetted catalog, or your own as a custom app. Each tool is allowed or blocked for everyone, with read-only and write or delete tools grouped so you can block every write at once.

  3. Share its endpoint URL

    Register the app's URL as a connector in Claude, ChatGPT or Microsoft 365. People reach it from inside the platform, signing in with their own account on apps set up that way, and every session is recorded. About 10 minutes in all.

A vetted catalog

Every hosted app in the catalog is scanned before it is offered: static and dependency analysis of its code, a score out of 10, and the full report one click away. A remote app, one its provider runs, is checked by its provider's domain instead.

  • Verified

    Scanned and verified safe to host, or an official server on its provider's verified domain, which the badge names.

  • Excessive access

    The server may reach or expose more data than its purpose suggests, and the report shows you where.

  • Unverified

    Its source code wasn't found. Not a detected threat, but nobody can review it, and the catalog says so.

Your organization decides which apps can be installed at all: each app allowed or blocked, the rest following a default. A blocked app never appears when someone adds an app. Your own MCP servers join the catalog as custom apps.

Tool policy

An MCP server is a set of tools: read a file, open an issue, delete a branch. The gateway decides, tool by tool, which ones agents may call.

Organization-wide, in the catalog

Each tool is allowed, set to ask for approval, or blocked, with a default for the tools you haven't decided. A dynamic rule acts only on some calls: when an argument matches a pattern, the call is blocked or waits for approval.

On each gateway app

Tools are allowed or blocked, alone or a group at a time: read-only, write or delete, and other. The organization's blocks always win, so no gateway can open a tool the catalog keeps closed.

MCP authentication: sign-in and scopes

The gateway signs agents in to the services behind each app without handing them a credential. OAuth tokens live in a dedicated token vault and are added only when a tool call needs them, so the agent, its prompt and its history never hold the secret.

  • Each member signs in

    A remote app that signs in with OAuth, a server its provider runs, can have everyone connect their own account, so each person gets their own data and permissions.

  • One shared credential

    An administrator provides one API key or connected account that the whole organization uses through the app.

  • One shared instance

    A hosted app runs in its own isolated sandbox on the gateway: one server for everyone, with one set of credentials.

Scopes narrow what a member's sign-in may ask for. Set the most an app can ever request, carve it into presets such as read-only, and map your identity provider's groups to them, so a support team never consents to write access it doesn't need. Narrowing only removes scopes; nothing grants more than the baseline.

Sessions and audit

Every time an AI agent connects to a gateway, the Sessions tab lists it: the client and its version, when it connected and was last active, and the gateway it reached.

  • Each app and gateway keeps its audit events, with the user and status of each, and the servers' own logs.
  • Guardrails scan gateway traffic with the same detectors your endpoints use, watching first or enforcing, so a prompt injection or a leaking secret is caught on its way through the gateway.

Spaces for personal workflows

A gateway is for the tools everyone needs. For a person's own workflow, the MCP Cloud app gives each person a space: their own sandboxed set of MCP servers from the same catalog, at one endpoint.

  • Each server in a space runs in its own isolated sandbox; none can reach another space.
  • Sign-ins go to the same token vault, and the same catalog policy and guardrails apply.
  • Administrators see every space and its owner; sharing a space follows your organization's sharing policy.

Frequently asked questions

What is an MCP gateway?

A single, governed endpoint between AI agents and the MCP servers they use. Instead of each person running servers on their laptop with their own keys, the organization provides them once, decides which tools agents may call, keeps the credentials out of the agents' reach and records every connection.

What is the difference between a hosted and a remote MCP server?

A hosted app is an MCP server we run for you in an isolated sandbox of its own, walled off from your other MCP servers, other spaces and every other customer; with the gateway's tunnel it can also reach private systems on your own network. A remote app already runs elsewhere, usually at its provider; the gateway proxies and governs the connection to it, and an app that signs in with OAuth can have each member sign in with their own account.

Which AI platforms can connect?

Claude, ChatGPT and Microsoft 365 Copilot, through a connector an administrator registers once in the platform's admin console, so members need no setup. Any MCP client, such as Cursor, can connect to an app's endpoint URL directly.

How is an MCP gateway different from an LLM gateway?

An LLM gateway sits between applications and the models they prompt. An MCP gateway sits between agents and the tools they act through. If you already run a LiteLLM proxy, Autonomous checks its requests and answers too: see LLM gateway guardrails.

What about MCP servers people already run on their laptops?

The endpoint agent finds them, with the AI agents that load them, and your policy can block a server or a single tool there too. Finding the AI tools nobody approved is Shadow AI.

Related posts

More on the blog →

Put your MCP servers behind one gateway

See the gateway, the catalog and your agents' sessions on your own organization.

Book a demo