Dome Systems

Agent Operations Platform

Tool Gateway

The Tool Gateway is where agents reach the outside world. Every tool call — to an MCP server, a REST API, an internal service — passes through it. That makes it the natural enforcement point for what an agent can do, with which arguments, on behalf of which user.

dome — gateway

Workflow

Attach the first tool.Then the next.

The same loop applies to every backend you bring under management. One CLI command, one Cedar rule, one declarative line in CI — repeat for every tool that touches an agent.

  1. 01

    Attach

    Register the backend with its protocol, auth method, and credential strategy. Tools surface into the catalog with declared schemas.

  2. 02

    Authorize

    Define Cedar rules at the right scope. Simulate against replayed traffic before activation.

  3. 03

    Evaluate

    Every call is evaluated at egress — agent, end-user, tool, arguments, scope. Forbid wins; sub-5ms.

  4. 04

    Filter

    Classify and redact sensitive fields in tool responses before they reach the agent's context.

Consistent operations

How every tool call flows

A single enforcement point in the call path turns four hard problems into one place to reason about: what is callable, who can call it, what credentials get used, and what comes back.

Receive

Agent-signed call arrives at the Gateway with full request context.

Authorize

Cedar policy evaluates principal, action, resource, and arguments.

Inject

Backend credentials are looked up in Vault and added at egress.

Filter

Sensitive fields in the response are classified and redacted.

Catalog

Tools are registered as backends with declared schemas. Agents discover them through the same catalog the policy engine reads. Per-agent access is controlled by rules, not separate backends.

Per-call evaluation

Cedar rules evaluate the full request context — agent, end-user act-as claims, tool, arguments — before any byte leaves the platform. Forbid-wins across the four-scope hierarchy.

Egress controls

Backend credentials live in Vault, never in agent code. The Gateway injects them at egress and filters response fields by classifier before the agent sees them.

Options

What the Gateway lets you do

Beyond attaching a backend, the Gateway exposes operational controls — what you can configure via the CLI, API, or Terraform to harden how each tool behaves on the platform.

Multi-protocol backends

Bring in Remote MCP, stdio MCP, REST APIs described by OpenAPI, or first-party internal services — all governed under the same policy contract.

Credential strategies

Attach backends with shared, per-user, or per-agent credentials. Rotation happens at Vault; the agent never sees the secret.

Response classifiers

Pluggable PII and secret detectors, plus custom classifiers per tenant. The Gateway redacts before the response reaches the agent's context.

Argument validation

Enforce input schemas declared at attach time. Calls with off-schema arguments are denied before reaching the backend.

Rate limiting

Per-agent and per-tool ceilings to prevent runaway loops or abusive call patterns. Configurable at workspace or agent scope.

Replay simulation

Run a candidate Cedar rule against the last N hours of recorded traffic. See which decisions would flip before shipping the change.

In practice

From backend to governed call

Attach the backend, then write the rules that govern who can call it. The agent code stays the same regardless of backend type. It speaks MCP to the Gateway.

Attach a remote MCP toolbash
dome tool add \
  --name zendesk \
  --url https://mcp.zendesk.example.com \
  --protocol streamable-http \
  --auth-method oauth \
  --credential-type shared

dome rules apply tools/zendesk.cedar
tools/zendesk.cedarcedar
permit (
  principal == Dome::Agent::"support-triage",
  action    == Dome::Action::"mcp:call",
  resource  == Dome::MCPTool::"zendesk/create_ticket"
) when {
  context.arguments.requester == context.actas.email
};