Platform RBAC

The Policy platform uses two layers of access control:

• Role-based access control decides what actions a user is allowed to take in an organization
• Ownership and visibility rules decide which policies, flows, and groups a user can see

Both matter. A user may have a role that allows editing, but still only be able to edit resources they can actually access.

Authorization Enforcement

The orchestrator evaluates role permissions through the policy engine using a reserved internal authorization policy.

• role assignments still come from the existing member_roles table
• the effective permission matrix is unchanged: viewer < editor < publisher < admin, with auditor as a separate read-only audit role
• the authorization policy is cached in memory by the orchestrator to avoid a database lookup on every request
• if the policy engine is unavailable or authorization evaluation fails, the platform fails closed and denies the request

Roles

The platform currently uses these organization roles:

Role	Purpose
viewer	Can view and run visible policies and flows
editor	Can create and update drafts, tests, and groups
publisher	Can do everything an editor can, plus publish versions
admin	Can manage roles, API keys, deletes, and other admin actions
auditor	Can view resources and tenant audit activity, but is not an authoring role

Default Role Provisioning

When a user enters an organization and does not already have a role assignment:

• if they are the first user in that organization, they are automatically assigned admin
• otherwise they are automatically assigned viewer

This prevents users from landing in an organization with no effective role while still keeping default access narrow.

Effective Permissions

Viewer

A viewer can:

• view policies and flows they are allowed to see
• run policies and flows they are allowed to see
• browse groups they are allowed to see

A viewer cannot:

• create groups
• create drafts
• create versions
• create or edit tests
• assign owners
• manage roles
• delete policies or flows

Editor

An editor can:

• create draft policies and flows
• update draft policies and flows they can access
• create and manage tests
• create groups
• assign visible resources to groups

An editor cannot:

• publish versions
• manage roles
• perform admin-only deletes

Publisher

A publisher can:

• do everything an editor can do
• publish policy versions
• publish flow versions

Admin

An admin can:

• do everything a publisher can do
• manage role assignments
• manage API keys
• delete policy bases and flow bases
• perform other tenant administration actions

Auditor

An auditor can:

• view resources they are allowed to see
• access tenant audit activity

An auditor cannot:

• create drafts
• create groups
• publish versions
• perform admin actions

Ownership Model

Roles control actions. Ownership controls visibility.

Drafts that have never been published

If a policy or flow exists only as a draft and has never been published:

• it is user-owned
• only the creating user can see it in normal listings
• it can still be opened directly if the ID is known

Published or versioned resources

Once a policy or flow is published/versioned:

• the base becomes organization-owned
• anyone in that organization with sufficient role permissions can see it

This means published resources stop behaving like private drafts and become shared tenant assets.

Draft Visibility Rules

The platform currently follows these rules:

• a user creates a brand new draft policy or flow: only that user sees it in normal lists
• a user creates a draft from an existing published/versioned base: anyone in the owning org can see it
• a direct ID can still open a never-published draft because IDs are UUIDs and treated as hard-to-guess links

Group Visibility Rules

Groups follow the visibility of their contents.

• if a user creates a group containing only resources they alone can see, only that user can see the group
• if a group contains organization-owned policies or flows, anyone in that organization can see the group

In practice, groups remain private until they contain org-visible content.

Delete Behavior

Deletes are currently soft deletes.

• you delete a base policy or base flow
• you do not delete an individual version
• once the base is deleted, it can no longer be loaded or run, even if someone tries to use a version ID directly

Audit Visibility

Tenant audit activity is available to:

• admin
• auditor

Current audit coverage includes create, edit, publish, assign, execute, and delete paths that exist in the platform. Ad hoc editor test runs are not part of the main audit trail.