Skip to main content

Permission model reference

Starfire uses multiple permission layers because a normal user, an organization administrator, a developer integration, and a platform operator should not share one global role system.

Permission layers

Organization role example

Exact role names can evolve, but this matrix illustrates the intended separation. This is a conceptual role matrix. The active Organizations 3.0 configuration is the source of truth for exact permissions.

Developer scopes

Developer credentials should receive resource-family scopes rather than human administrator roles. A key that can create builds should not automatically manage billing or users.

Control Center permissions

Platform operators can have granular permissions for user, billing, model, developer, security, audit, and configuration operations. An organization administrator is not automatically a Starfire platform administrator.

Effective permission

Access is granted only when every required layer permits the operation:
When troubleshooting access, identify the layer that denied the action. Granting a broader role can hide the real issue and create unnecessary privilege.