Agent Operations Platform

Developer and Operator Experiences

Bring agents under management from wherever you already work. Four surfaces reach the same control plane: SDKs in your agent code, an API for any client, a CLI for the terminal and CI, and an MCP server for AI assistants.

Read the docs

dome — operator

At a glance

One control plane, four surfaces

Pick the one that fits the workflow; they compose freely. SDKs and the CLI are the daily drivers, the API is underneath all of them, and MCP hands Dome itself to an assistant.

Surface	Who uses it	What it's for
SDK	Agent engineers	In-process policy checks, audit emission, registry context propagation. Go and Python.
API	Any client	REST and gRPC across the full control surface. The CLI, the SDKs and every integration run on it.
CLI	Platform teams, CI/CD	Canonical operator surface. Register agents, attach tools, apply policy, query audit.
MCP	AI assistants	Claude, Copilot and anything else that speaks MCP, driving Dome for triage and review.

SDK

In-process governance for agent code

How agent code participates in the platform. The SDK wraps the API key into a short-lived token, syncs a local rule bundle for fast decisions, and emits audit from the call site.

Python — register and checkpython

import dome

client = dome.DomeClient(dome.DomeConfig(
    base_url="https://api.dome.example.com",
    token="dome_at_...",   # agent API key
))
client.start()  # background rule sync; fail-closed until first sync

client.check(
    tool="zendesk/create_ticket",
    on_allow=lambda decision: ...,
    on_deny=lambda req, reason: ...,
)

Capabilities

Local rule evaluation for low-latency decisions at the call site
Rule bundle sync from the control plane
Fail-closed until the first successful sync
Audit emission for every check, allowed or denied
Identity propagation — agent token plus act-as principal
Token refresh and rotation handled transparently

API

The foundation everything else is built on

REST and gRPC cover the whole control plane. Every CLI command, every console action and every SDK sync is this API underneath, so reach for it directly when you are embedding Dome in your own tooling.

POST/v1/agents

Register an agent. The returned record goes into the agent's SDK configuration, binding every later call back to a managed agent.

Body parameters

namestringrequired: Human-readable identifier for the agent. Unique within the workspace.
workspacestringrequired: Workspace slug the agent belongs to. Drives default policy attachment and audit scoping.
toolsstring[]optional: Optional tool slugs to attach at registration. Tools can also be granted later.
act_asstringoptional: Optional principal the agent acts on behalf of. Used for identity propagation and consent scoping.

Requestjson

POST /v1/agents
Authorization: Bearer $DOME_OPERATOR_TOKEN
Content-Type: application/json

{
  "name": "support-triage",
  "workspace": "support",
  "tools": ["zendesk", "stripe"]
}

Response 201 Createdjson

{
  "id": "agt_3mw7kp",
  "name": "support-triage",
  "workspace": "support",
  "status": "active",
  "tools": ["zendesk", "stripe"],
  "created_at": "2026-06-03T14:22:09Z"
}

CLI

The canonical operator surface

The daily driver for platform teams, from a terminal or a pipeline. Every command resolves to an API call, so anything interactive can be scripted or made declarative through the Terraform provider.

Agent lifecyclebash

dome agents register \
  --name support-triage \
  --tool zendesk/create_ticket \
  --pool prod-models

dome agents suspend support-triage
dome agents reactivate support-triage

Policy & auditbash

dome rules apply tools/zendesk.cedar
dome rules simulate \
  --agent support-triage \
  --action mcp:call \
  --resource zendesk/update_ticket

dome audit query --agent-id support-triage --since 24h
dome audit stream --agent-id support-triage

MCP

Let AI assistants drive Dome

The Dome MCP server exposes the control plane to Claude, Copilot, Cursor, and anything else that speaks MCP. Ask an assistant to summarize the last hour of denials, draft a rule change, or walk an agent's audit trail.

✻ Welcome to Claude Code

/help for help, /status for your current setup

cwd: ~/dome-ops

※ Tip: connected to MCP server dome

> Summarize denials for support-triage in the last hour and propose a policy fix.

I'll pull the recent audit trail, look for a pattern in the denials, then check how the call is being decided today before suggesting anything.

dome_audit_query(MCP)

⎿ agent-id=support-triage results=denied since=1h 12 denied calls, 2 distinct tools: · zendesk/delete_ticket 9× · stripe/refund 3× All acting on behalf of support@meridian.example.

dome_rules_simulate(MCP)

⎿ agent=support-triage action=mcp:call resource=zendesk/delete_ticket Decision: DENY Reason: no rule permits it — default-deny Rule: (none matched)

support-triage is reaching for write actions it doesn't need, and today those calls fall through to default-deny rather than matching a rule. Making the denial explicit means it is auditable by rule id, and forbid wins over any permit added later. Here's the rule to add to tools/zendesk.cedar:

forbid (
  principal == Dome::Agent::"support-triage",
  action    == Dome::Action::"mcp:call",
  resource  == Dome::MCPTool::"zendesk/delete_ticket"
);