Skip to main content

​
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.
examples.cedar

​
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, requests are denied with a authorization.staleness_rejected audit event.

​
Fail-closed behavior

The authorization model is fail-closed at every level:
  • No matching rule: denied. When Intelligent Authorization convenes on live traffic, a no_match in a live-mode workspace can be overridden by a Court permit. Until then no_match always resolves to the default-deny.
  • Evaluator error: denied.
  • Stale policy: denied (hosted gateway only, per-workspace freshness window).
  • No policy loaded: denied.
  • Court unavailable: denied with reason: "court_unavailable" when fewer than two judges return a usable vote.
Cedar itself has no permissive or audit-only mode. Use simulation to test rule changes before deploying. Intelligent Authorization audit mode is a separate construct. It records Court rulings without enforcing them so you can validate the panel before flipping to live.

​
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