Row-Level Access Control

Overview

Row-level access control (RLAC) restricts access to individual records based on attributes of the user and the record. Instead of “can read all documents”, it’s “can read documents they own” or “can read documents in their department”.

Several patterns below are not enforced yet. A json-logic condition can only read what the engine puts in the context. Today that is: the acting subject (subject.id, subject.subjectType, subject.meta.*), the resource’s core fields (resource.id, resource.resourceType, resource.ownerScopeId, resource.displayName), the resource’s tags (top-level tags / tagList), the trusted clock (time.*), and any top-level custom context keys. It does not yet expose subject.tags.*, resource.createdBy, resource.ownerId, or resource.meta.*, so patterns using those never grant today (see the roadmap). Two things that work now: for owner-based access use resource ownership (an owns(subject, resource, role) grant) rather than a resource.createdBy condition; for attribute rules use resource tags and subject.meta.*. Also, conditions attach to the role-permission edge (condition), not a permission logic field.

Patterns

Pattern 1: Owner-Based Access

Users can only access resources they own:

# Create permission with owner condition
curl -X POST 'https://api.example.com/permissions' \
  -d '{
    "scopeId": "scope_org",
    "action": "read",
    "resourceType": "document",
    "resourcePattern": "*",
    "key": "document:read:owned",
    "label": "Read Own Documents",
    "logic": {
      "==": [{"var": "resource.createdBy"}, {"var": "subject.id"}]
    }
  }'

// Evaluation
const decision = await bedrock.evaluate({
  actor: { subjectId: "subject_jane", subjectType: "user" },
  scopeId: "scope_org",
  action: "read",
  resource: { resourceId: "resource_doc_123" }  // createdBy: "subject_jane"
});
// Result: ALLOWED (Jane owns this document)

Pattern 2: Department-Based Access

Users can access resources in their department:

# Tag users with departments
curl -X POST 'https://api.example.com/tag-assignments' \
  -d '{"tagId": "tag_engineering", "targetType": "subject", "targetId": "subject_jane"}'

# Tag resources with departments
curl -X POST 'https://api.example.com/tag-assignments' \
  -d '{"tagId": "tag_engineering", "targetType": "resource", "targetId": "resource_doc_123"}'

# Permission: Read documents in your department
curl -X POST 'https://api.example.com/permissions' \
  -d '{
    "scopeId": "scope_org",
    "action": "read",
    "resourceType": "document",
    "resourcePattern": "*",
    "key": "document:read:department",
    "logic": {
      "some": [
        {"var": "resource.tags.departments"},
        {"in": [{"var": ""}, {"var": "subject.tags.departments"}]}
      ]
    }
  }'

Pattern 3: Manager Access

Managers can access their reports’ data:

# Store reports in subject metadata
curl -X PATCH 'https://api.example.com/subjects/subject_manager' \
  -d '{
    "meta": {
      "directReports": ["subject_alice", "subject_bob", "subject_charlie"]
    }
  }'

# Permission: Read reports' timesheets
curl -X POST 'https://api.example.com/permissions' \
  -d '{
    "scopeId": "scope_org",
    "action": "read",
    "resourceType": "timesheet",
    "resourcePattern": "*",
    "key": "timesheet:read:reports",
    "logic": {
      "in": [{"var": "resource.ownerId"}, {"var": "subject.meta.directReports"}]
    }
  }'

Pattern 4: Project Team Access

Only project team members can access project resources:

# Tag users with projects
curl -X POST 'https://api.example.com/tag-assignments/batch' \
  -d '[
    {"tagId": "tag_project_alpha", "targetType": "subject", "targetId": "subject_jane"},
    {"tagId": "tag_project_alpha", "targetType": "subject", "targetId": "subject_bob"}
  ]'

# Tag resources with projects
curl -X POST 'https://api.example.com/tag-assignments' \
  -d '{"tagId": "tag_project_alpha", "targetType": "resource", "targetId": "resource_spec_doc"}'

# Permission
curl -X POST 'https://api.example.com/permissions' \
  -d '{
    "scopeId": "scope_org",
    "action": "read",
    "resourceType": "project-doc",
    "resourcePattern": "*",
    "key": "project-doc:read:team",
    "logic": {
      "some": [
        {"var": "resource.tags.projects"},
        {"in": [{"var": ""}, {"var": "subject.tags.projects"}]}
      ]
    }
  }'

Pattern 5: Geographic Restrictions

Access based on region:

# Permission: Access customer data in your region
curl -X POST 'https://api.example.com/permissions' \
  -d '{
    "scopeId": "scope_org",
    "action": "read",
    "resourceType": "customer",
    "resourcePattern": "*",
    "key": "customer:read:region",
    "logic": {
      "some": [
        {"var": "resource.tags.regions"},
        {"in": [{"var": ""}, {"var": "subject.tags.regions"}]}
      ]
    }
  }'

Pattern 6: Sensitivity Levels

Access based on clearance:

# Permission: Read documents at or below your clearance
curl -X POST 'https://api.example.com/permissions' \
  -d '{
    "scopeId": "scope_org",
    "action": "read",
    "resourceType": "document",
    "resourcePattern": "*",
    "key": "document:read:clearance",
    "logic": {
      ">=": [
        {"var": "subject.meta.clearanceLevel"},
        {"var": "resource.meta.requiredClearance"}
      ]
    }
  }'

Combining Conditions

Owner OR Department

{
  "or": [
    {"==": [{"var": "resource.createdBy"}, {"var": "subject.id"}]},
    {
      "some": [
        {"var": "resource.tags.departments"},
        {"in": [{"var": ""}, {"var": "subject.tags.departments"}]}
      ]
    }
  ]
}

Department AND Clearance

{
  "and": [
    {
      "some": [
        {"var": "resource.tags.departments"},
        {"in": [{"var": ""}, {"var": "subject.tags.departments"}]}
      ]
    },
    {
      ">=": [
        {"var": "subject.meta.clearanceLevel"},
        {"var": "resource.meta.requiredClearance"}
      ]
    }
  ]
}

Owner OR Manager OR Admin

{
  "or": [
    {"==": [{"var": "resource.createdBy"}, {"var": "subject.id"}]},
    {"in": [{"var": "resource.createdBy"}, {"var": "subject.meta.directReports"}]},
    {"var": "subject.meta.isAdmin"}
  ]
}

Implementation Patterns

Pre-Filtering Queries

For list views, pre-filter at the database level:

async function getAccessibleDocuments(userId: string, scopeId: string) {
  // Get user's effective permissions
  const permissions = await bedrock.listEffectivePermissions(userId, scopeId);

  // Extract conditions from permissions
  const conditions = extractConditions(permissions, "document", "read");

  // Build database query from conditions
  const query = buildQueryFromConditions(conditions, userId);

  return db.documents.find(query);
}

Post-Filtering Results

For complex conditions, filter after fetching:

async function filterAccessibleDocuments(
  documents: Document[],
  userId: string,
  scopeId: string
) {
  const accessible = [];

  for (const doc of documents) {
    const decision = await bedrock.evaluate({
      actor: { subjectId: userId, subjectType: "user" },
      scopeId,
      action: "read",
      resource: { resourceId: doc.bedrockResourceId }
    });

    if (decision.allowed) {
      accessible.push(doc);
    }
  }

  return accessible;
}

Checking Many Resources

There is no bulk evaluate API—call evaluate per resource, in parallel:

async function checkAccessMany(
  userId: string,
  scopeId: string,
  resourceIds: string[]
) {
  const decisions = await Promise.all(
    resourceIds.map((resourceId) =>
      bedrock.evaluate({
        actor: { subjectId: userId, subjectType: "user" },
        scopeId,
        action: "read",
        resource: { resourceId },
      })
    )
  );

  return resourceIds.filter((_, i) => decisions[i].allowed);
}

Performance Considerations

Cache permission evaluations

Cache decisions for the same user/resource/action combinations.

Pre-filter when possible

Convert simple conditions to database queries rather than post-filtering.

Evaluate in parallel, and cache

There is no bulk evaluate API; issue per-resource evaluate calls in parallel and cache decisions for repeated user/resource/action combinations.

Denormalize for read performance

Store computed access lists on resources for fast filtering.

Index tag assignments

Ensure tag assignments are indexed for fast lookups.

Best Practices

Keep conditions simple

Complex nested conditions are hard to debug and slow to evaluate.

Use tags for flexible classification

Tags are more flexible than hardcoded relationships.

Test edge cases

Test with users who have no tags, resources with no tags, etc.

Document your access model

Make it clear to your team how row-level access works.

Next Steps

Conditional Permissions

More JSON Logic patterns

Tag-Based Access

Deep dive into tag-based conditions

Getting Started

Core Concepts

Resources

Tags

Delegation

Use Cases

Modeling Guides

Row-Level Access Control

Overview

Patterns

Pattern 1: Owner-Based Access

Pattern 2: Department-Based Access

Pattern 3: Manager Access

Pattern 4: Project Team Access

Pattern 5: Geographic Restrictions

Pattern 6: Sensitivity Levels

Combining Conditions

Owner OR Department

Department AND Clearance

Owner OR Manager OR Admin

Implementation Patterns

Pre-Filtering Queries

Post-Filtering Results

Checking Many Resources

Performance Considerations

Best Practices

Next Steps

Conditional Permissions

Tag-Based Access

​Overview

​Patterns

​Pattern 1: Owner-Based Access

​Pattern 2: Department-Based Access

​Pattern 3: Manager Access

​Pattern 4: Project Team Access

​Pattern 5: Geographic Restrictions

​Pattern 6: Sensitivity Levels

​Combining Conditions

​Owner OR Department

​Department AND Clearance

​Owner OR Manager OR Admin

​Implementation Patterns

​Pre-Filtering Queries

​Post-Filtering Results

​Checking Many Resources

​Performance Considerations

​Best Practices

​Next Steps

Conditional Permissions

Tag-Based Access

Overview

Patterns

Pattern 1: Owner-Based Access

Pattern 2: Department-Based Access

Pattern 3: Manager Access

Pattern 4: Project Team Access

Pattern 5: Geographic Restrictions

Pattern 6: Sensitivity Levels

Combining Conditions

Owner OR Department

Department AND Clearance

Owner OR Manager OR Admin

Implementation Patterns

Pre-Filtering Queries

Post-Filtering Results

Checking Many Resources

Performance Considerations

Best Practices

Next Steps