Role-Based Access Control (RBAC) is the security model used in Prisme.ai to manage who can access, modify, and use different parts of your workspace. It ensures that users only have the permissions they need while protecting sensitive information and functionality.

​
RBAC Fundamentals

The RBAC system consists of several key elements:

  • Roles: Sets of permissions that can be assigned to users
  • Subjects: Resources that can be acted upon (pages, files, events, etc.)
  • Actions: Operations that can be performed on subjects (read, create, update, etc.)
  • Rules: Define which roles can perform which actions on which subjects
  • Conditions: Optional criteria that further restrict when rules apply

These components work together to create a flexible yet secure access control system.

​
Managing Roles and Rules

1

Accessing RBAC Settings

To view and edit your workspace’s access control configuration:

  1. Go to your workspace
  2. Navigate to Settings > Advanced > Manage Roles
  3. Edit the YAML configuration
  4. Save your changes

Changes to RBAC settings take effect immediately. Be careful not to lock yourself out!

2

Defining Roles

Create custom roles to fit your organization’s needs:

authorizations:
  roles:
    editor: {}  # Built-in role
    
    # Custom role for regular users
    user:
      auth:
        prismeai: {}  # Automatically assigned to all Prisme.ai users
        
    # Role for API access
    workspace:
      auth:
        apiKey: {}  # Can be used with API keys

The auth section allows you to automatically assign roles based on authentication providers.

3

Creating Rules

Define what each role can do with specific rules:

rules:
  # Allow editors to read and update workspaces
  - role: editor
    action:
      - read
      - get_usage
      - aggregate_search
      - update
    subject: workspaces
    
  # Give editors full control over files
  - role: editor
    action: manage  # Shorthand for all permissions
    subject: files

Each rule must include at least:

  • action: What can be done (a single action or list)
  • subject: What it can be done to (a single subject or list)

Rules can optionally specify:

  • role: Which role this applies to (if omitted, applies to everyone)
  • conditions: Restrict the rule to specific cases. If omitted (or an empty object), the rule will apply to every instance of specified subject
  • inverted: Set to true to make this a deny rule instead of allow
  • reason: Documentation string for the rule
4

Adding Conditions

Restrict rules to specific situations with conditions:

# Allow access only to pages with a "public" label
- action: read
  subject: pages
  conditions:
    labels:
      $in:
        - public

# Deny editor access to API key events
- role: editor
  inverted: true
  action: read
  subject: events
  conditions:
    type:
      $regex: ^apikeys\.*$

Conditions use a subset of MongoDB query syntax for powerful filtering.

​
Common RBAC Patterns

​
Subjects and Actions

RBAC controls access to various resource types through subject and action combinations:

​
Securing Automations

By default, anyone can execute any automation that has an event or endpoint trigger. To restrict access to sensitive automations:

1

Define Authorization Action

In your automation, specify an authorization requirement:

slug: getAnalytics
name: "Admin Page: Init Analytics"
description: "Restricted automation for admin use only"
when:
  events:
    - initAnalytics
do:
  - emit:
      event: updateAnalytics
      payload:
        data: [...]
authorizations:
  action: admin  # This is the authorization key

The authorizations.action field specifies a permission key for this automation.

2

Create Permission Rule

Define who can execute automations with this authorization key:

# Allow admin role to execute automations with "admin" authorization
- role: admin
  action: execute
  subject: automations
  conditions:
    authorizations.action:
      $in:
        - admin

This restricts execution only to users with the specified role.

3

Test the Restriction

Verify that:

  • Users with the admin role can execute the automation
  • Users without the admin role receive an authorization error
  • The automation cannot be called indirectly by other automations without permission

​
Using API Keys

​
Example RBAC Configuration

Here’s a complete example of a typical RBAC configuration:

​
Security Best Practices

Principle of Least Privilege

Give users only the permissions they actually need:

  • Start with minimal permissions and add as required
  • Use specific conditions to limit rule scope
  • Avoid “manage” permission when more specific actions suffice
  • Regularly review and prune unnecessary permissions

Secure Public Access

Carefully control what unauthenticated users can do:

  • Use explicit conditions on public rules
  • Limit event creation to specific event types
  • Be cautious with file upload permissions
  • Restrict user session events appropriately

Protect Sensitive Automations

Secure automations that access sensitive data:

  • Add authorization requirements to important automations
  • Create specific roles for administrative functions
  • Avoid sensitive data exposure through events
  • Test automations with different user roles

Manage API Access

Control programmatic access carefully:

  • Create API keys with minimal required permissions
  • Rotate API keys regularly
  • Monitor API key usage for unusual patterns
  • Delete unused API keys promptly

​
Troubleshooting

​
Next Steps

Authentication

Learn about user identity and authentication

API Security

Secure programmatic access to your workspaces

Automations

Explore automations and their security model

Enterprise Integration

Connect with SSO and enterprise identity systems