Write a Coinbase CDP wallet policy that caps sendEvmTransaction at $100 and nothing else, and your agent can still call signEvmHash, which signs any 32-byte hash, with no limit at all. CDP's documented rule is that an operation no policy mentions is accepted. Privy and Turnkey both do the opposite and deny anything you did not allow.
That difference, and a handful like it, decides how much an agent wallet can lose when the model goes wrong. None of the pages ranking for "privy vs turnkey" show it. The top results are Turnkey's own /vs/privy pages, Crossmint's alternatives page and cost calculators. None of them puts the three policy formats side by side or says whether the wallet can enforce a daily cap, which is the first thing an agent builder needs to know. Everything below is checked against each vendor's docs, OpenAPI spec and pricing page as of 7 November 2026.
What Is a Wallet Policy Engine for AI Agents?
An agent wallet is a server-side key that your code, or an LLM acting through your code, asks to sign things. A policy engine sits between the request and the key. It parses what is about to be signed (destination, value, calldata, typed-data fields), checks that against rules you wrote, and refuses to sign if they fail.
All three vendors run keys in AWS Nitro Enclaves. Privy splits each key 2-of-2 with Shamir secret sharing, with one share that only the enclave can decrypt. Turnkey runs its signer and its policy engine inside enclaves on QuorumOS, its own minimal Linux unikernel, with reproducible builds that operators check against the enclave attestation. CDP keeps keys in a Nitro TEE and guards wallet calls with a Wallet Secret, a P-256 key that signs a JWT sent as X-Wallet-Auth.
The enclave stops someone stealing the key. It does nothing about your own agent asking for a bad signature, and that is where the policy engine has to do the work.
Privy vs Turnkey vs Coinbase CDP: Policy Engines Compared
| Coinbase CDP | Privy | Turnkey | |
|---|---|---|---|
| Rule format | JSON rules with typed criteria | JSON rules with field conditions | Expression language strings |
| Unmatched operation | Accepted if no rule targets it | Denied | Denied (implicit deny) |
| Conflict rule | Matching reject beats accept
|
DENY beats ALLOW
|
EFFECT_DENY beats EFFECT_ALLOW
|
| Policies per wallet | 1 project + 1 account | 1 per wallet, 1 override per signer | 5 per organisation (250 on Enterprise) |
| USD-denominated check |
netUSDChange, per transaction |
No | No |
| Rolling spend cap | Not public (rateLimiting in spec only) |
Yes, aggregations, 1 to 72 hours | Not released ("usage controls" in SDKs) |
| Who can bypass | API key with "Manage" scope edits policy | Wallet owner; app secret if no owner set | Root quorum, by design |
| Rejection error | HTTP 403 policy_violation
|
HTTP 400 policy_violation
|
OUTCOME_DENY_EXPLICIT / _IMPLICIT
|
Read the full article on tomcn.uk →
About the Author
I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.
Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.
Top comments (0)