Skip to main content

​
Overview

Scope overrides allow you to modify inherited permissions at specific points in your scope hierarchy. This enables fine-grained control without restructuring your entire role and permission model.

​
Types of Overrides

Bedrock supports three types of overrides:
Override TypeWhat it ControlsUse Case
Role OverrideEnable/disable an entire role at a scopeDisable “Admin” role in production
Permission OverrideEnable/disable a specific permission at a scopeDisable “delete” permission in compliance areas
Role-Permission OverrideEnable/disable a specific permission for a specific role at a scopeDisable “write” for “Editor” role in archived projects

​
How Overrides Work

Overrides are applied during permission resolution: 
1. Get user's role assignments
2. Get permissions for those roles
3. Apply scope overrides (most specific scope wins)
4. Return effective permissions
Overrides only affect inherited permissions. They don’t grant new permissions—they can only enable or disable existing ones.

​
Role Overrides

Disable or enable an entire role at a specific scope.

​
Example: Disable Admin Role in Production

# Admin role is defined at org level
curl -X POST 'https://api.example.com/roles' \
  -d '{
    "name": "Admin",
    "description": "Full administrative access",
    "scopeId": "scope_org"
  }'

# Disable Admin role in production scope
curl -X POST 'https://api.example.com/scope-overrides/roles' \
  -H 'Content-Type: application/json' \
  -d '{
    "childScopeId": "scope_production",
    "roleId": "role_admin",
    "state": "disabled"
  }'
Now users with the Admin role won’t have admin access in the production scope.

​
Updating Role Overrides

# Re-enable the role
curl -X PUT 'https://api.example.com/scope-overrides/roles/override_123' \
  -d '{"state": "enabled"}'

​
Permission Overrides

Disable or enable a specific permission at a scope.

​
Example: Disable Delete Permission in Compliance Scope

# Delete permission exists at org level
curl -X POST 'https://api.example.com/permissions' \
  -d '{"name": "delete:records", "scopeId": "scope_org"}'

# Disable delete in compliance scope
curl -X POST 'https://api.example.com/scope-overrides/permissions' \
  -d '{
    "childScopeId": "scope_compliance",
    "permissionId": "perm_delete_records",
    "state": "disabled"
  }'

​
Example: Disable Code Execution for All Agents

# Disable execute permission in production
curl -X POST 'https://api.example.com/scope-overrides/permissions' \
  -d '{
    "childScopeId": "scope_production",
    "permissionId": "perm_execute_code",
    "state": "disabled"
  }'

​
Role-Permission Overrides

The most granular override: disable a specific permission for a specific role at a specific scope.

​
Example: Editors Can’t Delete in Archived Projects

# Editor role has delete permission at org level
curl -X POST 'https://api.example.com/role-permissions' \
  -d '{"roleId": "role_editor", "permissionId": "perm_delete"}'

# But not in archived projects
curl -X POST 'https://api.example.com/scope-overrides/role-permissions' \
  -d '{
    "childScopeId": "scope_archived_projects",
    "roleId": "role_editor",
    "permissionId": "perm_delete",
    "state": "disabled"
  }'

​
Example: Agents Can Read But Not Write in Sensitive Areas

# Agent role has both read and write
curl -X POST 'https://api.example.com/role-permissions' \
  -d '{"roleId": "role_agent_writer", "permissionId": "perm_read"}'

curl -X POST 'https://api.example.com/role-permissions' \
  -d '{"roleId": "role_agent_writer", "permissionId": "perm_write"}'

# Disable write for this role in customer data scope
curl -X POST 'https://api.example.com/scope-overrides/role-permissions' \
  -d '{
    "childScopeId": "scope_customer_data",
    "roleId": "role_agent_writer",
    "permissionId": "perm_write",
    "state": "disabled"
  }'

​
Override Precedence

When multiple overrides could apply, the most specific one wins: 
Organization (no overrides)
    ↓
Department (permission override: disable delete)
    ↓
Team (role-permission override: enable delete for Admin)
    ↓
Project (no overrides - inherits from Team)
In this example:
  • Most users can’t delete in the Department or below
  • But Admins CAN delete in the Team and Project (role-permission override)

​
Viewing Overrides

​
Get All Overrides for a Scope

# Role overrides
curl -X GET 'https://api.example.com/scope-overrides/roles/scope_production'

# Permission overrides
curl -X GET 'https://api.example.com/scope-overrides/permissions/scope_production'

# Role-permission overrides
curl -X GET 'https://api.example.com/scope-overrides/role-permissions/scope_production'

​
Deleting Overrides

# Delete by ID
curl -X DELETE 'https://api.example.com/scope-overrides/roles/override_123'

# Delete by scope and role
curl -X DELETE 'https://api.example.com/scope-overrides/roles/scope_production/role_admin'

# Delete role-permission override by all IDs
curl -X DELETE 'https://api.example.com/scope-overrides/role-permissions/scope_production/role_editor/perm_delete'

​
Common Patterns

​
Pattern 1: Production Lockdown

Restrict dangerous operations in production: 
# Disable multiple destructive permissions at once
curl -X POST 'https://api.example.com/scope-overrides/permissions/batch' \
  -H 'Content-Type: application/json' \
  -d '[
    {"childScopeId": "scope_prod", "permissionId": "perm_delete", "state": "disabled"},
    {"childScopeId": "scope_prod", "permissionId": "perm_execute", "state": "disabled"},
    {"childScopeId": "scope_prod", "permissionId": "perm_modify_infra", "state": "disabled"}
  ]'

​
Pattern 2: Agent Sandboxing

Restrict agent capabilities in sensitive areas: 
# Batch restrict agent permissions in sensitive scopes
curl -X POST 'https://api.example.com/scope-overrides/role-permissions/batch' \
  -H 'Content-Type: application/json' \
  -d '[
    {"childScopeId": "scope_customer_data", "roleId": "role_agent", "permissionId": "perm_write", "state": "disabled"},
    {"childScopeId": "scope_pii", "roleId": "role_agent", "permissionId": "perm_read", "state": "disabled"}
  ]'

​
Pattern 3: Temporary Restrictions

Apply temporary restrictions during incidents: 
# During incident: disable all writes
curl -X POST 'https://api.example.com/scope-overrides/permissions' \
  -d '{
    "childScopeId": "scope_affected_service",
    "permissionId": "perm_write",
    "state": "disabled"
  }'

# After incident: remove override
curl -X DELETE 'https://api.example.com/scope-overrides/permissions/scope_affected_service/perm_write'

​
Pattern 4: Compliance Zones

Create compliance zones with restricted access: 
# Set up multiple compliance zones at once
curl -X POST 'https://api.example.com/scope-overrides/permissions/batch' \
  -H 'Content-Type: application/json' \
  -d '[
    {"childScopeId": "scope_soc2", "permissionId": "perm_export_data", "state": "disabled"},
    {"childScopeId": "scope_hipaa", "permissionId": "perm_share_external", "state": "disabled"},
    {"childScopeId": "scope_hipaa", "permissionId": "perm_export_data", "state": "disabled"}
  ]'

​
Best Practices

Too many overrides make the system hard to understand. Prefer restructuring roles when possible.
Keep a record of why each override exists and when it should be reviewed.
Permission overrides are more granular and less likely to have unintended effects.
Before applying overrides in production, test in a staging environment.
Log all override creations, updates, and deletions for compliance.

​
Next Steps

User Governance

Apply overrides to user permissions

Agent Governance

Apply overrides to agent permissions