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, Bedrock evaluates in order:
  1. Resource Policies — Are there explicit allow/deny policies on this resource?
  2. Resource Hierarchy — Does a parent resource grant access (with cascade)?
  3. Role-Based Permissions — Does the subject’s role grant the action?
  4. Conditions — Do JSON Logic conditions on permissions/policies pass?
                    ┌─────────────────────┐
                    │  Resource Policies  │ ◀── Highest priority
                    └──────────┬──────────┘
                               │
                    ┌──────────▼──────────┐
                    │ Resource Hierarchy  │ ◀── Inherit from parents
                    └──────────┬──────────┘
                               │
                    ┌──────────▼──────────┐
Subject ──membership──▶ Scope ──▶ Role ──▶ Permission
                    └─────────────────────┘

​
Key Relationships

RelationshipDescription
Subject → ScopeA subject joins a scope via a Membership
Membership → RoleA membership is assigned one or more Roles via Role Assignments
Role → PermissionA role contains one or more Permissions via Role Permissions
Scope → ScopeScopes form a hierarchy via Scope Hierarchy Edges
Scope Type → Scope TypeScope types define valid parent-child relationships

​
Permission Inheritance

Permissions flow down the scope hierarchy: 
Organization (defines: Admin, Editor, Viewer roles)
    │
    ├── Team A (inherits roles, can override)
    │       │
    │       └── Project X (inherits from Team A)
    │
    └── Team B (inherits roles, can override)
            │
            └── Project Y (inherits from Team B)
A subject with the “Editor” role at the Organization level has Editor permissions in all child scopes—unless an override modifies that behavior.

​
Overrides

Bedrock supports three types of overrides to fine-tune inherited permissions:
Override TypeWhat it Controls
Role OverrideEnable/disable an entire role at a child scope
Permission OverrideEnable/disable a specific permission at a child scope
Role-Permission OverrideEnable/disable a specific permission for a specific role

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