Table of Contents
These three get compared as wallet providers, which misses what you are actually buying. All three generate keys and sign transactions competently, and nobody chooses between them on that basis.
What you are buying is a rule engine. Each one answers the question of what an agent is allowed to do, and each answers it in a different place, with a different language and a different thing that can override it.
That is the comparison below. Where the rule runs, how precisely it can be written, and what happens when someone with enough authority decides to ignore it.
An agent wallet is a policy engine with a signer attached. The signer is commodity, the policy is the product, and the override path is the part nobody reads.
Key Takeaways
- Privy has the most expressive policy language of the three.
- Crossmint installs a signer on chain before it can sign.
- Turnkey runs the policy engine inside the signing enclave.
- Privy and Turnkey both deny anything no rule allows.
- A Turnkey root quorum can bypass every policy you write.
What These Three Actually Are
The architectural split is cleaner than the marketing suggests, and it decides most of the outcome.
Crossmint builds smart wallets where permissions are a property of the wallet contract, so a delegated signer has to be installed on chain before it can sign anything. Privy and Turnkey keep the enforcement off chain and inside a trusted execution environment, evaluating each request before any signature is produced.
That difference matters in opposite directions. On-chain permissions are externally auditable and cannot be quietly changed by whoever controls your backend, while enclave-side policies are faster to update, cost nothing to install and can express conditions no contract would practically check.
None of the three decides how much your agent should be allowed to spend, which is the policy design covered in our guide to agent spend limits.
What to note: pick the enforcement location first, because expressiveness and operational cost both follow from it.
Crossmint, Permissions Installed On Chain
Crossmint's model is a wallet with signers added to it, and the backend credential is the server signer.
A delegated signer is registered on an existing wallet and must be approved by one of that wallet's recovery methods. Where a server signer is itself the recovery method that approval is automatic, and on client-side wallets with email or phone recovery a person has to enter a one-time code, which is why the recovery configuration decides whether unattended operation is possible at all.
What it offers:
- Restrictions on a signer including spending limits, recipient whitelists and an expiry
- Server, passkey and external wallet signers across EVM, Solana and Stellar
- Device signers using a non-extractable keypair in the phone's secure hardware or a browser crypto context
- Control over installation timing, either immediately through a confirmed transaction or deferred to the signer's first transaction
- Email and phone signers available across all chains, intended for recovery rather than automation
Two costs come with the on-chain model. Installing a signer is itself a transaction, and the option to defer that installation is currently EVM-only through the TypeScript SDK while Solana and Stellar always install on chain.
Best for teams who want permissions auditable at the contract level and are willing to pay installation cost for it.
Privy, the Most Expressive Policy Language
Privy is the surprise of this comparison if you have only read the marketing pages, because the policy documentation is substantially deeper than the overview suggests.
A policy is a set of rules per RPC method, each carrying conditions and an allow or deny action, enforced inside a trusted execution environment before any signing or key export happens.
What the conditions can express:
- Amounts in the chain's smallest unit, with numeric comparison operators
- Recipient allowlists and denylists, where the membership operator accepts up to one hundred values
- Contract and Solana program allowlists, plus decoded calldata checks by function name and parameter given an ABI or Anchor IDL
- Chain allowlists and denylists, time-bound signers and export windows
- Stateful limits that reference aggregated historical values over a time window, for certain Ethereum methods
The posture is strict. Any request no rule matches is denied, a deny beats any allow, every instruction in a Solana transaction must evaluate to allow, and an allow-everything baseline requires writing an explicit allow-all rule for each method.
Best for teams whose agents interact with contracts rather than only transferring tokens, since calldata-level conditions are what that requires.
Turnkey, Deny by Default in the Enclave
Turnkey's distinguishing property is architectural rather than a feature list.
Key generation, signing and the policy engine all run inside the same hardware-isolated enclaves, which have no persistent storage, no interactive access and no external networking. A standard cloud host forwards requests and collects metrics without touching the enclave core, and cryptographic attestation is used to confirm that only authorised code is running.
What the policy model gives you:
- Policies defined in JSON and evaluated on every request
- A consensus expression governing who may approve an action, so named approvers can be required
- A condition expression governing when a policy applies, including the transaction destination
- Explicit deny taking precedence over any allow
- A default in which almost every action is implicitly denied
The override deserves attention before you design anything around it. A quorum of root users bypasses policies entirely, which makes root membership the real control sitting above everything else you configure.
Best for teams who want approval logic and signing in one attested environment and are comfortable writing policy as code.
Where Each Enforces the Rule
| Dimension | Crossmint | Privy | Turnkey |
|---|---|---|---|
| Enforcement location | On chain, in the wallet | In a trusted execution environment | In the signing enclave |
| Default posture | Restrictions added per signer | Deny anything unmatched | Implicit deny for almost everything |
| Condition depth | Limits, whitelists, expiry | Amounts, calldata, chains, time, aggregates | Approvers plus transaction fields |
| Multi-approver support | Recovery-method approval to add signers | Policies attach to key quorums | Consensus expressions per policy |
| Setup cost per signer | An onchain installation transaction | None | None |
| Documented chain scope | EVM, Solana, Stellar for server signers | Ethereum, Solana, Tron, Sui, XRPL policy types | Not enumerated on the pages reviewed |
Read the condition depth row and the practical ranking appears. For anything beyond send money to approved addresses under a limit, Privy currently documents the most granular controls of the three.
What to note: none of these produces the authorisation record proving a human sanctioned a purchase, which is the layer our analysis of payments for AI agents examines.
The Gotchas Worth Knowing
Four details sit outside the feature comparison and change implementations.
On Crossmint, the recovery method is the gatekeeper for adding signers, so an unattended agent needs a server signer configured as the recovery method rather than email or phone, otherwise somebody has to type a code. Installation is also a transaction, which means provisioning many agents has a real on-chain cost.
On Privy, simulation runs before policy evaluation for operations where it both signs and broadcasts, so a failing simulation surfaces as a simulation error rather than a policy violation. That is a debugging detail that wastes an afternoon if you do not know it.
On Turnkey, the root quorum override means your policy is only as strong as the list of root users, and policy as code requires someone fluent in its expression language. All three keep signing material away from your application, which is the shared strength rather than a differentiator.
What to note: write down who holds root or recovery authority on day one, because that list is your actual security boundary.
Which Fits Which Build
- If permissions must be externally auditable, Crossmint puts them where anyone can verify them.
- If agents call contracts rather than just transfer, Privy's calldata conditions are the deciding feature.
- If you need named approvers on specific actions, Turnkey's consensus expressions are the cleanest fit.
- If you are provisioning agents at volume, the two off-chain options avoid an installation transaction each.
- If you already serve consumer wallets, Privy covers users and agents in one system.
- If you want rolling spend caps, Privy's aggregate conditions express them natively.
What to note: most production setups pair one of these with a separate treasury arrangement, leaving the agent only a float it can spend.
Risks and Limitations
- Documentation depth varies, so a missing feature on a page is not proof it does not exist.
- Security properties here are each vendor's own published claims and are not independently verified.
- Override paths through root users or recovery methods can defeat otherwise sound policies.
- Chain and feature coverage differs within a single vendor, so confirm per network.
- None of these removes your obligations for screening, records or oversight.
Conclusion
Crossmint, Privy and Turnkey are three answers to the same question, which is what an agent may do with money it can reach.
Crossmint answers it in the wallet contract, which buys external auditability at the price of an installation transaction per signer. Privy answers it in an enclave with the most granular condition language of the three, including decoded calldata and rolling aggregates. Turnkey answers it inside the same attested enclave that holds the keys, with named approvers and almost nothing permitted unless a policy says so.
Choose on enforcement location and condition depth, then read the override path. Whichever you pick, the proof layer sits above it, which is why the receipt pattern in our walkthrough of ACK-Pay settlement belongs in the design alongside it.
Read Next:
FAQs:
1. What is the main difference between Crossmint, Privy and Turnkey?
Where the rule is enforced. Crossmint installs signer permissions on chain in the wallet itself, while Privy and Turnkey evaluate policies inside a trusted execution environment before any signature is produced.
2. Which has the most detailed spending controls?
Privy, based on published documentation. Its conditions cover amounts in the chain's smallest unit, recipient allowlists, contract and program allowlists, decoded calldata by function name and parameter, chain restrictions, time windows and aggregated historical limits for certain Ethereum methods.
3. Are these platforms deny by default?
Privy and Turnkey are. Privy denies any request that no rule matches and a deny beats any allow, while Turnkey implicitly denies almost every action unless a policy allows it, so an allow-everything baseline has to be written explicitly.
4. Can a policy be overridden?
Yes, and the path differs. On Turnkey a quorum of root users bypasses policies entirely, and on Crossmint the wallet's recovery method approves the addition of new signers, so both lists are effectively above your policy configuration.
5. Which suits an unattended agent best?
Privy and Turnkey are built for server-side operation without a person present. Crossmint can do it, provided a server signer is configured as the recovery method, since email or phone recovery requires somebody to enter a one-time code.
Disclaimer:
This content is provided for informational and educational purposes only and does not constitute financial, investment, legal, or tax advice; no material herein should be interpreted as a recommendation, endorsement, or solicitation to buy or sell any financial instrument, and readers should conduct their own independent research or consult a qualified professional. Platform capabilities, policy features, chain coverage and security claims are drawn from each vendor's own published documentation at the time of writing, are not independently verified here, and change frequently; confirm every detail directly with the provider before committing to an integration.
