An MCP gateway is a control point between AI assistants or agents and the tools they can call. It publishes selected tools, checks each request against policy before it runs, keeps service credentials away from the caller and records the outcome. For a security team, an MCP gateway is what separates letting an AI read your stack from letting it act on it.
- An MCP gateway decides which tools an AI client can discover and which calls it may execute, and those are two separate decisions.
- Before a tool runs, a gateway should validate the input schema, authorize the caller's roles, apply a rate policy and check whether the risk level requires human approval.
- The safe way to start is one low-risk workflow, such as gathering alert context, with the execution record reviewed before any action with greater impact is added.
What is an MCP gateway?
An MCP gateway is the layer that governs how AI clients use tools over the Model Context Protocol. MCP gives AI systems a structured way to discover and call tools (modelcontextprotocol.io). The protocol describes how a client and a server talk; it does not decide what a given AI in your SOC should be allowed to do.
That decision is what the gateway adds. Instead of every assistant or agent connecting directly to every tool with its own credentials, AI clients authenticate to the MCP gateway. The gateway exposes a curated set of published tools, evaluates each call against policy and returns the result to the caller. Each tool comes with a clear contract: a name such as search_alerts, an input schema that says which fields the AI must provide, and a risk level.
Why does AI agent security need a control point?
AI agent security is mostly about actions, not answers. An agent that summarizes an alert badly costs an analyst some time; an agent that isolates the wrong host or disables the wrong account has an operational impact. Once AI workflows can call security tools, the question shifts from what the model knows to what the model is permitted to execute.
Without a gateway, three problems tend to appear together. Service credentials get copied into each AI client that needs tool access. Permission to connect quietly becomes permission to run any exposed action. And when something goes wrong, the team has to reconstruct what happened from the AI's own description of its work. An MCP gateway addresses all three in one place: credentials stay behind the gateway, execution is checked separately from discovery, and every outcome is recorded.
What should an MCP gateway check before a tool runs?
An MCP gateway should run a fixed set of checks on every call before the tool executes. We use the following checklist when we describe execution policy for a published tool:
- Input schema: validate that the request contains the fields the tool expects, in the expected form.
- Caller roles: authorize the caller against the roles allowed to execute this specific tool.
- Rate policy: limit request volume per tool, so a looping agent cannot flood a connected service.
- Risk and approval: decide whether the call can run now or must wait for a human to approve it.
- Outcome record: log the tool, the caller, the status and the duration, including denials and pending approvals.
The result of those checks is one of three outcomes. An allowed call reaches the tool and returns its result. A denied call stops. A call that needs approval waits, and the action has not executed until someone approves it.
Does your security team need an MCP gateway?
Your security team needs an MCP gateway as soon as AI assistants or agents call tools that touch your environment, and especially when any of those tools can change something. If no AI workflow calls tools yet, the gateway can wait; the more urgent work is knowing which AI is already in use. These signals tell us a gateway is due:
- More than one AI assistant or agent wants access to the same security tools.
- The tools include actions with impact, such as isolating a host, and not just searches.
- The alternative is handing service credentials to each AI client separately.
- You need to explain afterward what an agent ran, what was denied and what is waiting for approval.
- You already run an MCP server and want its tools available to governed AI workflows rather than to whoever connects.
How Imperum MCP Gateway works
Imperum MCP Gateway is the MCP gateway in the Imperum Autonomous SOC: it connects AI assistants and agents to security tools, applies execution policies and records outcomes, while Imperum manages the connected services' credentials. It covers four steps.
Publish selected tools
Administrators discover actions from deployed connectors, Imperum's platform tools and AI services, choose what to publish and inspect each tool's input schema. They set risk, approval and rate policies around that capability, so the team can reuse existing integrations without giving each AI client its own service credentials. Publishing and changing tools requires administrator permission, and the available capabilities depend on your deployment and connected services.
Apply execution policy
Before execution, the gateway checks the tool's inputs, the caller's roles, the rate policy and the approval requirement. Role restrictions define which roles may execute a tool; an empty role list leaves the tool unrestricted by role, and administrators retain access. Rate policies apply per tenant, tool and caller. High and critical risk tools require approval by default, and deployed agents can use an administrator-configured auto-approval policy within its allowed risk level.
Work as server and as client
Imperum works on both sides of the MCP connection. As the server, it lets an authenticated external MCP client request published Imperum and connector tools, with execution following the gateway's policies. As the client, it lets configured Imperum AI workflows use tools from an MCP server you register; newly discovered tools enter the gateway with high risk and approval required, so you review their classification and policy before use.
Agent Studio workflows can use gateway tools, and AI Assistant access must be enabled and scoped. These settings do not mean every native Imperum agent runs through the MCP Gateway.
Review what ran
The Execution Log shows caller, tool, status and duration. The team can review successful executions, failures, policy denials and requests waiting for approval, and investigate an outcome without relying on the AI's answer alone. The log is an execution view, not a guarantee that every malformed or unknown-tool request is recorded.
Where does human judgment stay?
An MCP gateway enforces the policy you write; it does not write the policy for you. People still decide which tools to publish, which roles may run them, which risk level each tool carries and where approval is required. Approval is a policy decision, not a universal step after every tool call, so a tool marked low risk and unrestricted will run when it is called.
A gateway also has a defined scope. Imperum MCP Gateway governs tool calls and connects AI workflows to capabilities, while Virtus Sentinel addresses AI asset discovery and exposure. A gateway connection does not by itself provide all of Virtus Sentinel's protections, and the connected services still receive the authentication they need for their own connection.
Frequently asked questions
Does the AI receive our service credentials?
No. With Imperum MCP Gateway, the AI caller authenticates to the gateway, and gateway access is separate from service credentials. Imperum uses managed credentials for connected services and stores registered MCP server secrets encrypted in its vault. The connected services still receive the authentication needed for their own connection, but that authentication is not handed to the AI client.
Does connecting an MCP gateway expose every platform action?
No. Imperum MCP Gateway exposes published tools, not every action in the platform. Administrators select which local capabilities to publish. Tools discovered from a registered external MCP server are added with high risk and approval required. Every tool execution, whatever its source, remains subject to the configured role, rate and approval policies.
Which actions wait for human approval?
In Imperum MCP Gateway, tools marked as requiring approval, and tools rated high or critical risk, wait for approval by default. A deployed agent's administrator-configured auto-approval policy can permit actions within its allowed risk level. A high-risk request such as host isolation therefore waits by default, while a low-risk search can run once the caller's roles and rate policy allow it.
Is MCP Gateway the same as Virtus Sentinel?
No. Imperum MCP Gateway governs tool calls and connects AI workflows to security capabilities. Virtus Sentinel addresses AI asset discovery and exposure across your environment. The two solve different parts of AI agent security, and a gateway connection does not by itself provide all of the protections that Virtus Sentinel offers.
Next steps: start with one workflow
Pick one real task, such as gathering alert context, and put it behind the gateway before adding anything with greater impact:
- Connect and select: use a configured integration or register an external MCP server, then review the tools exposed to the gateway.
- Set the boundaries: inspect schemas, roles and risk, decide where approval is needed and configure the caller's access.
- Test and review: validate a representative request, inspect its outcome and review the execution record before expanding access.
The MCP Gateway page walks through publishing, execution policy and the Execution Log in more detail, and Agent Studio is where you build the AI workflows that use those tools.
