Authorization model

The authorization model is how Dome decides whether an agent may call a tool or model. Dome evaluates Cedar permit and forbid policies against a typed entity model on every governed request. Any matching forbid denies the request, and when no rule matches, the request is denied.

How a request is decided

Each request maps to one principal (Dome::Agent), one action (Dome::Action), and one resource (Dome::MCPTool or Dome::LLMModel). Conditions may also read request context and, when present, verified act-as claims on the principal.

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

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

Evaluation semantics

1. The evaluator checks every rule in the effective policy against the request.
2. If any forbid matches, the request is denied, regardless of any matching permit.
3. If no forbid matches and at least one permit matches, the request is allowed.
4. If no rule matches at all, the request is denied (default-deny / fail-closed).

forbid always wins. A forbid at organization scope cannot be overridden by a permit at agent scope. Design rules accordingly: broad restrictions at higher scopes, specific allowances at lower scopes.

Effective policy

The effective policy is the merged set of all active rule bundles across the scope hierarchy. Assembly works as follows:

1. Fetch the active bundle at each scope: organization, tenant, workspace, agent.
2. Merge Cedar files with scope-prefixed filenames (org/rules.cedar, workspace/rules.cedar) to prevent name collisions.
3. Compute a composite content hash from the merged file list.
4. Load the merged policy into the evaluator as a single PolicySet.

The gateway polls for content-hash changes on a sync interval (default: 10 seconds). When a bundle is deployed or rolled back, the hash changes and the gateway picks up the new policy on the next sync.

Per-workspace vs per-agent evaluation

Both evaluators enforce the same Cedar semantics. The hosted gateway adds per-workspace freshness checks. If a workspace's policy has not synced within its configured freshness window, the affected tool.call or model.call completes with result=denied and denial.reason=stale_policy.

Fail-closed behavior

The authorization model is fail-closed at every level:

• No matching rule: denied by default.
• Evaluator error: denied.
• Stale policy: denied (hosted gateway only, per-workspace freshness window).
• No policy loaded: denied.

Cedar itself has no permissive or audit-only mode. Use simulation to test rule changes before deploying.

Next steps

With that Cedar evaluation model in mind, continue with:

• Rules concept for bundles, scopes, and effective Rules
• Rules reference for entity, action, and attribute catalogs
• Authorize Access to write, validate, simulate, and apply Rules
• Permissions concept for platform RBAC (separate from Cedar)
• Scopes concept for the hierarchy that feeds effective policy