Ironflow is pre-1.0: APIs can change between releases. Pin a version. What is ready →

Platform RBAC

Platform RBAC controls what platform users and API keys can do. Platform roles (platform_admin, platform_operator, platform_viewer) are stored in the unified roles table under org_platform and use the same RBAC infrastructure as tenant roles.

Built-in Roles

Three roles are available out of the box:

Role	Description	Key Capabilities
`platform_admin`	Full platform access	All operations including user management, write impersonation, and key management
`platform_operator`	Operational access	Tenant management, full impersonation, freeze and thaw the instance, read access to users/keys/roles/policies/audit
`platform_viewer`	Read-only access	View users, keys, roles, policies, tenants, the instance state and audit logs; read-only impersonation

Built-in roles cannot be deleted or modified.

Assigning Roles

To Users

Assign roles when creating a user:

ironflow platform users create --email ops@example.com --name "Operator" \
  --role-ids role_platform_admin

Or via the API:

curl -X POST http://localhost:9123/api/v1/platform/users \
  -H "Authorization: Bearer $PLATFORM_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "email": "ops@example.com",
    "password": "secure-password",
    "name": "Operator",
    "role_ids": ["role_platform_admin"]
  }'

To API Keys

Assign roles when creating a key:

ironflow apikey create ops-key --platform --role role_platform_operator

--role takes a role ID and can be repeated. A platform key created without --role gets no roles and therefore no permissions — the auto-assigned viewer fallback applies to tenant keys only. Role IDs passed with --platform must belong to org_platform.

Action Reference

Platform actions control access to specific operations:

Action	Description
`platform:users:read`	List and view platform users
`platform:users:manage`	Create, update, and delete platform users
`platform:keys:read`	List and view platform API keys
`platform:keys:manage`	Create, rotate, and delete platform API keys
`platform:roles:read`	List and view platform roles
`platform:roles:manage`	Create, update, and delete custom roles
`platform:tenants:read`	List and view tenant organizations
`platform:tenants:manage`	Provision and delete tenant organizations
`platform:impersonate:read`	Read-only access to tenant data via impersonation
`platform:impersonate`	Write access to tenant data via impersonation (any endpoint whose RBAC action is not a read)
`platform:policies:read`	View the platform policy set and its versions
`platform:policies:manage`	Write, validate, dry-run and roll back the platform policy set, and force a tenant set to monitor mode
`platform:audit:read`	Query the platform audit log
`platform:instance:read`	Read the instance barrier and drain state
`platform:instance:freeze`	Freeze and thaw the instance
`platform:instance:reconcile`	Reconcile one drain obligation
`platform:instance:attest`	Attest instance coverage for a boundary
`platform:bootstrap`	Run the one-time platform bootstrap. No built-in platform role holds it; only an admin of the default organization does

Actions by Role

Action	Admin	Operator	Viewer
`platform:users:read`	Yes	Yes	Yes
`platform:users:manage`	Yes	—	—
`platform:keys:read`	Yes	Yes	Yes
`platform:keys:manage`	Yes	—	—
`platform:roles:read`	Yes	Yes	Yes
`platform:roles:manage`	Yes	—	—
`platform:tenants:read`	Yes	Yes	Yes
`platform:tenants:manage`	Yes	Yes	—
`platform:impersonate:read`	Yes	Yes	Yes
`platform:impersonate`	Yes	Yes	—
`platform:policies:read`	Yes	Yes	Yes
`platform:policies:manage`	Yes	—	—
`platform:audit:read`	Yes	Yes	Yes
`platform:instance:read`	Yes	Yes	Yes
`platform:instance:freeze`	Yes	Yes	—
`platform:instance:reconcile`	Yes	—	—
`platform:instance:attest`	Yes	—	—

Platform vs Tenant RBAC

Aspect	Platform RBAC	Tenant RBAC
Scope	Cross-tenant platform operations	Single organization
Roles	`platform_admin`, `platform_operator`, `platform_viewer`	`admin`, `developer`, `viewer`
Actions	`platform:*` namespace	`functions:`, `events:`, etc.
Custom roles	Named roles; deny rules for them live in the policy set	Named roles; deny rules for them live in the policy set
Key prefix	`ifplatform_`	`ifkey_`

Custom Roles

Create a custom role:

ironflow platform roles create support-role

The server adds the platform_ prefix, so this creates platform_support-role. A custom role grants no platform:* action on its own: only the three built-in roles carry actions. A custom role is a name that a rule in the platform policy set can test, and the policy set can only deny what a built-in role allowed. To give a user or key platform access, assign a built-in role.

Deny rules that depend on a role are written in the Rego policy set. See Authorization policy sets and Custom Roles & Policy Sets.

Next Steps

Managing Platform Users & Keys — assign roles during user/key creation
Impersonating Tenants — how impersonation permissions work in practice
Platform Roles Reference — complete role and action tables
Platform Architecture — how platform RBAC is evaluated