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.