Crossmint, Privy And Turnkey Take Different Paths On Agent Rules

Crossmint, Privy and Turnkey enforce agent-wallet permissions in different locations. Crossmint places rules in the wallet contract. Privy evaluates policies in a trusted execution environment before signing. Turnkey runs its policy engine inside the hardware-isolated enclave that generates keys and signs transactions.

The locations affect how permissions are created, changed and reviewed. Crossmint adds delegated signers to an existing wallet and records their permissions on chain. Privy and Turnkey keep policy enforcement off chain, allowing policy changes without a signer-installation transaction.

On Crossmint, a delegated signer must be approved through one of the wallet’s recovery methods before it can sign. A server signer configured as the recovery method can approve its own installation. Email and phone recovery require a person to enter a one-time code. This configuration determines whether the wallet can operate without human involvement.

Crossmint permissions can include spending limits, recipient allowlists and expiry dates. The platform supports server, passkey and external-wallet signers across EVM, Solana and Stellar networks. Installing a signer generally requires an on-chain transaction. Crossmint’s TypeScript SDK can defer installation until the signer’s first transaction on EVM networks. Solana and Stellar installations remain on chain.

Privy policies are assigned to individual RPC methods. The documented conditions include transaction amounts, recipient addresses, chains, contract addresses, Solana program addresses and decoded contract data, such as function names and parameters. Policies can also include time restrictions, signer and export windows, and aggregated historical limits for certain Ethereum methods.

Privy denies a request when no rule matches it, and an explicit denial takes precedence over an approval. Every instruction in a Solana transaction must be approved. For operations that both sign and broadcast a transaction, Privy simulates the transaction before evaluating the policy. A failed simulation can therefore appear as a simulation error rather than a policy violation.

Turnkey runs key generation, signing and policy evaluation inside hardware-isolated enclaves. According to its published documentation, the enclaves have no persistent storage, interactive access or external networking. Cryptographic attestation verifies that authorized code is running.

Turnkey policies use JSON and can include approval groups, transaction conditions and explicit denials. Consensus expressions can require named approvers to authorize an action. Condition expressions can specify when a policy applies, including the transaction destination. Most actions are denied unless a policy permits them.

A quorum of Turnkey root users can bypass all configured policies. Root-user membership therefore operates above the policy system. On Crossmint, recovery methods control the approval of new signers and can also override the practical limits of an automated setup.

Privy and Turnkey do not require an on-chain signer-installation transaction. Crossmint generally does. The three providers’ documented features and supported networks vary by chain and may change. Their security claims are based on vendor documentation and were not independently verified for this comparison.

None of the platforms by itself creates a record proving that a person approved a specific purchase. Organizations using agent wallets remain responsible for setting spending limits, managing recovery and root authorities, and keeping transaction records.