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

# Account States & Restrictions

> Reference Starfire AI administrative account states, narrow feature restrictions, reasons, verification, and recovery procedures.

# Account states & restrictions

Starfire uses account state to control access without forcing every support, billing, or security situation into a single banned/unbanned switch.

## Account states

| State           | Intended use                                              |
| --------------- | --------------------------------------------------------- |
| `ACTIVE`        | Normal operation                                          |
| `RESTRICTED`    | Narrow capabilities limited while general access remains  |
| `SUSPENDED`     | Broad normal access blocked by administrative policy      |
| `BILLING_HOLD`  | Access affected by unresolved billing state               |
| `SECURITY_HOLD` | Sensitive access restricted during security investigation |
| `DEACTIVATED`   | Account intentionally no longer active                    |

## Narrow restrictions

Where supported, prefer a targeted restriction when the problem affects only one capability.

Examples:

* uploads disabled
* FORGE disabled
* Developer Platform disabled
* web search disabled
* lower file/build limits
* specific model access denied

## Apply a state change

1. Confirm the affected account.
2. Identify the operational reason.
3. Choose the narrowest appropriate state/restriction.
4. Add the required reason/context.
5. Apply the change with an authorized admin role.
6. Verify effective user access.
7. Review audit history when available.

## Remove a restriction

Do not remove the restriction merely because time passed. Confirm the original cause is resolved, then restore only the permissions/features that should return.

## Billing vs security

Keep billing and security conditions distinct. A failed invoice should not be represented as malicious-user suspension, and a credential compromise should not be hidden behind a billing state.

## Auditability

State and restriction changes should record actor, target, reason, time, and previous/new state when supported.

<Warning>
  Do not use account suspension as a shortcut for an organization-level access problem. Organization membership and resource permissions are narrower controls.
</Warning>