Custody and enforcement model

AllowKit’s target architecture is non-custodial escrow with policy co-signing. Funds sit in an on-chain escrow controlled by the user and bounded to one agent. The agent cannot spend by itself, and AllowKit cannot move funds by itself.

01 · Deposit

The user funds an on-chain escrow account for one agent. The main wallet keeps its keys and can withdraw the remaining balance.

02 · Request

The agent has its own keypair and can only request payments from its assigned escrow. It never receives the user’s wallet key.

03 · Check

AllowKit evaluates policy off-chain, then signs only requests that pass caps, approved-recipient rules, approval thresholds, and pause state.

04 · Settle

The escrow releases funds on Solana only with both signatures. If AllowKit is down or policy fails, the payment fails closed.

Source of truth

Limits are evaluated by the AllowKit policy engine before co-signing. The on-chain escrow enforces that a valid policy signature is required, so an agent cannot bypass the API and drain funds directly.

Enforcement

Layer	What it does
Off-chain policy engine	Checks daily and weekly spend, max per payment, approved service id, recipient address, approval threshold, pause state, and velocity rules.
On-chain escrow	Requires the agent signature and an authorized AllowKit policy signature before releasing funds.
Bypass protection	An agent calling Solana directly has only its own signature, so the escrow refuses release.
Availability behavior	If AllowKit cannot evaluate policy or co-sign, payment stops. No fail-open path.

See the full threat model for what this design defends against.