Roles & Permissions

Overview

Roles and permissions in Peridot define who can access systems, view data, and enforce governance policies across your organization.

They are the foundation of secure operation and ensure that control over AI systems is restricted, auditable, and aligned with organizational responsibilities.

Peridot uses role-based access control (RBAC) with support for custom roles and fine-grained permissions.

Why This Matters

Without proper access control:

  • Unauthorized users may access sensitive data

  • Policies may be modified without oversight

  • Incidents may not be properly contained

  • Auditability is compromised

RBAC ensures that governance is enforced not just at the system level, but at the user level.

Default Roles

Peridot provides four default roles:

Admin

Full control over the system.

Permissions include:

  • Manage users and roles

  • Configure integrations

  • Create and modify policies

  • Access all data and logs

  • Configure system settings

Use case: Platform owners, senior infrastructure or security leads

Security Admin

Focused on governance and risk control.

Permissions include:

  • Create and manage policies

  • View all data flows and incidents

  • Access audit logs

  • Configure enforcement rules

Use case: Security engineering, GRC teams

Operator

Responsible for monitoring and responding.

Permissions include:

  • View inventory and data flows

  • Monitor incidents

  • Trigger manual actions

  • View policy outcomes

Use case: Security operations, incident response teams

Viewer

Read-only access.

Permissions include:

  • View dashboards and reports

  • Access audit logs (read-only)

  • Observe system activity

Use case: Auditors, compliance teams, leadership

Custom Roles

Organizations can define custom roles to meet specific requirements.

Custom roles allow:

  • Fine-grained permission control

  • Separation of duties

  • Alignment with internal access models

Example Custom Roles

  • Policy Reviewer — Can view and approve policies but not create

  • Integration Admin — Manages integrations without access to policies

  • Audit Analyst — Full access to logs without system control

Permission Categories

Permissions are grouped into key areas:

Identity & Access

  • Manage users and groups

  • Assign roles

  • Configure SSO and provisioning

Governance

  • Create and edit policies

  • Configure enforcement actions

  • Manage routing rules

Observability

  • View data flows

  • Access AI inventory

  • Monitor system activity

Incidents

  • View incidents

  • Triage and respond

  • Trigger workflows

System Configuration

  • Manage integrations

  • Configure model providers

  • Control API access

Resource-Level Access

Permissions can be scoped to specific resources:

  • Workspaces

  • Environments

  • Integrations

  • Applications

This allows organizations to restrict access to specific systems or teams.

Environment-Based Access

Access can also be restricted by environment:

  • Development

  • Staging

  • Production

Example:

  • Developers may have full access in dev

  • Limited access in production

  • No access to sensitive systems

Best Practices

To maintain secure access control:

  • Use least privilege by default

  • Separate administrative and operational roles

  • Restrict policy editing to trusted users

  • Regularly review role assignments

  • Audit access through logs

In Production

In a production deployment:

  • All access is controlled through RBAC

  • Role assignments are enforced across environments

  • Permissions are auditable

  • Sensitive operations are restricted

Next Steps

  • Configure access in Members and Groups

  • Enable SSO in Identity & Access

  • Review activity in Audit Logs


Was this article helpful?