> ## Documentation Index > Fetch the complete documentation index at: https://docs.bedrock.quarry-systems.com/llms.txt > Use this file to discover all available pages before exploring further. # Core Concepts > Understanding the fundamental building blocks of Bedrock authorization ## 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. Hierarchical containers that define authorization boundaries Templates that define how scopes behave and inherit permissions Entities that can be granted permissions (users, agents, services) Named collections of permissions assigned to subjects Fine-grained access rights for actions on resources Dynamic access control with JSON Logic expressions Fine-tune inherited permissions at child scopes 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](/delegation) 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`](/concepts/scope-types), and any [conditions](/concepts/conditional-permissions) 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)? ``` reachability? → delegation (if on-behalf-of) → resource policies → RBAC → ownership → resource-hierarchy fallback → decision ``` 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](/concepts/evaluation) for the exact flow. ## Key Relationships | Relationship | Description | | --------------------------- | ----------------------------------------------------------------------- | | **Subject → Scope** | A subject joins a scope via a **Membership** | | **Membership → Role** | A membership is assigned one or more **Roles** via **Role Assignments** | | **Role → Permission** | A role contains one or more **Permissions** via **Role Permissions** | | **Scope → Scope** | Scopes form a hierarchy via **Scope Hierarchy Edges** | | **Scope Type → Scope Type** | Scope types define valid parent-child relationships | ## Permission Inheritance Whether permissions flow down the scope hierarchy depends on each scope's [`permissionMode`](/concepts/scope-types): * **`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. ``` Organization (Editor assigned here) │ ├── Team A ← Editor reaches here only if Team A's type is `inherit` or `additive` │ │ │ └── Project X │ └── Team B ``` 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](/concepts/overrides) can then further disable or adjust inherited grants. ## Overrides Bedrock supports three types of overrides to fine-tune inherited permissions: | Override Type | What it Controls | | ---------------------------- | -------------------------------------------------------------------- | | **Role Override** | Activate or deactivate an entire role at a specific scope | | **Permission Override** | Activate or deactivate a specific permission at a specific scope | | **Role-Permission Override** | Grant or revoke a specific permission for a specific role at a scope | See how to use overrides for fine-grained control ## Next Steps Start with scopes—the foundation of Bedrock's hierarchy Jump straight into building with Bedrock