Agent Operations Platform
Tool Gateway
Dome's MCP gateway, and where agents reach the outside world. Every tool call passes through it: an MCP server, a REST API, an internal service. One place decides what an agent may do, with which arguments, for which person.
Workflow
Attach the first tool.Then the next.
The same loop for every backend. One CLI command, one rule, one declarative line in CI.
- 01
Attach
Register the backend with its protocol, auth method, and credential strategy. Tools surface into the catalog with declared schemas.
- 02
Authorize
Define rules at the right scope. Simulate against replayed traffic before activation.
- 03
Evaluate
Every call is evaluated at egress — agent, end-user, tool, arguments, scope. Forbid wins; sub-5ms.
- 04
Filter
Classify and redact sensitive fields in tool responses before they reach the agent's context.
Consistent operations
How every tool call flows
One enforcement point, four questions answered in the same place: what is callable, who may call it, which credential is used, and what comes back.
Agent-signed call arrives at the Gateway with full request context.
Policy evaluates principal, action, resource, and arguments.
Backend credentials are pulled from your secrets store at egress.
Sensitive fields in the response are classified and redacted.
Catalog
Backends register with declared schemas, and agents discover them through the same catalog the rules read. Per-agent access is a rule, not a second backend.
Per-call evaluation
Rules see the whole request: agent, verified caller, tool, arguments. Nothing leaves the platform before the decision, and forbid wins across all four scopes.
Egress controls
Backend credentials live in your secrets store, never in agent code. The Gateway injects them at egress and runs the Guard chain over the response.
Options
What the Gateway lets you do
What you can configure per backend, from the CLI, the API, or Terraform.
Multi-protocol backends
Remote MCP, stdio MCP, REST described by OpenAPI, or a first-party internal service, all under the same contract. A REST API can come in through a versioned adapter you install and upgrade like a package.
Credential strategies
Attach a backend with shared, per-user, or per-agent credentials. Rotation happens in your secrets store, and the agent never sees the secret.
Guards
Filters on the response path and validators on the request path, attached per connection. Versioned, with rollback — the panel below works through the model.
Catalog curation
Block or deprecate a tool and it never appears in discovery. Pre-fill a person's catalog on their behalf, and a key sees only what its permissions allow.
Rate limiting
Per-agent and per-tool ceilings, set at workspace or agent scope. A runaway loop stops before it becomes a bill.
Replay simulation
Run a candidate rule bundle against a window of recorded decisions. See which calls flip from allow to deny, and which rule does it, before shipping.
In practice
From backend to governed call
Attach the backend, guard what it returns, then write the rules. Agent code does not change: it speaks MCP to the Gateway.
dome tool add \
--name zendesk \
--url https://mcp.zendesk.example.com \
--protocol streamable-http \
--auth-method oauth \
--credential-type shared
dome guards filters create tool-scrub \
--config-from ./tool-scrub.json
dome tool guards filters set zendesk \
--direction response --filters tool-scrub
dome rules apply tools/zendesk.cedarpermit (
principal == Dome::Agent::"support-triage",
action == Dome::Action::"mcp:call",
resource == Dome::MCPTool::"zendesk/create_ticket"
) when {
principal has act_as &&
resource.arguments.requester == principal.act_as.email
};Guards
Authorization decides whether a call happens. Guards decide what comes back.
A rule says nothing about the content of a result, and the result is often the sensitive part: a customer record carrying a national ID, a document quoting another client's matter. Guards attach per connection and per direction. Request sees the arguments before dispatch, response sees the result before the agent does.
{
"json": {
"components": [
{
"field_actions": [
{ "matcher": { "path": "**.ssn" },
"action": "FILTER_ACTION_OMIT" },
{ "matcher": { "path": "**.email" },
"action": "FILTER_ACTION_REDACT" },
{ "matcher": { "path": "**.card" },
"action": "FILTER_ACTION_BLOCK" }
]
}
]
}
}dome guards filters create tool-scrub \
--description "Omit SSN, redact email, block cards" \
--config-from ./tool-scrub.json
dome tool guards filters set zendesk \
--direction response --filters tool-scrub
# Roll back to an earlier version
dome guards filters rollback tool-scrub --to-version 2Three actions, fixed precedence
Redact rewrites the matched value, omit removes the key, block withholds the message. Where two target the same path the strongest wins: block over omit over redact.
A small path dialect
Match a top-level field, an exact nested path, one array element, or every element of an array. A leading ** matches at any depth, so **.phone catches the field wherever the response puts it.
Every encoding, one pass
Guards traverse every shape an MCP server can return: raw JSON, the content array, JSON encoded inside text or resource.text, and the structuredContent mirror. One encoding cannot leak what another redacted.
Fail closed
A filter that cannot be evaluated blocks its connection and direction. A broken filter is an outage on that path, never a silent bypass.
One ordered chain per slot
Each connection and direction holds one ordered chain, and setting it replaces the whole list. Put narrow transforms ahead of broad blocking matchers: a matching block short-circuits the rest.
Versioned, never mutated
Editing a filter deploys a new version, and connections pick it up on the next config sync. Rollback copies an earlier config forward. History is never rewritten.
Kind is structural and fixed at create time — json filters attach to tool connections, text filters to model connections. The convenience flags on dome guards filters create produce text filters, so scrubbing a tool payload means authoring a JSON config and passing --config-from. The MCP gateway field guide works through the whole model.
Registry
Broker
ManagementQuestions
Common questions about MCP gateways
What is an MCP gateway?
An MCP gateway is a single governed endpoint between agents and the tools they call. Dome's Tool Gateway is one: every tool call passes through it, so it is the enforcement point for what an agent may do, with which arguments, for which person.
Does routing tools through Dome mean rewriting the agent?
No. The agent speaks MCP to the Gateway, and its code stays the same regardless of what kind of backend sits behind it. Attaching or replacing a backend is a configuration change rather than a redeploy.
What is the difference between authorization and Guards?
Authorization decides whether a call happens. Guards decide what comes back. Authorization evaluates policy before the call leaves the perimeter; Guards filter and validate the response before the agent sees it.
Do agents ever hold the tool's credentials?
No. Credentials are injected at egress, at the Gateway, so the agent never holds the credential for the system it is calling. A leaked agent credential does not expose the upstream tool.
Where does the Tool Gateway sit in the platform?
It is the middle of the three control points, governing tools between code in the Agent Registry and models in the Model Broker, on one control plane of access, authorization, and audit.