Use Dome as an MCP gateway

Your assistant already calls MCP tools on your behalf: databases, ticket queues, internal APIs, whatever you've connected. Called directly, that access carries its own problems: one shared credential for every call, no record of which call did what, and no way to cut off this assistant without breaking every other caller too.

In this tutorial, you will put a public demo MCP server behind the Default gateway, then rewrite your assistant's MCP config to reach it by signing in with your own Dome account instead of pasting in a static key. The rule you deploy is intentionally broad: allow everything for now. Govern your first agent covers narrowing it with allow, redact, and deny.

Prerequisites

For this tutorial, you will need:

• The Dome CLI. Refer to Install for Homebrew and direct-download instructions.
• A role that can provision a sandbox and deploy rules: admin, operator, or equivalent.
• Cursor, Claude Code, or Codex, each pointed at your Dome account rather than a shared agent key.

Prepare your environment

Sign in and provision a throwaway sandbox:

dome auth login
dome sandbox provision --scope=workspace --workspace-name connect-assistant
dome context sync
dome context use sandbox-connect-assistant

Confirm the workspace before continuing. Everything after this point creates resources:

dome context current

Add a tool

A tool is a backend the Gateway calls on your assistant's behalf. By connecting it to a Gateway, you decide which tools your assistant can discover and call, without your assistant ever seeing the tool's URL or credentials.

Register the public demo server and attach it to the Default gateway:

dome tools add \
  --name demo-hr \
  --url https://demo-mcp.domesystems.ai/mcp \
  --protocol streamable-http \
  --auth-method none \
  --gateway Default

The connection name prefixes every tool it exposes, so this server's tools become demo-hr/hr/list_employees, demo-hr/it/get_incidents, and so on. A tool with no Gateway membership is registered but unreachable.

Enable interactive access

Every call through a Gateway is authorized and audited against an agent identity, not against a person or a product name. Interactive access gives you that identity without registering one by hand: enabling it creates a managed agent that you, and anyone else you allow-list, sign in as through a browser.

Enable it on Default, allow-listing the email you used for dome auth login:

dome gateways interactive enable Default --email you@example.com

The command prints the managed agent's name, gateway-interactive-<gateway-id>. Confirm it, since the next step needs it:

dome gateways get Default --json

Read interactive_access.managed_agent_name from the response.

Allow it through

Enabling interactive access already admitted the managed agent to Default. Cedar Rules still decide what it may call, the same as any agent.

Deploy a bundle that stays deliberately open, since this tutorial is about the connection, not the policy. Create interactive-access.cedar:

permit(
  principal is Dome::Agent,
  action == Dome::Action::"mcp:discover",
  resource
);

permit(
  principal is Dome::Agent,
  action == Dome::Action::"mcp:call",
  resource
);

The --agent flag takes the managed agent's name from the previous step, not a name you chose.

Deploy it scoped to that agent:

dome rules apply interactive-access.cedar \
  --agent gateway-interactive-GATEWAY_ID \
  --name interactive-access

Connect your client

Point your MCP client at the Default gateway's tools ingress. One call resolves the whole URL, so there is nothing to assemble by hand.

Run it:

dome gateways get Default --json

Copy endpoints.mcp_url from the response. That value is MCP_URL below, with no token or header this time. The first connection triggers a browser sign-in instead.

{
  "mcpServers": {
    "dome-tools": {
      "url": "MCP_URL"
    }
  }
}

claude mcp add --transport http dome-tools MCP_URL

[mcp_servers.dome-tools]
url = "MCP_URL"

codex mcp login dome-tools

Reload MCP. The first connection opens your browser: sign in with the email you allow-listed, review the client and the tools it can reach, and approve. Your client stores the resulting grant and refreshes it silently after that, until it expires or you revoke it.

Verify the results

Ask your assistant a question that needs the demo tool, for example "Who works here?" You should get back the demo employee directory, including ids such as E001.

Confirm the call is attributed to the managed agent, and to you specifically:

dome audit query --limit 5

Expect a tool.call event naming demo-hr/hr/list_employees (or whichever tool your assistant chose), attempted and completed, with gateway-interactive-<gateway-id> as the agent and your email under act_as. That is the difference from a shared agent key: if a teammate signs in later, their calls land under the same agent but their own act_as identity, and you can revoke just their grant without touching yours.

Next steps

You pointed a real MCP client at a Dome Gateway, signed in as yourself, and watched a governed call land in audit under your own identity. Continue with:

• Use Dome as a model broker to route your assistant's own inference through Dome the same way
• Interactive MCP access to allow-list teammates, scope Rules per person, and manage grants
• Govern your first agent to narrow this broad rule to an allowlist and redact fields on the way back