MCP Gateway vs Decision Engine

An MCP gateway is an inline proxy that sits between AI agents and the MCP servers or tools they call. It inspects every request, applies policy, and can rate-limit, log, or block traffic in the path. Think of it as an API gateway specialized for the Model Context Protocol, tuned for the way agents make chained tool calls. When people ask what an MCP gateway does, this is the short version: it is the enforcement point that every agent-to-tool request passes through.

Gateways are good at what network devices have always been good at:

• Terminating and inspecting traffic in real time
• Applying static allow-lists and block-lists
• Rate limiting noisy or misbehaving agents
• Logging every request and response for later review
• Enforcing schema validation on MCP tool calls

But a gateway has a hard ceiling on its own. It sees the call. It does not see who is really behind the call, what that agent can actually do inside the downstream SaaS application, or whether this specific action is part of a toxic combination that only shows up when you correlate identity, entitlements, and behavior across platforms.

MCP gateway vs API gateway

An API gateway secures traffic between clients and backend APIs with authentication, rate limits, and schema validation. An MCP gateway does the same for the Model Context Protocol. The difference is context. A traditional API gateway assumes a static client identity, a well-defined contract, and predictable request patterns. An MCP gateway deals with probabilistic agents making dynamic, chained calls where the real risk is not in any single request but in the identity and authority behind it. That is why MCP gateways benefit from an external decision engine in a way API gateways rarely do.

A decision engine answers the question a gateway cannot answer alone: given the identity behind this call, the agent's effective authority, and the data at stake, should this action be allowed, approved, or blocked? It does not sit in the traffic path. It reasons about identity, authority, and risk, then returns a verdict when asked.

For agentic AI security, the decision engine has to correlate:

• The human identity that invoked the agent, if any
• The agent's own non-human identity and the credentials it carries
• The agent's effective access inside each downstream application: which service account it runs as, which objects, tables, and actions that account can actually touch, not the vendor's theoretical config page
• Whether the agent is running in maker mode on its creator's admin credentials
• Whether the agent is orphaned, publicly reachable, or part of a shadow deployment
• Real-time behavior and prior action chains

This is the runtime truth layer, and it is where machine insider risk gets caught. Picture a user with no Salesforce license invoking an agent that a Salesforce admin built, then pulling records that user should never see. The gateway sees a tool call. The decision engine sees the privilege escalation, because it already mapped what that service account can reach and matched it against who is really driving the request.

The pattern most enterprise programs are landing on looks like this:

1. An AI agent makes an MCP tool call.
2. The MCP gateway intercepts the request inline.
3. The gateway calls the decision engine with the call metadata: agent ID, invoker identity, target tool, target data.
4. The decision engine correlates that call against its map of agents, identities, entitlements, and behavior.
5. The decision engine returns one of three answers: allow, approve (route to a human), or block.
6. The gateway enforces the verdict in the traffic path.

The gateway provides the enforcement moment. The decision engine provides the meaning. Obsidian is the second layer. Obsidian is not a gateway, does not build a gateway, and does not sit in the traffic path. An ecosystem partner like Cloudflare handles the inline enforcement. Obsidian is the endpoint the gateway calls when it needs a real verdict.

One honest caveat on where this runs live today. Autonomous runtime enforcement, where a verdict actually stops an action as it happens, is available for Claude and Microsoft Copilot. For the other agent platforms in scope (Agentforce, Amazon Bedrock, Google Vertex, ServiceNow's Now Assist, Snowflake Cortex, Moveworks, n8n), Obsidian discovers and governs today, building the inventory and the authority map, with runtime enforcement on the roadmap rather than shipping in present tense. That distinction matters when you plan a rollout, because you enforce where enforcement exists and you govern everywhere else.

Setting up the two layers

The integration is more onboarding than migration:

1. Deploy the gateway inline on your MCP traffic path, per vendor documentation.
2. Register the decision engine as a policy callout endpoint.
3. Onboard your AI platforms to the decision engine through native APIs and webhooks. Obsidian's approach does not require SaaS connectors.
4. Let the engine build an inventory of agents, identities, and effective access for two to four weeks before enabling any enforcement.
5. Turn on approve verdicts first for high-risk categories such as maker mode, orphaned agents, and org-wide reachable agents.
6. Move to block verdicts where enforcement is live once your team is comfortable with the false-positive rate.

A gateway on its own can only match patterns it already holds. It cannot answer questions like:

• Is this agent running in maker mode on a Salesforce admin's credentials?
• Is the human on the other end of this call actually entitled to the data the agent is about to fetch?
• Is this a confused-deputy case, where an agent with broad permissions is being steered by a lower-privileged user?
• Is this call one link in an action chain that looks fine step by step but crosses a policy boundary in aggregate?
• Is the agent's creator disabled, which would make this an orphaned agent running on inherited access?

Answering these needs the identity graph a decision engine maintains. Obsidian correlates signals from AI agent platforms, identity providers, and browser telemetry into a living map of effective access: which agent, running as which account, can reach which tables, objects, and actions in the third-party app. Without that map, a gateway enforces policy on shadows. The blast radius of a single over-permissioned agent stays invisible until someone correlates its real reach, and roughly 90 percent of agents are over-permissioned to begin with.

What a gateway alone cannot see

• Effective access inside SaaS applications, down to the service account and its object-level reach
• Correlation of one agent's behavior across multiple platforms
• Maker-mode and orphaned-agent conditions
• Toxic combinations that only appear when identity, entitlement, and behavior are joined

The contract between the gateway and the decision engine is deliberately small. The gateway calls out on each MCP tool call. The decision engine returns one of three verdicts.

• Allow: The call is consistent with the agent's effective access and the invoker's entitlements. Let it through.
• Approve: The call is high risk but not clearly malicious. Hold it, route it to a human approver, and enforce the human's decision.
• Block: The call violates policy. The invoker lacks entitlements, the agent is orphaned, the combination is toxic, or the action chain crosses a boundary. Reject it.

This is a policy control plane, not per-call billing. The decision engine's job is to make each verdict deterministic, auditable, and fast enough for the gateway's enforcement window. Because agents move roughly 16 times more data than humans do, and can generate thousands of tool calls in a single session, the verdict has to be cheap to ask for and quick to return.

Latency and failure modes

Gateways typically add sub-millisecond overhead in the path. The decision engine callout is the variable. A well-built engine returns verdicts inside a one-second window and usually much faster. Set a fail-open or fail-closed default for the moments the engine is unreachable, and log every fallback event so the audit trail stays intact. When calls go missing from gateway logs, suspect agents reaching MCP servers directly and bypassing the path, which is exactly why cross-platform inventory from the decision engine matters more than any single choke point.

You do not really choose between them. You choose based on what you are trying to accomplish right now.

• Use an MCP gateway if you need inline enforcement, traffic logging, and rate limiting on agent-to-tool communication and you already have a clear policy set to enforce.
• Use a decision engine if you need visibility into agent inventory, effective access, maker-mode risk, orphaned agents, and toxic combinations across every AI platform you run.
• Use both if you want deterministic enforcement of dynamic policy at runtime, informed by identity and behavior context a gateway cannot assemble on its own.

Most organizations start with the decision engine, because inventory and effective access are prerequisites for any rule a gateway would enforce. You cannot write policy for something you cannot see, and ghost-chasing configuration pages tells you what an agent was set up to do, not what it can actually reach.

Cost drivers to plan for

Watch for per-API-call billing on either layer, since it scales badly against agentic workloads. The real cost drivers are the number of AI platforms in scope, the number of agents under management, whether the decision engine needs SaaS connectors (Obsidian's does not), and the integration and operations lift beyond the license.

A three-question gut check

1. Do agents in your environment call MCP servers often enough that inline enforcement earns its keep?
2. Do you already have inventory and effective-access visibility, or are you reasoning from configuration?
3. Do you have a decision layer to supply the verdict, or would the gateway be enforcing static rules against dynamic threats?

If the honest answer to the second question is that you lack inventory, start with the decision engine and add the gateway when you are ready to enforce.