Simulate rules

Simulation replays candidate Rules against recorded authorization decisions to show which outcomes would change. Dome compares each historical event with the decision the candidate Rules would produce.

Overview

Simulation takes candidate Rules and replays them against recorded authorization decisions from your audit log. For each historical event, it compares the original decision with the decision the candidate Rules would produce. The output is a set of DecisionDiffs: entries where the allow/deny outcome differs between the current Rules and the candidate Rules.

Use simulation to answer questions like:

• Would this new forbid have blocked any requests that were previously allowed?
• Does this permit open access to anything that was previously denied?

You can also probe a single synthetic request against the active effective Rules without performing the action. That path returns the decision and the Rule that determined it. Use it when you want a fast check for one agent, action, and resource before you look at historical diffs.

Simulation sits between writing Rules and deploying them. Refer to Authorize Access for deploy and rollback.

The typical workflow is:

1. Run a simulation for one agent, action, and resource against the Rules in effect.
2. Optionally simulate draft Rules in the editor before you apply.
3. Optionally simulate with Agent Act-As or simulate with arguments.
4. Read results for historical DecisionDiffs when you replay candidate Rules against audit history.

Requirements

Before you begin:

• Authenticate to Dome and select a workspace
• Have an active Rule bundle
• For historical replay, have authorization events available in the audit log

Permissions

Simulation and DecisionDiff reads require rules.view. All workspace roles hold it.

Run a simulation

Simulate an authorization decision for one agent, action, and resource against the Rules currently in effect.

Write or refine the Cedar Rules you want to test before you deploy them:

permit(
  principal == Dome::Agent::"data-pipeline",
  action == Dome::Action::"mcp:call",
  resource == Dome::MCPTool::"database-query"
);

Then run the simulation with the caller, action, and resource you care about:

dome rules simulate \
  --agent data-pipeline \
  --action mcp:call \
  --resource database-query \
  --resource-type mcp_tool

{
  "agent_id": "data-pipeline",
  "action": "mcp:call",
  "resource": "database-query",
  "resource_type": "mcp_tool"
}

POST /v1/authz/evaluate
Content-Type: application/json

{
  "caller": {
    "agent_id": "<agent-uuid>"
  },
  "action": "mcp:call",
  "resource": "database-query",
  "resource_type": "mcp_tool",
  "workspace_id": "<workspace-uuid>"
}

Simulate authorization for agent "data-pipeline" doing mcp:call on mcp_tool "database-query".

Simulate draft Rules in the editor

In the Rules editor, click Simulate in the toolbar. The slide-over shows an Against: Deployed | Draft toggle (defaults to Draft). On Draft, the editor's current unsaved files ship as the override for the scope being edited. Production traffic is untouched — the override lasts for that Evaluate call only.

Evaluate accepts an optional override that replaces one scope's bundle for the duration of the call. Workspace and agent scopes only.

{
  "caller": { "agent_id": "<agent-uuid>" },
  "action": "mcp:call",
  "resource": "database-query",
  "resource_type": "mcp_tool",
  "workspace_id": "<workspace-uuid>",
  "override": {
    "scope_kind": "workspace",
    "scope_id": "<workspace-uuid>",
    "files": [
      { "path": "rules.cedar", "content": "permit(principal, action, resource);" }
    ]
  }
}

An empty, missing, or unknown-scope override is a no-op — the call evaluates the deployed policy.

Simulate with Agent Act-As

Include Act-As claims when your Cedar Rules reference end-user identity and you want to verify behavior for specific profiles.

The Act-As flags populate the act_as record on the principal that Cedar Rules can reference. For example, a Rule that checks principal.act_as.roles.contains("admin") evaluates against the roles you provide.

Simulation accepts these claims as test input. Live requests must pass Delegated agents verification before the same values become available to Rules.

dome rules simulate \
  --agent support-agent \
  --action mcp:call \
  --resource customer-records \
  --resource-type mcp_tool \
  --actas-sub user-123 \
  --actas-email admin@example.com \
  --actas-roles admin,manager \
  --actas-groups support

{
  "agent_id": "support-agent",
  "action": "mcp:call",
  "resource": "customer-records",
  "resource_type": "mcp_tool",
  "actas_sub": "user-123",
  "actas_email": "admin@example.com",
  "actas_roles": "admin,manager",
  "actas_groups": "support"
}

POST /v1/authz/evaluate
Content-Type: application/json

{
  "caller": {
    "agent_id": "<agent-uuid>"
  },
  "action": "mcp:call",
  "resource": "customer-records",
  "resource_type": "mcp_tool",
  "workspace_id": "<workspace-uuid>",
  "act_as": {
    "sub": "user-123",
    "email": "admin@example.com",
    "roles": ["admin", "manager"],
    "groups": ["support"]
  }
}

Simulate authorization for agent "support-agent" doing mcp:call on mcp_tool "customer-records" acting as user "user-123" with email "admin@example.com" and roles "admin,manager".

Simulate with arguments

Pass per-call arguments when your Rules reference resource.arguments.<key> and you want to verify behavior for a specific payload. Top-level keys of the JSON object become Cedar keys on the resource. Refer to conditions on attributes or arguments for the full shape.

A Rule like resource.arguments.query like "*Atlas*" matches the example below. Keys whose JSON values are unrepresentable in Cedar (fractional floats, null, mixed-type lists) are dropped silently. Rules that reference them will not match.

dome rules simulate \
  --agent data-pipeline \
  --action mcp:call \
  --resource vector-search \
  --resource-type mcp_tool \
  --eval-arguments '{"query":"Atlas","limit":50}'

POST /v1/authz/evaluate
Content-Type: application/json

{
  "caller": { "agent_id": "<agent-uuid>" },
  "action": "mcp:call",
  "resource": "vector-search",
  "resource_type": "mcp_tool",
  "workspace_id": "<workspace-uuid>",
  "arguments": "eyJxdWVyeSI6IkF0bGFzIn0="
}

Read results

DecisionDiffs show where allow/deny outcomes would change between the current effective Rules and the candidate Rules. Each diff entry includes:

• The original decision (allow or deny) under the current Rules
• The new decision under the candidate Rules
• The specific event that produced the diff (agent, action, resource)
• The Rule that matched in each case

{
  "status": "completed",
  "total_events": 142,
  "decision_diffs": [
    {
      "event_id": "evt-...",
      "current": "allow",
      "candidate": "deny",
      "rule_id": "rule-..."
    }
  ]
}

Review diffs carefully before deploying. A simulation that shows no diffs means the candidate Rules produce identical outcomes for all historical events. It does not guarantee behavior for requests absent from that history. Add synthetic simulations for important unobserved cases.

Use historical replay to answer:

• Which previously allowed requests would a new forbid block?
• Which previously denied requests would a new permit allow?
• Do the candidate Rules preserve all observed outcomes?

Next steps

• Write and apply Rules through the normal Rule lifecycle
• Delegated agents so live Act-As claims match what you simulated
• Authorization model concept for entity attributes a simulation may reference