> ## Documentation Index
> Fetch the complete documentation index at: https://aidocs.ethanbragdon.icu/llms.txt
> Use this file to discover all available pages before exploring further.

# Permission Model Reference

> Compare personal, organization, developer, and platform-administrator permission boundaries across Starfire AI.

# 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

| Layer                   | Controls                                                                                              |
| ----------------------- | ----------------------------------------------------------------------------------------------------- |
| **Account**             | Personal resources, sessions, profile, personal projects, personal billing context                    |
| **Organization**        | Team membership, organization projects, Knowledge, policies, seats, team billing, developer ownership |
| **Resource**            | Access to a specific project, Knowledge base, application, or other shared object                     |
| **Developer scopes**    | What an API key, application, or service account can do programmatically                              |
| **Control Center RBAC** | Platform-wide operator capabilities                                                                   |

## Organization role example

Exact role names can evolve, but this matrix illustrates the intended separation.

| Action                       | Owner |        Admin | Developer |  Member |
| ---------------------------- | ----: | -----------: | --------: | ------: |
| View organization            |     ✓ |            ✓ |         ✓ |       ✓ |
| Invite members               |     ✓ |            ✓ |         — |       — |
| Change member roles          |     ✓ |            ✓ |         — |       — |
| Manage projects              |     ✓ |            ✓ |         ✓ | limited |
| Manage Knowledge             |     ✓ |            ✓ |         ✓ | limited |
| Create developer resources   |     ✓ |            ✓ |         ✓ |       — |
| View organization billing    |     ✓ | configurable |         — |       — |
| Change subscription/seats    |     ✓ | configurable |         — |       — |
| Change organization policy   |     ✓ |            ✓ |         — |       — |
| Delete/transfer organization |     ✓ |            — |         — |       — |

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:

```text theme={null}
Feature exists
  AND plan allows it
  AND organization policy allows it
  AND role/resource permission allows it
  AND credential/session is valid
  AND no narrower restriction blocks it
```

<Warning>
  When troubleshooting access, identify the layer that denied the action. Granting a broader role can hide the real issue and create unnecessary privilege.
</Warning>