Rules

Rules decide which tool and model requests each agent is allowed to make. Dome evaluates them on every governed request, so you can grant, restrict, or deny access down to the specific action and condition.

Overview

Rules ship as scoped bundles of .cedar files. The gateway merges every active bundle that covers the agent and evaluates the request against that set.

The typical workflow is:

1. Write Rules manually or with the Rules assistant.
2. Validate the Rules for Cedar errors and advisory warnings.
3. Simulate representative decisions before changing production behavior.
4. Apply the Rules to activate the change.
5. Inspect the Rules that apply to an agent and roll back if the result is not expected.

Requirements

Before you begin:

• Authenticate to Dome and select a workspace
• Register at least one agent
• Identify the tools or models the Rules will govern
• Choose the workspace or agent scope where the Rules should apply

Permissions

Rule bundle operations require platform permissions. Each operation states its required permission inline.

Write Rules

Write each authorization requirement as a sentence before translating it to Cedar. For example, “Allow this agent to call the github/list_issues tool.”

You can also use the Rules assistant to translate natural-language requirements into a draft. Assistant drafts never deploy automatically.

Map the sentence to a Rule in five steps.

1. Choose permit for an allowed request or forbid for a denied request.
2. Set the principal to the agent's UUID or use a broader form when the Rule should cover every agent in scope.
3. Choose the action that represents the operation.
4. Set the resource to the specific tool or model, or use a resource type when the Rule should cover every resource of that type.
5. Add a when condition if the Rule should apply only under certain circumstances or add unless to define an exception.

Inside the parentheses, name principal, action, and resource. Omit a constraint to match every value. Use == for one entity, is for every entity of a type, and in for several actions. Common actions are mcp:call, mcp:discover, and LLM actions such as llm:invoke, llm:embed, and llm:moderate. Connection attributes appear as resource.<key>. Per-call values appear as resource.arguments.<key> after resource has arguments. The full action catalog and attribute tables are on the Rules reference.

Author in the dashboard

The Rules editor supports a Visual Builder alongside raw Cedar. The Builder is a form for the common shape: effect (permit, forbid), principal, one or more actions, a resource, and when / unless conditions. Dropdowns are sourced from your workspace catalog (agents, tools, models, pools, attribute keys). Cedar renders live in the preview pane.

Toggle Builder ↔ Cedar on the editor toolbar. In-progress form state is preserved across the switch. Builder-generated Rules parse back into the form on reopen. Rules the Builder cannot model (custom annotations, cross-clause ||, set helpers outside the Builder's operators) render as a raw card and open in the code editor.

Create rule opens a scope picker — workspace bundle or a specific agent's bundle. Edit links from elsewhere in the dashboard skip the picker and open the bundle directly.

The Rules screen can also show the read-only Effective Rules view for a chosen agent: the resolved policy across organization, tenant, workspace, and agent scopes, grouped into scope cards in precedence order. Filter, search, expand Cedar, or open Simulate from any row.

Permit a tool call

Replace AGENT_ID with the registered agent's UUID. The tool resource uses CONNECTION_NAME/TOOL_NAME.

permit(
  principal == Dome::Agent::"AGENT_ID",
  action == Dome::Action::"mcp:call",
  resource == Dome::MCPTool::"github/list_issues"
);

Discovery is a different action. A Rule that only permits mcp:discover does not allow tool calls.

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

Forbid with an exception

Deny a sensitive tool for everyone, then carve out agents whose metadata marks them for it. Guard the read with has first, because an agent without that metadata key errors the Rule out instead of matching it.

forbid(
  principal,
  action == Dome::Action::"mcp:call",
  resource == Dome::MCPTool::"deployment/production-deploy"
) unless {
  principal has metadata &&
  principal.metadata has deploy_target &&
  principal.metadata.deploy_target == "production"
};

Condition on attributes or arguments

Gate an LLM call on a connection attribute (resource.<key>) or a per-call argument (resource.arguments.<key>). Guard argument reads with resource has arguments first. Dereferencing a missing argument errors the Rule out.

permit(
  principal,
  action == Dome::Action::"llm:embed",
  resource is Dome::LLMModel
)
when {
  resource.pii_certified == true
};

forbid(
  principal,
  action == Dome::Action::"mcp:call",
  resource == Dome::MCPTool::"vector-search"
)
when {
  resource has arguments &&
  resource.arguments has query &&
  resource.arguments.query like "*Atlas*"
};

A .cedar file can contain multiple Rules.

Include every user-authored file that should remain active at the target scope because Apply Rules replaces the current user-authored bundle.

After writing the files, validate the Rules before simulation or deployment.

Validate Rules

Validate one or more Cedar files without deploying them. Validation returns blocking Cedar errors and advisory warnings for resource references.

dome rules validate rules.cedar

{
  "files": [
    {
      "name": "rules.cedar",
      "content": "permit(principal == Dome::Agent::\"data-pipeline\", action == Dome::Action::\"mcp:call\", resource == Dome::MCPTool::\"database-query\");"
    }
  ]
}

POST /v1/rules/validate
Content-Type: application/json

{
  "files": [
    {
      "name": "rules.cedar",
      "content": "permit(principal == Dome::Agent::\"data-pipeline\", action == Dome::Action::\"mcp:call\", resource == Dome::MCPTool::\"database-query\");"
    }
  ],
  "scope_kind": "workspace",
  "scope_id": "{{WORKSPACE_ID}}"
}

Validate rules.cedar for the active workspace and explain every error or warning.

Simulate Rules

Simulate an authorization decision against the Rules currently in effect without performing the requested action. Supply the agent, action, resource, and any request context the Rules inspect.

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_ID}}"
  },
  "action": "mcp:call",
  "resource": "database-query",
  "resource_type": "mcp_tool",
  "workspace_id": "{{WORKSPACE_ID}}"
}

Simulate whether "data-pipeline" may call the "database-query" MCP tool.

Refer to Simulate Rules for request arguments, Agent Act-As claims, and historical replay.

Apply Rules

Apply one or more Cedar files to replace the active user-authored bundle at a target scope. Each successful apply creates a bundle with a new sequence number and content hash.

dome rules apply rules.cedar --name "production-v2"

{
  "files": [
    {
      "name": "rules.cedar",
      "content": "permit(principal == Dome::Agent::\"data-pipeline\", action == Dome::Action::\"mcp:call\", resource == Dome::MCPTool::\"database-query\");"
    }
  ],
  "name": "production-v2",
  "scope_kind": "workspace",
  "scope_id": "{{WORKSPACE_ID}}"
}

POST /v1/rules
Content-Type: application/json

{
  "files": [
    {
      "name": "rules.cedar",
      "content": "permit(principal == Dome::Agent::\"data-pipeline\", action == Dome::Action::\"mcp:call\", resource == Dome::MCPTool::\"database-query\");"
    }
  ],
  "scope_kind": "workspace",
  "scope_id": "{{WORKSPACE_ID}}",
  "name": "production-v2"
}

Apply rules.cedar to the active workspace as a bundle named "production-v2".

After applying Rules, show the effective Rules to confirm that the new bundle contributes to the expected agents. Gateways pick up the change through effective Rules caching. Allow time for the next sync before testing requests.

Show effective Rules

Show the Rules that apply to an agent after Dome assembles organization, tenant, workspace, agent, and generated bundles. The result includes a content hash for gateway synchronization and the contributing bundles that formed the effective Rules.

dome rules show --agent data-pipeline

GET /v1/agents/{{AGENT_ID}}/policies?workspace_id={{WORKSPACE_ID}}

Show every Rule that applies to "data-pipeline" and identify the contributing bundles.

Get active Rules at a scope

Get the currently active user-authored Rules at one scope when you need that scope's files rather than the assembled effective Rules.

{
  "scope_kind": "workspace",
  "scope_id": "{{WORKSPACE_ID}}"
}

GET /v1/rules/active?scope_kind=workspace&scope_id={{WORKSPACE_ID}}

Get the active user-authored Rules for the current workspace.

List Rule history

List deployment history at a scope to retrieve IDs, names, sequence numbers, timestamps, and active status. Use an ID when you roll back Rules.

dome rules list --limit 20

{
  "scope_kind": "workspace",
  "scope_id": "{{WORKSPACE_ID}}",
  "limit": 20
}

GET /v1/rules?scope_kind=workspace&scope_id={{WORKSPACE_ID}}&limit=20

List the 20 most recent Rule deployments for the active workspace.

Roll back Rules

Roll back to a historical user-authored bundle when a deployment produces an unexpected authorization result. Rollback creates a new bundle from the selected historical content and preserves the original deployment.

Generated bundles (kind=generated, labeled by generator — allowed resources, Act-As, blocked tools, and similar) appear in deployment history for lineage, but they are not rollback targets. The dashboard hides rollback for those rows. Diffs are scoped to the same lineage (scope + kind + generator). Change generated content through the feature that created it, not by rolling back a user-authored bundle over it.

dome rules rollback {{BUNDLE_ID}}

{
  "bundle_id": "{{BUNDLE_ID}}"
}

POST /v1/rules/rollback
Content-Type: application/json

{
  "bundle_id": "{{BUNDLE_ID}}"
}

Roll back to Rule bundle "{{BUNDLE_ID}}" and confirm the new active bundle.

After rollback, show the effective Rules to confirm that the restored content contributes at the expected scope.

Delete Rules

Delete the active user-authored Rules at a scope when that scope should no longer contribute custom Rules. Deletion preserves bundle history for later inspection.

DELETE /v1/rules?scope_kind=workspace&scope_id={{WORKSPACE_ID}}

Delete the active user-authored Rules from the current workspace while preserving bundle history.

After deletion, list Rule history and show effective Rules to confirm the resulting authorization state.

Generate starter Rules

Generate a static Cedar template with one active Rule that lets every agent discover available tools. The template also includes a commented example for permitting calls to one MCP tool.

The generated Rules do not permit tool calls, inspect registered tools, or change active Rules. The --from-tools flag produces the same static template.

dome rules generate --output starter.cedar

{}

Generate a starter Cedar template with a tool-discovery permit and a commented example for permitting a tool call.

Validate and simulate the generated file before applying it.

Next steps

• Rules concept for how authorization decisions work
• Rules reference for actions and attributes
• Draft with the Rules assistant when you prefer natural-language drafts
• Simulate Rules to probe decisions and replay history
• Authorization model concept for evaluation semantics