Use case
Consolidate tool access
Using Dome's MCP Gateway
Every agent reaches for tools: Zendesk, Jira, a warehouse, three internal APIs, someone's custom MCP server. Consolidating that reach is six resources, and the agent is granted exactly one of them. Credentials stay at the boundary, rules run on every call, and one audit vocabulary covers all of it.
Composed from
Six resources, one boundary
Gateways, Tools, Rules, Guards, Quotas and Audits. The gateway is where the six meet, whether your agents are the ones calling out or your customers' agents are the ones calling in.
The one surface an agent is granted. Logical, not physical. Make as many as the shape of your estate needs.
The connections behind it. An MCP server, a REST API described by OpenAPI, or a first-party internal service.
Evaluated per call, on the arguments as well as the target. Simulated against real traffic before they ship.
The response path. Redact fields, refuse records, filter what comes back before it reaches the model.
Ceilings per agent, per tenant, per window.
Every call, with who, what, under which rule, and with what result. One vocabulary across every backend.
Nothing here belongs only to the MCP Gateway. One policy language, one audit vocabulary, one access layer, across every composition. See the whole resource set.
Scenario
Four tools, four credentials
A support-triage agent reaches Zendesk, Jira, Snowflake and a custom MCP server. Four credentials sit in its environment, four auth models sit in its code, and audit comes back in four shapes.
What makes it hard
Credentials travel with the agent
A key in an environment variable is a key on every machine the agent runs on.
The same control, re-implemented per tool
Each backend arrives with its own idea of who may call it and what they may ask for.
Authorization stops at the call
Permitting a query does not constrain the rows it returns.
Cost has no boundary
One conversation fans out into dozens of tool calls. A per-request budget tells you nothing.
The work, in resources
Tools. Add each backend once. An MCP endpoint, an OpenAPI description, or an internal service.
Gateways. Compose them into one Gateway and grant it to the agent. The credential stays here and never reaches agent code.
Rules. Permit the operations this agent needs. Simulate against yesterday's traffic before you deploy them.
Guards. Filter the response path so a permitted call cannot return fields this caller should not see.
Quotas. Cap the agent over a window. A retry loop stops before it drains the workspace.
Audits. One event shape across all four backends. Queryable, and streamable to the SIEM.
Scenario
Your API becomes a tool surface
You publish an MCP surface over your billing API. A customer's agent walks it in a sequence nobody designed for: twenty calls where a person would have made two, half of them retried.
What makes it hard
Callers stopped being deterministic
Rate limits and API keys assume software that behaves the same way twice. An agent decides what to call at runtime.
The contract described none of this
Long-lived sessions, agents spawning agents, one agent holding forty tools at once.
Per-tenant blast radius
One customer's runaway agent is your incident, and containment has to be set in advance.
The arguments are the risk
The call is permitted. What it is asking for is the open question.
The work, in resources
Tools. Expose the operations you want callable. The rest of the API stays invisible, including in discovery.
Gateways. A Gateway per tenant, carrying only what that tenant is entitled to reach.
Rules. Write once at tenant scope, with overrides where a contract genuinely differs.
Guards. Constrain arguments on the request path. A malformed or hostile call is stopped before it runs.
Quotas. Ceilings per tenant. One customer's loop stays one customer's problem.
Audits. Per-tenant usage and denials, ready for billing and for the support conversation.
What changes
Where the operational work ends up
The work does not disappear. Per-tool, per-agent, per-team controls collapse into one place the platform team operates and security can reason about.
Before
After
Distributed control
Credentials live in each agent. Each tool has its own auth model. Audit is per-tool and per-format. The same decision is duplicated across every agent that calls the same backend.
One gateway
Credentials live at the boundary. Policy attaches to the tool. Audit is one event vocabulary across every action. Adding a tool is a configuration change.
Output trust
Whatever the tool returns flows back to the agent. PII, restricted records, credentials embedded in payloads, all of it landing in the model context.
Output governance
Responses pass back through policy. Fields redacted, records refused, sensitive substrings filtered. Outputs governed as well as inputs.
Composes with
The enterprise systems you already have
The gateway sits on top of the systems your team already operates. Credentials, policy, and audit each route through their existing home.
Secrets
Tool credentials never leave the gateway. Injected at the call boundary from the secrets store your team already manages.
Learn moreIdP
End-user identity propagates from the front door through every tool call, attributable to your existing identity provider.
Learn moreSIEM
Every governed call streams to the security data lake. The full audit vocabulary lands in your existing query surface.
Learn moreSOAR
Denials and anomalies can trigger playbooks. The audit trail provides the evidence chain those playbooks need to act.
Learn moreMCP ecosystem
External MCP servers attach as tools and flow through the same gateway. One policy, one audit, one operational surface.
Learn moreSource control
Tool attachments and rules live in a repo. Versioned, peer-reviewed, simulated against recent traffic before merge.
Learn moreNext steps