Skip to main content
A wallet policy is the runtime spending rule set attached to an agent. While KYA tiers set the ceiling of what an agent could spend, wallet policies define what it actually may spend — merchant allowlists, per-merchant caps, time-of-day rules, kill-switch triggers. Policies are enforced on every spending request, before execution. Any violation returns 403 POLICY_VIOLATION with a specific reason code.

Policy shape

Read a policy

Update a policy

Evaluate a policy before attempting

Before an agent tries to spend, it can dry-run policy evaluation:
Response:
Or:

Rule types

Global limits

Hard caps on total spending per transaction, day, month. Always enforced regardless of merchant.

Merchant rules

Allow- or block-list specific merchants or merchant categories. First matching rule wins. Fall-through behavior configurable (default_action: allow or block).

Velocity rules

Rate-limit transactions: “at most N in window W”. Useful for abuse prevention.

Time rules

Permit spending only during defined windows. Outside the window → POLICY_VIOLATION.

Approval threshold

Any transaction over amount doesn’t execute directly — it creates an approval request that a human (with approver_role) must confirm. See approval workflows.

Kill-switch

Named humans can instantly freeze the wallet (POST /v1/agent-wallets/:id/freeze). Policy includes who they are and how to reach them, so incident response doesn’t require Sly support involvement.

Freeze and unfreeze

Freeze is distinct from Ed25519 key revocation:
  • Freeze — spending blocked, auth still works (agent can still read, observe, coordinate)
  • Revoke — auth blocked (agent cannot authenticate at all)
Use freeze first in incidents; reserve revocation for confirmed compromise.

Exposures (projected spending)

For scenario planning:
Returns active mandates, open streams, and scheduled transfers within the horizon with their cumulative projected spend. Useful for treasury forecasting.

Endpoints