Roles and permissions

Praxis splits authorization across two RBAC apps that work together:

• idm — Identity Management. Owns users, organizations, tenants, invitations, SSO, and API tokens.
• praxis — The pipeline product. Owns pipelines, collectors, sources, destinations, packs, monitors, credentials, and the live-tail stream.

Both apps share the same four role names — viewer, member, admin, owner — so the role you hold on your organization in idm automatically grants the equivalent scope on the praxis side. Permissions inherit up the chain (an admin holds everything member does, plus extras), and a small number of cross-app claims let an admin in praxis reach into the relevant identity surfaces without explicit double-assignment.

Authorization is server-enforced: every API call goes through Oathkeeper and the identity-service permission chain before reaching a handler. The UI also gates write CTAs on the same permission strings — if a button is hidden in the product, the corresponding API will refuse the request anyway.

---

Role summary

The fastest way to read this page: pick a role and skim down the column.

Capability	Viewer	Member	Admin	Owner
Read pipelines, collectors, sources, destinations, monitors, credentials, packs	✓	✓	✓	✓
View live-tail telemetry	✓	✓	✓	✓
Create / edit pipelines, sources, destinations, packs	—	✓	✓	✓
Subscribe to / clone packs	—	✓	✓	✓
Publish a pipeline (push config to collectors)	—	✓	✓	✓
Manage collectors (register, restart, reload pipeline, upgrade, deregister)	—	✓	✓	✓
Use the AI assistant (regex, processor, security recommendations)	—	✓	✓	✓
Create / edit monitors and notification channels	—	✓	✓	✓
Create / edit credentials	—	—	✓	✓
Manage organization members, create tenants, configure SSO and API tokens	—	—	✓	✓
Delete pipelines, collectors, packs	—	—	—	✓
Delete an organization or a tenant	—	—	—	✓

A user's effective permissions come from the role they hold per organization (and per tenant where applicable). A user can be a viewer in one organization and an owner in another at the same time.

---

What each role can do

Viewer — read-only, "I just need to see what's running"

Best for stakeholders who need visibility into pipelines, monitors, and telemetry health without making changes.

Can do:

• Browse the Overview, Pipelines, Collectors, Sources, Destinations, Monitors, Packs, and Credentials lists.
• Open a pipeline, source, destination, monitor, or pack and read its configuration and current state.
• Subscribe to live-tail to watch telemetry flow.
• View their own profile, the organization, and tenant details.

Cannot do:

• Create, edit, or delete any pipeline, source, destination, pack, monitor, or credential.
• Subscribe to or clone packs.
• Run the AI assistant.
• Publish pipelines or change collector state (restart, reload pipeline, upgrade, deregister).
• See the Settings entry — it's hidden because no settings actions are available to a viewer.

Member — day-to-day pipeline operator

Best for engineers who own pipelines and the collectors running them.

Adds on top of viewer:

• Create and edit pipelines, sources, destinations, and packs.
• Subscribe to curated packs and clone packs into editable copies.
• Edit a pipeline directly from the pipeline list (the Edit pipeline action) or from a pipeline card.
• Publish a pipeline to push the latest config to collectors.
• Add a new collector and run bulk Restart / Upgrade / Deregister on collectors they manage.
• Invoke the AI assistant for regex, processor, and security-recommendation help.
• Create, edit, and delete monitors plus notification channels (email, Slack, webhooks).

Still cannot:

• Create, edit, or delete credentials.
• Reach the Settings area or any organization-level admin surface.
• Delete pipelines, collectors, or packs.

Admin — operations and tenant administration

Best for team leads and platform operators who run the tenant end-to-end.

Adds on top of member:

• Create, edit, and rotate credentials used by sources and destinations.
• See the Settings entry. Inside Settings:
  • Manage organization members (invite, remove, change roles).
  • Create new tenants under the organization and update tenant settings.
  • Configure enterprise SSO connections.
  • Create, rotate, and revoke API tokens.
  • Edit the collector update policy (Settings → Collector update policy).

Still cannot:

• Delete the organization, delete a tenant, or perform any destructive operation on top-level identity objects.

Owner — full ownership including destructive operations

Best for the small group responsible for the lifecycle of the organization itself.

Adds on top of admin:

• The praxis * wildcard — every permission the praxis app exposes, including pipeline / collector / pack delete.
• The two destructive identity actions: delete an organization (org:delete), delete a tenant (tenant:delete).

Practical guidance: keep the owner role to the minimum number of accounts you need for incident response and account recovery. Day-to-day administration can be done with admin.

platform_admin (deployment-only)

Praxis also recognizes a platform_admin role that grants the global system:admin permission. It is not assigned through the normal organization-role flow — it is granted via deployment-level configuration (user_app_role_assignments at global scope) and used for cross-tenant maintenance and incident response. End users do not normally hold this role.

---

Permissions catalog

Permissions are short strings of the form resource:action. Roles are bundles of these strings; the role you hold determines which strings the platform considers granted for any request you make.

Praxis (pipeline product)

Permission	What it allows
pipeline:read	Read pipelines, the pipeline list, and pipeline detail pages.
pipeline:write	Create / edit pipelines, sources, destinations, packs (incl. subscribe and clone). Add Source / Add Destination / New Pack / Clone CTAs are gated on this.
pipeline:delete	Delete pipelines and packs.
pipeline:execute	Publish a pipeline (push config to collectors), validate against selected collectors.
collector:read	Read the collectors list, collector detail, rollout status.
collector:write	Add a new collector, restart / reload pipeline / upgrade / deregister collectors, edit the collector update policy in Settings.
monitor:read	Read monitors and notification channels.
monitor:write	Create, edit, delete monitors and notification channels.
creds:read	Read the credentials picker (used inside source and destination configuration).
creds:write	Create and edit credentials.
livetail:read	Subscribe to live-tail telemetry from a tenant's collectors.
assistant:invoke	Run the AI assistant (regex generator, processor builder, security recommendation).

Public, infrastructure-only permissions (no role required, used by collector bootstrap and health checks): health:check, collector:policy_fetch.

Identity Management (idm)

Permission	What it allows
user:read_self / user:write_self / user:logout	Read or update the current user's own profile; log out. Always public.
org:read	View organization details and member list.
org:update	Update organization settings.
org:manage_members	Invite, remove, and change roles for members.
org:delete	Delete an organization.
tenant:read	View tenants under the organization.
tenant:create / tenant:update / tenant:manage_members	Create tenants, update settings, manage tenant membership.
tenant:delete	Delete a tenant.
invitation:read / invitation:create / invitation:delete	Manage pending invitations.
invitation:accept	Accept an invitation. Always public — the invited user does not yet hold a role.
sso:read / sso:manage	View or configure enterprise SSO connections.
apitoken:read / apitoken:manage	View, create, rotate, and revoke API tokens.
system:admin	Cross-app, cross-tenant administrative access. Held only by platform_admin.

Public flows that don't require a role: account verification, recovery, SSO login flow, webhook callbacks, first-org bootstrap, health checks.

---

How roles map to permissions

The tables below are exhaustive — every permission a role holds, including those inherited from lower-tier roles. Cells marked with (via inherit) come from a role earlier in the chain.

Praxis app

Role	Permissions granted at this tier	Inherits
viewer	pipeline:read, collector:read, monitor:read, creds:read, livetail:read	—
member	pipeline:write, pipeline:execute, collector:write, monitor:write, assistant:invoke	viewer
admin	creds:write, plus cross-app: @idm/org:manage_members, @idm/tenant:create, @idm/sso:manage, @idm/apitoken:manage	member
owner	* (wildcard — every praxis permission, including delete)	admin

Identity Management app

Role	Permissions granted at this tier	Inherits
viewer	user:read_self, user:write_self, user:logout, org:read, tenant:read, invitation:read, apitoken:read, sso:read	—
member	(no additional permissions — same as viewer at the org level)	viewer
admin	org:update, org:manage_members, tenant:create, tenant:update, tenant:manage_members, invitation:create, invitation:delete, sso:manage, apitoken:manage	member
owner	org:delete, tenant:delete	admin
platform_admin	system:admin (granted out-of-band; not part of the normal role chain)	—

Cross-app claims

A small set of identity permissions are marked claimable by apps, meaning a praxis role can cite them directly. The praxis admin role uses this to grant Settings access without requiring a duplicate identity role assignment:

• @idm/org:manage_members
• @idm/tenant:create
• @idm/sso:manage
• @idm/apitoken:manage

Destructive identity operations (org:delete, tenant:delete, org:create, system:admin) are deliberately not claimable by app roles — they require an explicit assignment on the identity side.

---

Examples

"I want my SRE team to publish pipelines but not invite people"

Assign member in your organization. They can create, edit, publish, and clone pipelines; run the assistant; manage collectors; and create, edit, or delete monitors and notification channels. They cannot reach Settings or create credentials. If your SRE team also needs to manage stored credentials, give them admin instead.

"I want a stakeholder to watch dashboards and live-tail without breaking anything"

Assign viewer. They will see every read-only surface, including live-tail, and zero write CTAs.

"I need a service account that runs in CI to update pipelines"

Create an API token under an account that holds member (or admin if it also needs to rotate credentials). API tokens inherit the token holder's permissions; the same RBAC chain applies to token-authenticated requests.

"Who can delete a tenant?"

Only an idm owner. Praxis owner does not grant tenant:delete — that one is identity-side and intentionally outside the cross-app claim list.

---

How permissions are enforced

1. Gateway — every authenticated request passes through Oathkeeper, which strips spoofed identity headers and adds an authoritative principal (X-User-ID for users, X-Client-ID for API tokens).
2. Identity service — runs check-unified-permission against the request's tenant context and the principal's role assignments. The UI receives the resolved permission set and uses it to hide write CTAs the user can't complete.
3. Service handler — the praxis querier, control plane, stream-analyzer, and pipeline-assistant each tag every Huma route with the required permission name. A request that reaches a handler without the right permission is rejected before it touches storage.

UI gating is an experience layer — it removes buttons that would 403 anyway. The authorization boundary is the server.

---

Changing roles and assignments

• Inviting a new member: an admin (or owner) opens Settings → Members → Invite member and chooses the role to grant on accept.
• Promoting an existing member: same screen, edit role inline. Change takes effect on the user's next request.
• Switching tenants: the Org/Tenant selector at the top of the app changes which tenant you're acting in. Permissions are scoped per tenant — switching may show or hide CTAs depending on the role you hold there.
• Revoking access: remove the user from the organization in Settings → Members. Active sessions continue until the user's next token refresh; force a logout if you need immediate revocation.

---

Where this is defined

The catalogs below are the source of truth. If you need a permission split (for example, monitor:create separate from monitor:delete), this is where it changes:

• adaptive-pipeline/config/rbac/rbac-catalog.yaml — every praxis permission and the role bundles that grant them.
• identity-service/config/rbac/rbac-catalog.yaml — every identity permission, the role bundles, and which permissions are claimable by app roles.

The frontend constants in frontend/src/constants/permissions.ts mirror the catalogs and are the lookup that the UI uses to gate CTAs. They are kept in sync with the YAMLs at each release.