Dome Systems

Experience

Operator surfaces

Bring agents under management from wherever you already work. The same control plane is reachable through four surfaces — SDKs in your agent code, an API for any client, a CLI for the terminal and CI, and an MCP server for AI assistants.

dome — operator

At a glance

One control plane, four surfaces

Every surface speaks to the same Dome control plane. Pick the one that fits the workflow — they compose freely. SDKs and the CLI are the daily drivers; the API underpins everything; MCP exposes Dome itself to AI assistants for triage and review.

SurfaceWho uses itWhat it's for
SDKAgent engineersIn-process policy checks, audit emission, registry-context propagation. Go and Python.
APIAny clientREST and gRPC for the full control surface. Foundation for the CLI, SDKs, and integrations.
CLIPlatform teams, CI/CDCanonical operator surface. Register agents, attach tools, apply policy, query audit.
MCPAI assistantsLets agents (Claude, Copilot, etc.) drive Dome itself for triage and review.

SDK

In-process governance for agent code

The SDKs are how agent code participates in the platform. They wrap the agent's API key into a short-lived JWT, sync a local policy bundle for fast local decisions, and emit audit events 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 Cedar 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 surfaces cover the full control plane. Every operation in the CLI, every action in the console, every SDK sync — all of it is the API underneath. Use it directly when you need bespoke automation or to embed Dome operations in your own platform tooling.

POST/v1/agents

Register a new agent in the Dome control plane. The returned registry record is embedded in the agent's SDK configuration to bind every subsequent 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.
tierenumoptional
Resource and reasoning tier. Determines model pool eligibility and rate limits.
standardpremiumrestricted
toolsstring[]optional
Optional tool slugs to attach at registration. Tools can also be granted later via the policy surface.
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",
  "tier": "standard",
  "tools": ["zendesk", "stripe"]
}
Response 201 Createdjson
{
  "id": "agt_3mw7kp",
  "name": "support-triage",
  "workspace": "support",
  "tier": "standard",
  "status": "active",
  "tools": ["zendesk", "stripe"],
  "created_at": "2026-06-03T14:22:09Z"
}

CLI

The canonical operator surface

The CLI is the daily driver for platform teams. It works equally well from a developer terminal or a CI/CD pipeline. Every command resolves to an API call, so anything you can do interactively can be scripted or made declarative through a CI workflow or the Terraform provider.

Agent lifecyclebash
dome agents register \
  --name support-triage \
  --tier standard \
  --tool zendesk \
  --pool premium-reasoning

dome agents suspend support-triage
dome agents activate support-triage
Policy & auditbash
dome rules apply tools/zendesk.cedar
dome rules simulate \
  --rules tools/zendesk.cedar \
  --replay last-24h

dome audit query --agent support-triage --since 1h
dome audit stream --agent support-triage

MCP

Let AI assistants drive Dome

The Dome MCP server exposes the control plane to MCP-capable clients — Claude, Copilot, Cursor, and any other agent that speaks MCP. Useful for triage and review workflows: ask an assistant to summarize denials in the last hour, draft a policy change, or walk through an agent's recent 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 simulate a tighter rule before suggesting it.
dome:audit_query(MCP)
⎿ agent=support-triage window=1h status=deny 12 denied calls, 2 distinct tools: · zendesk/delete_ticket 9× (policy: tools.zendesk.write) · stripe/refund 3× (policy: tools.stripe.refund) All originated from session sid_8af2... acting on behalf of support@meridian.example.
dome:rules_simulate(MCP)
⎿ Replay window: last 24h (1,259 calls) Proposed rule: forbid delete_ticket for support-triage role · Would deny: 12 calls (matches the 12 above) · Would allow: 1,247 calls (unchanged) · Regressions: 0 previously-allowed calls now denied · Net effect: closes the gap with no collateral
Pattern is clear — support-triage is reaching for write actions it doesn't need. The simulation is clean. Here's the Cedar rule to add to tools/zendesk.cedar:
forbid (
  principal in Role::"support-triage",
  action == Action::"zendesk/delete_ticket",
  resource
) when {
  context.session.act_as.role != "admin"
};
Want me to apply this with `dome rules apply` and open an audit annotation linking the original denials?
>
⏵⏵ accept edits on (shift+tab to cycle)opus-4-7 · 98%