Tag-Based Access Control

Not yet enforced — see the roadmap. This page describes subject-tag matching (comparing a subject’s tags to a resource’s tags). The engine does not currently load subject tags into evaluation, so subject.tags.* is always undefined and the matching patterns below never grant today. For attribute-based rules you can use right now: resource-side tag conditions, subject.meta.* attributes, resource policies, and resource ownership. The examples below describe the intended model. Also note that conditions attach to the role-permission edge (condition), not a permission logic field.

Overview

Tag-based access control (ABAC) uses tags on subjects and resources to make dynamic authorization decisions. Instead of static role assignments, access is determined by matching attributes. Example: “Users can read documents tagged with their department.”

How It Works

Tag subjects with attributes (department, clearance, skills)
Tag resources with attributes (department, sensitivity, category)
Create permissions with JSON Logic conditions that compare tags
Evaluation checks if the subject’s tags match the resource’s tags

Basic Tag Matching

Department Match

Users can only access documents in their department:

# 1. Create department tags
curl -X POST 'https://api.example.com/tags/batch' \
  -d '[
    {"tagGroupId": "tg_dept", "identifier": "engineering", "label": "Engineering"},
    {"tagGroupId": "tg_dept", "identifier": "finance", "label": "Finance"}
  ]'

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

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

# 4. Create permission with tag condition
curl -X POST 'https://api.example.com/permissions' \
  -d '{
    "scopeId": "scope_org",
    "action": "read",
    "resourceType": "document",
    "resourcePattern": "*",
    "key": "document:read:*:dept-match",
    "label": "Read Department Documents",
    "logic": {
      "some": [
        {"var": "resource.tags.departments"},
        {"in": [{"var": ""}, {"var": "subject.tags.departments"}]}
      ]
    }
  }'

Evaluation

const decision = await bedrock.evaluate({
  actor: { subjectId: "subject_jane", subjectType: "user" },
  scopeId: "scope_org",
  action: "read",
  resource: { resourceId: "resource_doc_123" },
  includeResourceTags: true  // Load resource tags automatically
});

// Jane has tag: engineering
// Document has tag: engineering
// Condition: engineering in [engineering] = true
// Result: allowed = true

JSON Logic Patterns

Any Tag Matches

Subject has at least one tag that matches the resource:

{
  "some": [
    {"var": "resource.tags.departments"},
    {"in": [{"var": ""}, {"var": "subject.tags.departments"}]}
  ]
}

All Tags Required

Subject must have ALL tags the resource has:

{
  "all": [
    {"var": "resource.tags.departments"},
    {"in": [{"var": ""}, {"var": "subject.tags.departments"}]}
  ]
}

Specific Tag Required

Resource must have a specific tag:

{
  "in": ["public", {"var": "resource.tags.sensitivity"}]
}

Clearance Level

Subject’s clearance must meet or exceed resource’s requirement:

{
  ">=": [
    {"var": "subject.meta.clearanceLevel"},
    {"var": "resource.meta.requiredClearance"}
  ]
}

Combined Conditions

Multiple conditions with AND/OR:

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

Common Patterns

Pattern 1: Department-Based Access

# 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:dept",
    "logic": {
      "some": [
        {"var": "resource.tags.departments"},
        {"in": [{"var": ""}, {"var": "subject.tags.departments"}]}
      ]
    }
  }'

Pattern 2: Sensitivity Levels

# Permission: Read based on clearance
curl -X POST 'https://api.example.com/permissions' \
  -d '{
    "scopeId": "scope_org",
    "action": "read",
    "resourceType": "document",
    "resourcePattern": "*",
    "key": "document:read:clearance",
    "logic": {
      "or": [
        {"in": ["public", {"var": "resource.tags.sensitivity"}]},
        {
          "and": [
            {"in": ["internal", {"var": "resource.tags.sensitivity"}]},
            {"var": "subject.isEmployee"}
          ]
        },
        {
          "and": [
            {"in": ["confidential", {"var": "resource.tags.sensitivity"}]},
            {">=": [{"var": "subject.meta.clearanceLevel"}, 2]}
          ]
        },
        {
          "and": [
            {"in": ["restricted", {"var": "resource.tags.sensitivity"}]},
            {">=": [{"var": "subject.meta.clearanceLevel"}, 3]}
          ]
        }
      ]
    }
  }'

Pattern 3: Labor Class Matching (Construction)

# Workers can only access jobs matching their certifications
curl -X POST 'https://api.example.com/permissions' \
  -d '{
    "scopeId": "scope_org",
    "action": "view",
    "resourceType": "job",
    "resourcePattern": "*",
    "key": "job:view:labor-match",
    "logic": {
      "some": [
        {"var": "resource.tags.labor-classes"},
        {"in": [{"var": ""}, {"var": "subject.tags.labor-classes"}]}
      ]
    }
  }'

Pattern 4: Project Team Access

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

Pattern 5: Geographic Restrictions

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

Context Variables

In tag-based conditions, you have access to:

Variable	Description
`subject.id`	Subject’s Bedrock ID
`subject.subjectType`	Subject type (`user`, `agent`, `service`, `api_key`)
`subject.meta.*`	Subject metadata fields
`subject.tags.*`	Subject’s tags — planned, not loaded yet (see roadmap)
`resource.id`	Resource’s Bedrock ID
`resource.resourceType`	Resource type key
`resource.ownerScopeId`	Resource’s owner scope
`tags.<identifier>` / `tagList`	Resource tags — a top-level identifier→label map plus an array (not `resource.tags`)
`time.hour` / `time.dayOfWeek`	Trusted server clock
`<your keys>`	Custom `context` keys, spread at top level

There is no resource.meta, resource.type, or subject.type in the condition context—use resource.resourceType and subject.subjectType, and put custom data in subject.meta, resource tags, or top-level context keys.

Debugging Tag Conditions

The evaluation response includes context for debugging:

const decision = await bedrock.evaluate({
  actor: { subjectId: "subject_jane", subjectType: "user" },
  scopeId: "scope_org",
  action: "read",
  resource: { resourceId: "resource_doc_123" },
  includeResourceTags: true
});

// The engine exposes the RESOURCE's tags at the top level of the condition
// context as `tags` (identifier -> label) and `tagList`. The acting subject's
// tags are NOT loaded yet (see the roadmap), so there is no `subject.tags`.

console.log(decision.explanation);
// e.g. "No permission for read:document in scope scope_org"

Best Practices

Keep conditions simple

Complex nested conditions are hard to debug. Break them into multiple permissions if needed.

Test with edge cases

Test with subjects/resources that have no tags, multiple tags, and mismatched tags.

Document your conditions

Use the permission’s description field to explain what the condition does.

Combine with role-based access

Tag-based conditions work alongside roles. A subject still needs the permission via a role.

Getting Started

Core Concepts

Resources

Tags

Delegation

Use Cases

Modeling Guides

Tag-Based Access Control

Overview

How It Works

Basic Tag Matching

Department Match

Evaluation

JSON Logic Patterns

Any Tag Matches

All Tags Required

Specific Tag Required

Clearance Level

Combined Conditions

Common Patterns

Pattern 1: Department-Based Access

Pattern 2: Sensitivity Levels

Pattern 3: Labor Class Matching (Construction)

Pattern 4: Project Team Access

Pattern 5: Geographic Restrictions

Context Variables

Debugging Tag Conditions

Best Practices

Next Steps

Delegation

Conditional Permissions

​Overview

​How It Works

​Basic Tag Matching

​Department Match

​Evaluation

​JSON Logic Patterns

​Any Tag Matches

​All Tags Required

​Specific Tag Required

​Clearance Level

​Combined Conditions

​Common Patterns

​Pattern 1: Department-Based Access

​Pattern 2: Sensitivity Levels

​Pattern 3: Labor Class Matching (Construction)

​Pattern 4: Project Team Access

​Pattern 5: Geographic Restrictions

​Context Variables

​Debugging Tag Conditions

​Best Practices

​Next Steps

Delegation

Conditional Permissions

Overview

How It Works

Basic Tag Matching

Department Match

Evaluation

JSON Logic Patterns

Any Tag Matches

All Tags Required

Specific Tag Required

Clearance Level

Combined Conditions

Common Patterns

Pattern 1: Department-Based Access

Pattern 2: Sensitivity Levels

Pattern 3: Labor Class Matching (Construction)

Pattern 4: Project Team Access

Pattern 5: Geographic Restrictions

Context Variables

Debugging Tag Conditions

Best Practices

Next Steps