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

# Organizations and authority

> Understand how Arbol binds identities, permissions, and resources to one organization.

An Arbol access token identifies both an actor and an organization. The API verifies those claims before it resolves any resource or executes a handler.

## Tenant boundary

Organization identity comes from the verified credential. Public resource inputs therefore do not accept an `orgId` that changes the tenant boundary.

This has three practical effects:

1. Resource identifiers are meaningful only inside the credential's organization.
2. A resource from another organization is never made accessible by supplying its identifier.
3. Organization membership and role changes take effect through the identity provider, not through a second API-owned permission store.

## Actors and permissions

The OpenAPI contract can declare user-delegated and machine-to-machine security alternatives. Within either alternative, the listed scopes are an **all-of** requirement.

For example, an operation that reads a conversation transcript can require both `conversations:read` and `conversations:transcript`. Possessing only one scope is insufficient.

<Info>
  User tokens also carry the baseline organization grant declared by the contract. Machine credentials receive only the explicitly granted operation scopes.
</Info>

## Design integrations around the boundary

* Store Arbol resource identifiers with the organization context in your application.
* Request the smallest permission set your integration needs.
* Treat a `403` response as an authority decision, not as a signal to retry with a different organization identifier.
* Re-authorize when membership, role, or connected-account access changes.