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

# Permissions & Policies

> Understand organization roles, effective permissions, feature policy, and access boundaries in Starfire AI.

# Permissions & policies

Organizations need more than a member list. They need a predictable way to decide which resources and features a member can actually use.

## Effective access

A member's effective access can be influenced by multiple layers:

```text theme={null}
Platform availability
      +
Plan entitlement
      +
Organization policy
      +
Member role
      +
Resource permission
      +
Feature/user override
      =
Effective access
```

This means a role alone is not always enough to explain why a feature is visible or unavailable.

## Organization policies

Organizations can use policy concepts to control shared behavior, such as:

* which models members can use
* whether developer access is allowed
* whether FORGE is available
* file and storage limits
* research or search access
* project creation rules
* Knowledge management
* organization billing behavior

The exact policy editor and available controls can evolve during Organizations 3.0 rollout.

## Resource-level access

A member can belong to an organization without having access to every project or Knowledge source in it. Resource permissions create narrower collaboration boundaries inside the organization.

## Overrides

Some Starfire systems support inherited/default behavior plus a narrower override. When an override exists, the interface should make it clear whether a value is:

* inherited
* explicitly allowed
* explicitly denied

This prevents administrators from confusing a local exception with the organization default.

## Deny vs unavailable

These are different conditions:

* **Unavailable** — the platform, plan, or rollout does not expose the capability.
* **Denied** — the capability exists but policy or permission blocks this user/context.

Troubleshooting should identify which layer is responsible before changing permissions.

## Auditability

Sensitive organization changes should produce an administrative record when supported by the current build so operators can identify who changed membership, roles, billing, or important policy state.

<Card title="Control Center RBAC" icon="user-lock" href="/admin/rbac-support">
  Learn how organization permissions differ from platform-wide administrator permissions.
</Card>