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

# Access control

> Understand access control on the Anchorage Digital platform.

export const Check = () => <Icon icon="check" color="#049159" />;
export const Cross = () => <Icon icon="x" color="#dd0000" />;

## User permission levels

The platform has three user permission levels: **Administrator, Operator, and Viewer**. Users can hold multiple roles, and each vault can have its own user access configurations.

| Permission                      | Administrator |  Operator |   Viewer  |
| ------------------------------- | :-----------: | :-------: | :-------: |
| Edit vault & org policies       |   <Check />   | <Cross /> | <Cross /> |
| Add/remove users                |   <Check />   | <Cross /> | <Cross /> |
| Create vault                    |   <Check />   | <Cross /> | <Cross /> |
| Add/remove trusted destinations |   <Check />   | <Cross /> | <Cross /> |
| Provision API keys              |   <Check />   | <Cross /> | <Cross /> |
| Deposit & withdraw              |   <Check />   | <Check /> | <Cross /> |
| View balances                   |   <Check />   | <Check /> | <Check /> |

<CardGroup cols={3}>
  <Card title="Administrator" icon="black-tie">
    Full access to perform administrative tasks, including the ability to create and modify policies.
  </Card>

  <Card title="Operator" icon="hand">
    Access to perform operations in a vault policy, including initiating withdrawals or staking operations.
  </Card>

  <Card title="Viewer" icon="glasses">
    View permissions to vaults and the ability to download statements or reports.
  </Card>
</CardGroup>

**Organization-level vs vault-level:** Administrator is an organization-level role, granted through the administrator policy. Operator and Viewer access is assigned per vault through each vault's policy—so the same user can be an Operator in one vault and a Viewer in another.

<Note>
  Administrator scoping isn't fully granular yet. A user scoped to a specific administrator rule can still initiate—though not approve—other administrator operations. More granular administrator separation is on the roadmap.
</Note>

To view roles and permissions, use the **Settings → Roles** section on the web dashboard, or check individual user details within the iOS app.

### User actions across devices

User actions are determined by the device used.

| Action      | Mobile App | Web Dashboard |    API    | Quorum needed |
| ----------- | :--------: | :-----------: | :-------: | :-----------: |
| Deposits    |  <Check /> |   <Check />   | <Check /> |   <Cross />   |
| Withdrawals |  <Check /> |   <Check />   | <Check /> |   <Check />   |
| Trading     |  <Cross /> |   <Check />   | <Check /> |   <Cross />   |
| Transfers   |  <Cross /> |   <Cross />   | <Check /> |   <Cross />   |

<Note>
  Biometric approval is always required on iOS, even when quorum is not. Tapping approve isn't the security step — your biometrics unlock the signing key held in the device's secure hardware, which is what actually authorizes the operation.
</Note>

### How iOS and API authorization work differently

Both interfaces prove the same thing — that an authorized party approved the operation — but they prove it differently:

* **On iOS**, the approver is a person, in the moment. Biometrics bind the approval to a specific human on a specific enrolled device, and unlock the key in the device's secure hardware to sign.
* **Over the API**, the approver is a system — but a human quorum can still stand behind it. There's no person in the loop to scan each request, so authorization comes from a cryptographic signature: sensitive requests are signed with your Ed25519 key, and each key is scoped by [permission groups](/knowledge-base/platform/users/web-dashboard/developers).

  For certain permission groups, key creation and/or permission changes require quorum approval and Anchorage Digital review. That human approval is front-loaded (when required), then reused for each signed request rather than collected again per transaction.

In both cases the operation is still subject to quorum and Anchorage Digital review where the policy requires it.

## Quorums and policies

All sensitive operations—such as withdrawing assets or changing account settings—require approval from multiple members of your Anchorage organization.

Each vault operates under a [vault policy](/knowledge-base/platform/users/vault-policies), which defines the user access configuration for that vault. A vault policy may be assigned to multiple vaults, ensuring that the same permission level and rules for operation approval are consistently applied across all of them.

<CardGroup cols={3}>
  <Card title="Vault members" icon="users">
    Each vault must have a minimum of 3 members.
  </Card>

  <Card title="Quorum approvers" icon="id-badge">
    Each vault must have a minimum quorum of 2 approvers.
  </Card>

  <Card title="Viewer" icon="glasses">
    View permissions to vaults and the ability to download statements or reports.
  </Card>
</CardGroup>

By default, each vault must have a minimum of 3 members and a minimum quorum of 2 approvers. Within those conditions, it is possible to customize quorums and sub-quorums per rule type (withdrawal, staking, governance).

**Policy customization options:**

* Configure dedicated approval quorums and sub-quorums for withdrawal, staking, and governance operations
* Customize the quorum and sub-quorums for user management, trusted destination management, and vault and API management operations
* Add or remove users from vault and account sub-policies

For more details, see [Creating a vault](/knowledge-base/platform/users/creating-vaults) and [Managing users](/knowledge-base/platform/users/managing-users).