Skip to main content
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

​
Steps

1

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 for the exact capabilities of each.
2

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

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

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

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

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.

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