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

# Overview

> Control who can use compute, access data, and administer your organization.

Identity and access management (IAM) connects **who is acting** to **what they may do**. Permissions and role assignments are scoped to an organization; access in one organization does not grant access in another.

## How access fits together

```mermaid theme={null}
flowchart TD
    accTitle: IAM relationships
    accDescr: An API key authenticates as its owning principal. Principals receive roles containing permissions that allow actions on resources within a scope.
    K[API key] -->|authenticates as its owner| P[Principal]
    P -->|is assigned| R[Roles]
    R -->|contain| G[Permissions]
    G -->|allow actions within a scope| T[Resources]
```

| Component                              | Purpose                                                                                |
| -------------------------------------- | -------------------------------------------------------------------------------------- |
| [Principal](/iam/principals)           | A Human, Application, or Agent identity that acts in the organization.                 |
| [Role](/iam/roles)                     | A named collection of permissions assigned to one or more principals.                  |
| [Permission](/iam/permissions)         | An allowed action on a resource within a scope.                                        |
| [API key](/platform/settings/api-keys) | A credential owned by one principal. Its IAM access comes from that principal's roles. |

A principal can hold several roles, and their grants combine. Only **Allow** permissions are supported: a role with fewer permissions does not cancel access granted by another role. Creating a permission grants no access until it belongs to an assigned role.

For an IAM-controlled action, the required grant must match the action and resource scope. Without it, access is denied.

## Compute and data access

Compute permissions control whether a principal can run or abort work on an engine. Warehouse permissions control which data the principal can read or change. Running a query against the warehouse needs both appropriate compute and data access.

Catalog and connection permissions separately control discovery and management of registrations. They do not grant access inside an external database.

Start with [Roles](/iam/roles) to choose a built-in role or create a custom one. Use [Resources and actions](/iam/resources-and-actions) for the complete permission reference.