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

# Govern wallet access

> Decide who can see, configure and move funds, enforce it with roles, scoped keys and approval groups, and prove it from the audit log.

Access governance is where a custody reviewer starts: who can move funds, who can change the rules, and how you would know. The platform separates these with workspace roles for people, scoped keys for systems, approval groups for high-value actions, and an audit log that records all of it.

## What you'll need

* An owner account and the list of people and systems that need access.
* Your internal segregation-of-duties policy: who may configure, who may approve, who may only view.

## Components to configure

| Component             | Role                                                                                |
| :-------------------- | :---------------------------------------------------------------------------------- |
| **Roles**             | Owner, admin, member and viewer for people.                                         |
| **Per-wallet access** | Restricts a member to specific wallets.                                             |
| **Scoped API keys**   | Systems get only the scopes they need, bound to wallets and IP ranges, with expiry. |
| **Approval groups**   | Named groups with an M-of-N requirement for withdrawals above a threshold.          |
| **Dual control**      | Four-eyes on configuration changes.                                                 |
| **Audit log**         | Every action, by whom, when.                                                        |

## Steps

<Steps>
  <Step title="Assign roles by function">
    Keep **Owner** to two people at most: it is the role that can change everything, including the emergency freeze. **Admin** for those who configure policies and keys, **Member** for operators who initiate withdrawals, **Viewer** for finance, risk and audit. See [Access control](/security/access-control) for the exact capabilities of each.
  </Step>

  <Step title="Restrict members to their wallets">
    For members, apply **Restrict to wallet** so an operator sees and acts on the wallets of their desk only. A member with no restriction can see every wallet in the workspace.
  </Step>

  <Step title="Issue systems their own keys">
    Never share a person's credentials with a system. Create an API key per integration with the minimum scopes (`balances:read` for reporting; `withdrawals:create` bound to one wallet for a payout service; `webhooks:manage` for the integration that registers endpoints), an IP allowlist and an expiry. Rotate by creating the replacement first, then revoking.
  </Step>

  <Step title="Create approval groups">
    Under **Approval groups**, create a group for each approval tier, for example *Treasury approvers* with three members and **Approvers needed** set to two. Then set **Require approval to withdraw** with the amount above which the group must sign off.
  </Step>

  <Step title="Turn on dual control">
    Enable **Dual control** so that changing a limit, a whitelist or an approval rule needs a second admin. This closes the path where one administrator loosens a rule and then acts under it.
  </Step>

  <Step title="Review the audit log on a schedule">
    `GET /api/v1/workspaces/{workspace_id}/audit-logs`, or **Audit Log** in the console, lists approvals and rejections, key creation and revocation, webhook changes, freezes and policy changes with actor and time. Export it to your log platform and review role and key inventories quarterly.
  </Step>
</Steps>

## Considerations

* Approval is exercised in the console by a person who has signed in; an API key cannot approve.
* Scopes are enforced on every request; a request outside a key's scope is rejected before any policy runs.
* A revoked key stops working immediately; an expired key stops at its expiry. Neither affects withdrawals already in flight.

## Related

* [Build programmable approval policies](/solutions/compliance/build-programmable-approval-policies)
* [Access control](/security/access-control): roles, scopes and sign-in security in full.
* [Reporting & audit](/wallets/reporting-and-audit)