Enforcer v3 docs / Enforcer Concepts
Mental model
Core concepts
Five ideas cover almost everything you will do. Read these once and the rest of the guide reads quickly.
Tenant
A tenant is your app inside Enforcer. It owns its users, groups, roles, theme, and keys. One Enforcer deployment can host many tenants, fully isolated from each other.
Person vs user
Identity is two layers. A cross tenant person is the human. A per tenant user is their login in one app. A verified person carries across apps and tenant switches without re verifying.
Groups
Groups are how a capability gets unlocked. A user is added to a group, and that membership is what opens a route or action. Pass an identity check, join the verified group, and a previously forbidden action becomes allowed.
Auth methods
Several ways to prove who someone is: passkey, email OTP, phone OTP over SMS, Google, SIWE for wallets, and Privy. You pick which ones your tenant accepts.
The moat, in one line
One policy brain makes every permission decision. Deciding what a person may do and deciding what a person may see come from the same engine, and a test proves they never disagree. A stack stitched from separate vendors cannot give you that guarantee.
Modules
The base, identity plus permissions, is the whole front desk above. Heavier capabilities are paid modules you switch on per tenant:
- Banking and KYC, identity verification and money movement, runs as an async module and reports back by webhook.
- Messaging, sending email and SMS to your users.
- Storage, files tied to a tenant and account.
- Wallet, on chain wallet capability.
How KYC connects to access: KYC is a module, not a core route. When a user passes verification, the result of that step is that they get added to your verified group. From then on the policy engine lets them through the gated routes. That "passing KYC becomes a permission" step is the thing a glued together stack does not give you.