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

# Access control

> Roles for people, scopes for API keys, and the approval controls that separate initiating a transaction from approving it.

Access is controlled at three levels: **roles** for people in the console, **scopes** for API keys, and **approval controls** that decide when a person must sign off before a transaction proceeds.

## Roles

Every member of a workspace has one role.

| Role       | Can                                                                                                                                                                  |
| :--------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Owner**  | Everything an admin can, plus ownership of the workspace. Always retains admin rights.                                                                               |
| **Admin**  | Manage policies, approval groups, members and roles, API keys, webhooks, alert channels and governance settings, including the kill switch. Everything a member can. |
| **Member** | Create wallets, attach assets, request withdrawals and signing, and read everything in the workspace.                                                                |
| **Viewer** | Read-only. Cannot initiate or approve anything.                                                                                                                      |

A role is set when a member is invited and can be changed by an admin. Members are invited by email; invitations can be revoked before they are accepted.

## Per-wallet access

By default every wallet is open to all workspace members at their workspace role. An admin can restrict a wallet to named members, each with a role on that wallet. Once a wallet has an access list, only those members can operate it; workspace admins and the owner always keep access. Removing the last assigned member reopens the wallet to the workspace.

## API key scopes

API keys are for applications, not people. Each key carries the scopes it may use:

| Scope                                     | Allows                                                                 |
| :---------------------------------------- | :--------------------------------------------------------------------- |
| `wallets:read` · `wallets:create`         | List and inspect wallets · create wallets                              |
| `assets:read` · `assets:attach`           | Read the asset catalog · attach assets to a wallet                     |
| `balances:read`                           | Read balances and overviews                                            |
| `withdrawals:read` · `withdrawals:create` | Read withdrawals · request withdrawals                                 |
| `signing:read` · `signing:write`          | Read signing status · request signing of a digest                      |
| `webhooks:read` · `webhooks:manage`       | Read webhooks and delivery logs · create, update and delete webhooks   |
| `admin:*`                                 | Administrative routes, including API-key management and operator views |

A key can also be **bound to specific wallets**, so that it cannot see or act on any other wallet; limited to an **IP allowlist**; given an **expiry**; and **revoked** at any time. Revocation takes effect immediately.

No scope lets an API key change policy, approve a request, alter members or roles, or lift a freeze. Those actions belong to people acting in the console.

## Approval controls

Approval is where initiating and authorising are separated.

* **Require approval to withdraw**: every withdrawal, or every withdrawal above a threshold amount, is held for an approval group before signing.
* **Policies**: rules that route matching withdrawals to an approval group: spend limits per asset, and destination whitelists.
* **Approval groups**: named sets of members with a threshold: the number of approvals a request needs.
* **Dual control**: the person who initiated a request cannot approve it. With dual control off, a single person can initiate and approve; the console warns that this is suitable for solo teams only.

Approvals are recorded with the approver's identity, taken from their console session (never from the request body), and each decision is written to the audit trail.

## Sign-in security

Console users sign in with email and password, Google, or a passkey, and can enable two-factor authentication with an authenticator app (TOTP) or a passkey. Sessions expire; a request with an expired session returns to sign-in.

## Related

* [Policies & approvals](/wallets/policies-and-approvals)
* [Endpoints, keys & authentication](/blockchain-infrastructure/blockchain-api/endpoints-and-authentication) for the Blockchain API's separate key model