> ## 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.

# RBAC & Support Mode

> Understand Starfire AI administrator roles, granular permissions, sensitive-operation controls, and safer support access.

# RBAC & Support Mode

Control Center uses role-based access concepts so platform administration can be divided by responsibility instead of giving every operator unrestricted power.

## Granular permissions

The administration architecture supports permission families such as:

```text theme={null}
users.read
users.update
users.suspend

billing.read
billing.modify_plan

models.read
models.update
models.publish

security.read
security.revoke_session

developer.read
developer.manage_keys

platform.change_settings
platform.maintenance

audit.read
```

The exact permission catalog can evolve as Control Center 4.0 is rolled out.

## Roles are permission bundles

A role groups permissions for a job.

For example, a support role might receive user-read and session-diagnostic access without receiving model publishing or billing modification rights.

Custom administrator roles can eventually provide even tighter organizational control where enabled.

## Sensitive operations

Some administrative actions deserve stronger confirmation than an ordinary button click.

Examples include:

* permanent deletion
* broad session revocation
* destructive artifact/storage operations
* major billing changes
* platform maintenance changes
* other high-impact actions defined by policy

The UI can require an explicit confirmation step and, in future workflows, additional approval where appropriate.

## Support Mode

Support Mode is designed to give authorized support staff the diagnostics they need without turning support into unrestricted impersonation.

A support-oriented view can expose operational information such as:

* account and plan status
* client versions
* session state
* sync health
* request identifiers
* failed API requests
* storage/indexing status

## View-as-user boundaries

If a future support workflow allows a view-as-user capability, the safe design is explicit permission, a prominent visual indicator, time limitation, read-only default behavior, and full auditability.

<Warning>
  Support access should never be used as a shortcut around a missing organization role or as an informal way to browse private user content.
</Warning>

## Audit

Role changes, sensitive admin actions, and elevated support operations should be attributable to the acting administrator when the active subsystem supports auditing.

<Card title="Security & Audit" icon="shield-halved" href="/admin/security-audit">
  See how administrator actions and security events are tracked operationally.
</Card>