Skip to main content

​
Overview

Bedrock is an authorization engine built around a few core primitives that compose together to create flexible, hierarchical access control. Understanding these concepts is essential before diving into implementation.

Scopes

Hierarchical containers that define authorization boundaries

Scope Types

Templates that define how scopes behave and inherit permissions

Subjects

Entities that can be granted permissions (users, agents, services)

Roles

Named collections of permissions assigned to subjects

Permissions

Fine-grained access rights for actions on resources

Conditional Permissions

Dynamic access control with JSON Logic expressions

Scope Overrides

Fine-tune inherited permissions at child scopes

Evaluation

How Bedrock decides if an action is allowed

​
The Bedrock Model

At its core, Bedrock answers one question:
Can this subject perform this action on this resource in this scope?
To answer this, the engine works through several legs—roughly in this order:
  1. Reachability gate (when resource-scope gating is enabled) — Is the resource reachable in this scope at all? If not, the request is denied outright.
  2. Delegation (when acting on behalf of another subject) — An active delegation grant must exist, and the agent and the principal must each independently pass. A delegated allow is the intersection of the two.
  3. Resource Policies — Explicit allow/deny policies attached to the resource. Evaluated before RBAC; a policy deny wins.
  4. Role-Based Permissions (RBAC) — Does a role the subject holds grant the action? Roles are composed across the scope chain per the scope’s permissionMode, and any conditions must pass.
  5. Ownership — Does the subject own the resource with a role that grants the action?
  6. Resource Hierarchy — Only if still denied and the resource has ancestors: does a parent resource grant access (via a cascade link)?
These are not all strict priority tiers—several are conditional legs (delegation runs only for on-behalf-of requests; the hierarchy fallback runs only when direct RBAC denies and a concrete resource is present). See Evaluation for the exact flow.

​
Key Relationships

​
Permission Inheritance

Whether permissions flow down the scope hierarchy depends on each scope’s permissionMode:
  • override (the default) — grants apply only at the scope where the subject is a member. A role at the Organization scope does not reach child scopes.
  • inherit — a child scope with no grants of its own falls back to the nearest ancestor that has grants.
  • additive — a child scope’s grants are the union of its own and all ancestor grants.
Do not assume a role assigned at a parent scope automatically applies to child scopes. Under the default override mode it does not—downward inheritance requires the child scope’s type to use inherit or additive. Scope overrides can then further disable or adjust inherited grants.

​
Overrides

Bedrock supports three types of overrides to fine-tune inherited permissions:

Learn about Scope Overrides

See how to use overrides for fine-grained control

​
Next Steps

Scopes

Start with scopes—the foundation of Bedrock’s hierarchy

Quickstart

Jump straight into building with Bedrock