Security checklist

Review your organization against these warning signs. Each one is quick to spot and quick to fix. For the reasoning and detailed configurations behind the fixes, see security best practices.

One compromised user should not be enough

A rogue or compromised user can only do what their role and your policies allow.

What to check	What to do
- Several users are full admin. - No governance policies apply.	Give day-to-day users fine-grained roles, and require approval on admin actions. Several admins are healthy — unchecked admins are not.
- You have mainnet wallets. - Several users have access. - There are no policies.	Create policies. Without them, any single compromised user can move funds.

One leaked key should not be enough

Service account credentials live on servers, in CI systems, and in secret managers. They leak more often than passkeys, so scope them for containment.

What to check	What to do
A service account is full admin	Create a dedicated role per service account, with only the permissions it uses.
- You have mainnet wallets. - A service account has access. - There are no policies.	Create policies. They govern service account activity like any other, so a leaked key alone can’t move funds.
A service account can manage users, permissions, or policies	Remove those permissions. Automation almost never needs them, and a leaked key could otherwise disable your other controls.
One service account shared across systems	Create one per integration. A leak stays contained, and revoking it doesn’t break everything else.
Unused service accounts or tokens still active	Deactivate them. Forgotten keys are the ones that leak.
A service account’s private key sits on the computer of whoever created it	Generate keys where they run — a server or secrets manager — and keep no copy on a workstation. A compromised laptop steals keys silently; rotate any key that may have been exposed.

Policies that don’t protect you

A policy can exist and still not protect you.

What to check	What to do
A policy has `initiatorCanApprove: true`	It’s off by default, so re-justify it. With it on, an attacker who can initiate needs one fewer external approval; with a quorum of 1, they approve their own request.
No policies on `Permissions:Assign`, `Permissions:Modify`, `Policies:Modify`	Add the three governance policies. Otherwise every other policy is one API call away from deletion.
A policy’s only approver is a service account	Add a human approval group. Automation shouldn’t wave through an attacker’s transfer.
Policy filters match no wallets	Fix the scope. The policy exists, but nothing is covered.
No amount limit or velocity cap on mainnet wallets	Add `TransactionAmountLimit` and velocity rules so one compromise can’t drain everything in a single transaction.

You can’t react to what you don’t see.

What to check	What to do
No webhooks configured	Subscribe at least to transfer and policy events (`wallet.transfer.*`, `policy.approval.pending`) so you notice a drain while it’s happening, not after.
Empty address book despite regular transfers	Add your counterparties so lookalike addresses stand out.
- Wallets always pay the same addresses. - There is no whitelist policy.	Add a `TransactionRecipientWhitelist` policy. Stolen credentials can then only send funds where they already go.

Lockout risks

Hardening cuts both ways: check that you can’t lock yourself out.

What to check	What to do
A user has a single credential on a single device	Register a backup credential. Losing a phone shouldn’t mean losing the account.
Only one admin in the organization	Add a second, protected by the governance policies. No single point of failure — in either direction.

Introduction

Core Concepts

Platform Features

Networks

Solutions

Guides

Advanced

One compromised user should not be enough

One leaked key should not be enough

Policies that don’t protect you

Blind spots

Lockout risks

Next steps

Security best practices

Create policies

​One compromised user should not be enough

​One leaked key should not be enough

​Policies that don’t protect you

​Blind spots

​Lockout risks

​Next steps

Security best practices

Create policies

One compromised user should not be enough

One leaked key should not be enough

Policies that don’t protect you

Blind spots

Lockout risks

Next steps