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
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
- Confirm the affected account.
- Identify the operational reason.
- Choose the narrowest appropriate state/restriction.
- Add the required reason/context.
- Apply the change with an authorized admin role.
- Verify effective user access.
- 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.
Do not use account suspension as a shortcut for an organization-level access problem. Organization membership and resource permissions are narrower controls.
