Dome Systems

Agent Operations Platform

Authorization

Policy that enforces, not policy that asks. Dome evaluates Cedar at the call boundary — in the Gateway and Broker, inside the platform — before any tool or model call leaves the perimeter. A buggy agent, a compromised process, or a developer who forgot to add a check cannot bypass it.

workspace/support/zendesk.cedar
// support-triage may only update tickets
// whose requester matches the end user the call
// is being made on behalf of.
permit (
  principal == Dome::Agent::"support-triage",
  action    == Dome::Action::"mcp:call",
  resource  == Dome::MCPTool::"zendesk/update_ticket"
) when {
  context.arguments.requester == context.actas.email
};

Workflow

Author a rule.Apply it everywhere.

The same loop applies to every rule. Define in Cedar, simulate against replayed traffic, ship versioned, and watch every governed call evaluated against it — all from one set of commands.

  1. 01

    Authorize

    Define rules at org, tenant, workspace, or agent scope. Cedar as the language; forbid wins.

  2. 02

    Evaluate

    Every tool and model call evaluated against the rule set at egress. Fail-closed, sub-5ms.

  3. 03

    Propagate

    The agent's registry record and end-user act-as claims carry through chained calls. Decisions reference the full chain.

  4. 04

    Filter

    Sensitive fields in tool responses classified and redacted before they reach the agent.

Consistent operations

The decision contract

Authorization in Dome uses Cedar — but the important properties for governance teams are not the language. They are the scope hierarchy and the decision contract. Forbid wins. Fail closed. Every decision is auditable to the rule version that produced it.

Org

Central security baselines. Forbids that cannot be overridden downstream.

Tenant

Business-unit specific rules — data residency, classification, regional constraints.

Workspace

Team-level capability grants. The grain most rules sit at.

Agent

Per-agent constraints layered on top of broader grants.

Scope hierarchy

Rules cascade through four scopes from org to agent. Every scope's rules are evaluated; forbid wins across the chain. Central security keeps its baselines; teams keep their autonomy.

Cedar policy

An open, AWS-developed policy language with formal semantics. Versioned per scope, simulatable against replayed traffic, and applied through CLI, API, or Terraform.

Decision contract

Fail-closed by default. Sub-5ms evaluation at the call boundary. Every decision recorded with the rule version that produced it — one query reconstructs any incident.

Options

What authorization lets you do

Beyond a rule set, the authorization layer exposes operational controls — what you can configure via the CLI, API, or Terraform to manage how policy ships and applies.

Replay simulation

Run a candidate Cedar rule set against the last N hours of recorded traffic. Get a diff of decisions before any rule reaches production.

Versioning & rollback

Every rule set is versioned. Roll forward, roll back, and inspect what rule version produced any given decision in the audit log.

Dry-run mode

Ship a rule in shadow mode — the engine evaluates and records the decision, but the call is not blocked. Useful for high-stakes rollouts.

Custom policy attributes

Extend the request context with workspace-specific attributes. Cedar evaluates them like any other attribute — classification tags, customer tier, deal stage.

Time-bound rules

Apply rules only within a window — incident response permits, on-call elevations, or scheduled changes. Expiry is enforced at the engine.

Cross-scope delegation

Tenant or workspace admins can author within their scope, bounded by org-level forbids. The platform enforces the boundary; teams keep their velocity.

In practice

From rule to enforced call

A Cedar rule with request context is enough to enforce a non-trivial invariant — like 'the agent may only update tickets whose requester matches the end user the call is being made on behalf of.'

Workspace-scope rulecedar
// The support-triage agent may only update tickets
// whose requester matches the end user the call is
// being made on behalf of.
permit (
  principal == Dome::Agent::"support-triage",
  action    == Dome::Action::"mcp:call",
  resource  == Dome::MCPTool::"zendesk/update_ticket"
) when {
  context.arguments.requester == context.actas.email
};
Simulate before shippingbash
dome rules simulate \
  --rules tools/zendesk.cedar \
  --replay last-24h

# Diff against current production set
dome rules diff \
  --rules tools/zendesk.cedar \
  --scope workspace/support