Authorization & policy (Cedar)

Authorization is the core of the gateway. Every discovery request and every tool call is evaluated by the Cedar policy engine against four inputs: the principal (user or agent), the action (discover, call, …), the resource (server, tool, or generated API operation), and the context (environment, client surface, credential mode, delegation).

The decision is default‑deny

Cedar evaluates each request as a ladder: an explicit deny always wins, an explicit allow permits, and anything unmatched is denied by default — and hidden.

1. Explicit deny wins. A matching forbid overrides any permit. This is how break‑glass and revocation take effect immediately.
2. Explicit allow permits. A matching permit with no overriding forbid lets the call proceed.
3. Default deny. Anything not explicitly allowed is denied — and not just refused at call time.

Discovery is policy‑filtered

A denied tool isn’t shown as locked — it is absent from discovery entirely. Two agents pointed at the same gateway can see two different catalogs. This means an agent can’t even learn that a capability exists unless policy allows it, which removes a whole class of enumeration and social‑engineering risks.

Policies are versioned

Policies move through a lifecycle — draft → validate → publish, with archive and supersede. Every authorization decision records the policy version that produced it, so an audit event is always attributable to an exact, immutable policy. See Simulate a policy decision to test changes before publishing.

Reasoning about a denial

When a call is denied, the gateway returns a stable machine reason plus a human‑readable diagnosis with the matched (or missing) rule and the policy version — never the request payload or secrets. That’s enough to fix the policy without leaking anything sensitive.

See it illustrated See default-deny and policy-filtered discovery illustrated, including a tool disappearing when policy changes.