> ## Documentation Index
> Fetch the complete documentation index at: https://docs.domesystems.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Authorization model

> How Cedar rules evaluate permit and forbid against the assembled effective policy

export const authorizationModel = "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.";

<p>
  {authorizationModel}
</p>

## 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.

```cedar title="examples.cedar" theme={"system"}
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.capabilities.contains("production:deploy")
};
```

### 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](/concepts/platform/scopes). 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

| Deployment                  | Evaluator                                                                      | Use case                         |
| --------------------------- | ------------------------------------------------------------------------------ | -------------------------------- |
| **Hosted gateway**          | `WorkspaceRuleEvaluator` maintains separate policy sets per assigned workspace | Multi-tenant shared gateway      |
| **SDK / dedicated runtime** | `RuleEvaluator` uses a single workspace policy set                             | Dedicated per-service deployment |

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](/concepts/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](/govern/rules/simulate) 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](/concepts/controls/rules) concept for bundles, scopes, and effective Rules
* [Rules](/reference/controls/rules) reference for entity, action, and attribute catalogs
* [Authorize Access](/govern/rules) to write, validate, simulate, and apply Rules
* [Permissions](/concepts/platform/permissions) concept for platform RBAC (separate from Cedar)
* [Scopes](/concepts/platform/scopes) concept for the hierarchy that feeds effective policy