Policy engines de Privy y Turnkey vs x402: lo que ve el signer

El último control de gasto que tiene un agente autónomo es el policy engine que vive junto a su key. En un pago x402, ese engine nunca ve una transacción. Ve un mensaje EIP-712, y la forma de ese mensaje depende del adapter de wallet que lo construyó. Capturamos esas formas para Privy y Turnkey y leímos ambos lenguajes de policies para ver dónde un tope realmente aplica.

Los proveedores de wallets gestionadas le venden la misma promesa a quien construye agentes. El agente nunca tiene la private key. Las keys viven en un enclave. Un policy engine dentro de ese enclave decide qué puede firmar el agente. Si al agente le inyectan un prompt, o su código queda comprometido, la policy se mantiene.

Esa promesa se escribió para transacciones. Un pago x402 en EVM no es una transacción. El agente firma un TransferWithAuthorization de EIP-3009 o un mensaje de Permit2. Un facilitator lo envía y paga el gas. Toda regla escrita sobre eth.tx.value o sobre el campo to de una transacción no lo ve en absoluto.

Privy y Turnkey lo saben, y los dos engines pueden parsear typed data EIP-712. Esta auditoría pregunta qué obtiene un desarrollador siguiendo sus guías de x402, y qué no puede expresar todavía ninguno de los dos engines.

Fuentes: la documentación de Privy y Turnkey consultada el 11 de octubre de 2026; @x402/evm 2.28.0; viem 2.57.4; @turnkey/viem 0.14.45, publicado el 8 de octubre; @privy-io/node 0.35.0; la referencia del Policy Engine de Coinbase CDP; y la respuesta 402 en vivo de nuestro propio gateway. No abrimos cuentas en Privy ni en Turnkey. Donde un resultado depende de un evaluador de policies cerrado, lo decimos.

La versión corta:

• La ruta x402 documentada por Turnkey, new ExactEvmScheme(turnkeyAccount), le envía a Turnkey un payload EIP-712 con el domain vacío. Un signer que hashea lo que recibe produce una firma que falla la verificación contra USDC. Un pull request en borrador en el propio repositorio del SDK de Turnkey describe el mismo bug. No está mergeado.
• Las condiciones de typed data de Privy solo se evalúan cuando el mapa types de la policy coincide exactamente con el del request. Si no coincide, la condición es falsa, así que una regla DENY deja de dispararse en silencio. Privy lo documenta, y nuestra captura coincide con su tabla.
• Ninguno de los dos engines puede llevar un total acumulado de pagos con typed data. Las aggregations stateful de Privy solo aceptan eth_signTransaction y eth_signUserOperation. El lenguaje de policies de Turnkey se evalúa request por request.
• Ninguno puede acotar la ventana de validez de una autorización en relación con la hora actual. En x402, esa ventana la fija el vendedor.

Un pago, tres formas

Antes de mirar los engines, conviene saber exactamente qué le pide un cliente x402 a una wallet que firme. Leímos el código del cliente en @x402/evm 2.28.0. Hay tres formas.

Exact, EIP-3009. Es la forma por defecto. El cliente firma un solo mensaje TransferWithAuthorization. El domain es el del propio token: name y version tomados del campo extra del vendedor, el chain ID y la dirección del token como verifyingContract. El mensaje lleva from, to, value, validAfter, validBefore y un nonce aleatorio de 32 bytes. El cliente pone validAfter en 0 y validBefore en la hora actual más el maxTimeoutSeconds del vendedor.

Exact, Permit2. Cuando el vendedor define assetTransferMethod: "permit2", el cliente firma un PermitWitnessTransferFrom bajo el domain de Permit2 en 0x000000000022D473030F116dDEE9F6B43aC78BA3. El monto y el token van en un struct anidado permitted. El spender es el proxy exact de x402, 0x402085c248EeA27D92E8b30b2C58ed07f9E20001. El destinatario no es un campo de primer nivel. Está en un struct anidado witness con dos campos, to y validAfter.

Upto, Permit2. El scheme medido que cubrimos en nuestro post sobre upto usa el mismo primary type con otro spender, 0x4020A4f3b7b90ccA423B9fabCc0CE57C6C240002, y otro witness. Su tipo Witness tiene tres campos: to, facilitator y validAfter.

Las rutas Permit2 pueden sumar una segunda firma. Si la wallet todavía no aprobó a Permit2 y el vendedor anuncia una extensión de gas sponsoring, el cliente firma algo más. Corrimos el cliente contra un signer de prueba para ver qué. Con eip2612GasSponsoring, firmó un segundo mensaje de typed data: un Permit EIP-2612 sobre el domain de USDC, por el monto exacto del pago. Con erc20ApprovalGasSponsoring, firmó una transacción cruda: approve(Permit2, 2^256 - 1) sobre el contrato de USDC. Cuando el signer no podía leer el estado de la cadena, el cliente se saltó ambas extensiones.

Ese último caso importa para quien escribe policies. Una aprobación ilimitada a Permit2 significa que cualquier firma Permit2 posterior de esa wallet puede mover su USDC. Una policy que permita mensajes Permit2 tiene que fijar el spender a los proxies de x402, no solo el token.

Qué le llega al signer

Los policy engines evalúan el payload que reciben, no el que el cliente x402 quería enviar. Así que capturamos ese payload. El harness corrió ExactEvmScheme y UptoEvmScheme de @x402/evm 2.28.0 contra tres signers, con todos los backends simulados y sin llamadas de red. El mock de Turnkey registra el request signRawPayload y firma el hash EIP-712 exactamente del JSON que recibió, que es lo que debe hacer cualquier signer de typed data del lado del servidor. El mock de Privy registra el body de signTypedData. El request era un pago de 0.01 USDC en Base.

# exact / EIP-3009 — cuenta de Turnkey pasada directo a ExactEvmScheme
encoding   PAYLOAD_ENCODING_EIP712   hashFunction HASH_FUNCTION_NO_OP
types      ["TransferWithAuthorization"]
domain     {}
message    {"from":"0x19e7…","to":"0x2096…","value":"10000","validAfter":"0",
            "validBefore":"1791709666","nonce":"0xa9a0…"}
verifica contra el domain de USDC: false

# exact / EIP-3009 — la misma cuenta de Turnkey, envuelta en un WalletClient de viem
types      ["EIP712Domain","TransferWithAuthorization"]
domain     {"name":"USD Coin","version":"2","chainId":8453,
            "verifyingContract":"0x833589fcd6edb6e08f4c7c32d4f71b54bda02913"}
message    direcciones en minúsculas, valores uint256 como strings decimales
verifica contra el domain de USDC: true

# exact / EIP-3009 — Privy createViemAccount (lo que usa createX402Client)
types      ["TransferWithAuthorization"]
domain     {"name":"USD Coin","version":"2","chainId":8453,
            "verifyingContract":"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"}
message    {"value":"0x2710","validAfter":"0x0","validBefore":"0x6acb51e2",…}
            direcciones con checksum, valores uint256 como strings hex
verifica contra el domain de USDC: true

Las corridas Permit2 siguieron el mismo patrón. La cuenta de Turnkey sin envolver volvió a enviar un domain vacío. A través de un WalletClient, Turnkey recibió el domain de Permit2, pero solo las direcciones de primer nivel quedaron en minúsculas. Los campos anidados permitted.token y witness.to llegaron con checksum. Privy recibió el domain completo, los tres tipos de struct y números en hex.

Tres formatos de cable distintos para un mismo pago. Las reglas de cada engine tienen que coincidir con el que realmente recibe.

Turnkey: el domain que nunca sale del proceso

La guía de pagos agénticos de Turnkey muestra la integración x402 en dos líneas. Crear una cuenta con createAccount de @turnkey/viem. Registrar new ExactEvmScheme(turnkeyAccount). La guía dice que el scheme "acepta cualquier cuenta de viem, así que el signer de Turnkey funciona como reemplazo directo".

No es un reemplazo directo, por una razón que está en viem. @turnkey/viem implementa signTypedData llamando a viem.serializeTypedData y enviando el resultado con PAYLOAD_ENCODING_EIP712. En viem 2.57.4, serializeTypedData devuelve un domain vacío cuando el mapa types no tiene una entrada EIP712Domain. El cliente x402 nunca la incluye. Su mapa de tipos para EIP-3009 contiene solo TransferWithAuthorization.

Una cuenta local de viem no cae en esto, porque viem deriva EIP712Domain del objeto domain antes de hashear. Un WalletClient de viem tampoco, porque su acción signTypedData agrega la entrada antes de llamar a la cuenta. El ejemplo with-x402 anterior de Turnkey, construido sobre x402 0.7.2, firma a través de un WalletClient. La guía actual pasa la cuenta sin envolver, así que el domain se pierde antes de que el request salga del proceso.

Los ingenieros de Turnkey ya lo encontraron. tkhq/sdk#1520, un borrador abierto el 12 de septiembre, dice que la firma directa con la cuenta "actualmente descarta el domain EIP-712 recibido cuando se omite types.EIP712Domain, produciendo firmas que fallan la verificación contra el input original". También advierte que "las decisiones de policy basadas en el domain pueden cambiar". Un contribuidor externo propuso un fix similar en #1198 en febrero. Ambos siguen abiertos. Desde el 12 de septiembre salieron cinco releases de @turnkey/viem, y la 0.14.45 todavía tiene el código viejo.

De ahí salen dos consecuencias. Primero, un agente de Turnkey en la ruta documentada no puede completar un pago x402: la firma no coincide con el domain de USDC, así que el facilitator la rechaza. Segundo, cualquier condición de policy sobre eth.eip_712.domain no tiene nada que leer. Hasta que salga el fix, el workaround es el que usaba el ejemplo anterior: envolver la cuenta en un WalletClient y pasar un signer cuyo signTypedData pase por el WalletClient. En nuestro harness, eso produjo una firma válida.

Qué puede decir el lenguaje de Turnkey

Una vez que el domain llega, el lenguaje de policies de Turnkey es expresivo. eth.eip_712 expone primary_type, un domain con name, version, chain_id y verifying_contract, y un mapa message. Los campos anidados usan notación de corchetes, así que eth.eip_712.message['witness']['to'] alcanza el destinatario de Permit2. Los arrays soportan .all(), .any() y .count().

Cinco detalles importan para x402.

El ejemplo documentado de EIP-3009 no pone tope a nada. Los ejemplos de Ethereum de Turnkey permiten firmar EIP-3009 cuando domain.name == 'USD Coin' y el primary type es TransferWithAuthorization. No hay condición sobre value, sobre to, sobre la cadena ni sobre la dirección del token. Copiado tal cual, deja que el agente firme cualquier autorización de USDC, a cualquiera, por cualquier monto.

La plantilla de agente no permite x402 en absoluto. Turnkey niega por defecto. La guía de wallets agénticas le da al agente una policy de firma base para ACTIVITY_TYPE_SIGN_TRANSACTION_V2 y ACTIVITY_TYPE_ETH_SEND_TRANSACTION. El typed data pasa por ACTIVITY_TYPE_SIGN_RAW_PAYLOAD_V2, que esa policy no cubre. Su tope de gasto está escrito como eth.tx.value > 500000000000000000, que ningún pago x402 va a disparar nunca.

Las minúsculas son un requisito. Los docs piden hex en minúsculas en las policies EIP-712 y advierten que las mayúsculas "pueden provocar errores o rechazo de la policy". Sin embargo, los propios ejemplos de Permit2 de los docs comparan contra una dirección de USDC con checksum. En nuestra captura, las direcciones anidadas llegaron con checksum. No pudimos probar cómo las normaliza el evaluador. Prueba ambas variantes antes de confiar en una allowlist sobre witness.to.

La firma cruda es una puerta trasera. El mismo tipo de activity también firma bytes arbitrarios con PAYLOAD_ENCODING_HEXADECIMAL y HASH_FUNCTION_NO_OP. Eso es un digest precalculado, y un digest puede ser cualquier hash EIP-712. Turnkey documenta una regla de deny exactamente para este caso. Toda regla de allow para x402 también debería fijar activity.params.encoding == 'PAYLOAD_ENCODING_EIP712'.

Root y consensus cambian el panorama. Si un quórum de usuarios root ejecuta una acción, Turnkey la permite sin consultar policies, así que un agente nunca debe ser usuario root. Turnkey también puede exigir un segundo aprobador por encima de un umbral. Con x402, esa aprobación no puede bloquear y esperar. @turnkey/viem lanza TurnkeyConsensusNeededError cuando una activity necesita más aprobaciones, y el cliente x402 hace fallar el pago. Un nivel de aprobación humana tiene que estar fuera del reintento síncrono del 402.

Un límite más: los enteros del lenguaje son de 128 bits. La aprobación a Permit2 en la ruta de gas sponsoring es 2^256 - 1, fuera de ese rango. Una policy puede reconocer la llamada approve y su spender, pero no puede comparar ese monto numéricamente.

Privy: types exactos, o la regla nunca se dispara

El soporte x402 de Privy es propio. createX402Client en @privy-io/node arma un cliente x402 alrededor de una wallet de Privy, y las apps React tienen useX402Fetch en @privy-io/react-auth. El cliente de Node registra el scheme exact para EVM y Solana. No registra upto y no pasa configuración RPC, así que las extensiones de gas sponsoring de Permit2 nunca se activan a través de él.

El policy engine de Privy corre en el secure enclave. Las reglas se definen por método RPC. Un método sin regla se niega. DENY gana sobre ALLOW. El typed data tiene dos field sources: ethereum_typed_data_domain para chainId y verifyingContract, y ethereum_typed_data_message para rutas con puntos dentro del mensaje, como to, value o witness.to.

El source del mensaje tiene una regla filosa. La página de ejemplos de Privy lo dice sin rodeos. Una condición sobre el mensaje de typed data "solo se evalúa cuando el mapa types declarado en la policy coincide exactamente con el mapa types del request de firma", incluido el orden de los campos. Si no coincide, "una regla DENY nunca se dispara, y una regla ALLOW permisiva sobre el mismo método firma el request".

La receta de sanctions screening para x402 de Privy va más allá y lista qué clientes envían qué mapa. Sus propios createX402Client y useX402Fetch envían solo TransferWithAuthorization. Un WalletClient de viem, o cualquier integración que arme la llamada por su cuenta, también envía EIP712Domain. La receta nombra a AgentCore Payments como uno de esos casos. Nuestra captura coincidió con la primera fila: sin EIP712Domain, domain completo, números en hex.

Es el diseño correcto, y está bien documentado. Pero crea un modo de falla que solo aparece cuando cambias de cliente. Supón que un equipo escribe una regla DENY fijada al mapa del cliente de Node y una regla ALLOW amplia fijada solo al domain. Después el equipo pone al agente detrás de un framework basado en WalletClient. El mapa del request gana EIP712Domain. La regla DENY deja de coincidir. La regla ALLOW sigue pasando. Nada da error. La receta de Privy lo evita fijando ambas reglas al mismo mapa, así un cambio de forma falla cerrado. Copia ese patrón, no el más laxo.

Las rutas Permit2 lo empeoran. Los tipos Witness de exact y de upto difieren en un campo. Con semántica de coincidencia exacta, una sola regla no puede cubrir ambos. Una wallet que paga a los dos tipos de vendedor necesita una regla por forma, por cliente.

Dos detalles más:

Los hashes crudos no tienen método de regla. El adapter de viem de Privy firma hashes crudos mediante secp256k1_sign. Ese método no está en el tipo PolicyMethod del SDK, que termina con el comodín '*'. Con deny por defecto, una policy sin regla comodín rechaza la firma de hashes crudos. No pongas reglas ALLOW comodín en wallets de agentes.

Los umbrales siguen el formato de cable. El adapter de Node convierte todo bigint a hex, así que value llega como "0x2710". Los propios ejemplos numéricos de Privy escriben los umbrales en hex. No pudimos confirmar cómo compara el evaluador formatos mixtos, así que sigue la convención hex.

Lo que ninguno de los dos engines puede decir

Las reglas a nivel de campo cubren una firma a la vez. Tres cosas que el dueño de un agente suele querer quedan fuera de alcance en ambas plataformas.

Para completar, revisamos de nuevo la referencia del Policy Engine de Coinbase CDP, que cubrimos en nuestra auditoría de Wallet MCP. A hoy, sus criterios de typed data, evmTypedDataField y evmTypedDataVerifyingContract, existen solo bajo signEndUserEvmTypedData. La lista de operaciones para server accounts no tiene una entrada de typed data. Su operación signEvmHash no acepta criterios y solo se puede rechazar por completo.

Vistos en conjunto, los tres proveedores están en puntos distintos. Privy puede acotar con precisión una firma x402 individual, si el mapa de types es el correcto. Turnkey también, una vez que su adapter conserve el domain. CDP puede hacerlo para wallets de usuario final pero no para server wallets. Ninguno puede aplicar hoy un presupuesto x402 acumulado dentro del engine. Eso coincide con lo que encontramos en la capa de smart accounts en la auditoría de Crossmint: en EVM, el total acumulado es la parte que sigue quedando fuera de alcance.

Una policy para pagarle a LLM4Agents

El 402 de nuestro endpoint walk-up es un objetivo simple. Lo leímos hoy con un request sin autenticar: scheme exact, network eip155:8453, asset USDC de Base en 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913, payTo 0x0D741Ab0968906f8338C60f79b81B49c23258C12, maxTimeoutSeconds 300, y extra con "USD Coin" versión "2". Una llamada a gpt-5 con max_tokens 256 se cotizó en 10000, o 0.01 USDC. Es la forma EIP-3009: un mensaje, un mapa de types.

Esta es una regla de Privy para los clientes x402 de Node y React, con tope de 0.25 USDC por firma. Fija cadena, token, destinatario y monto, y declara el mapa exacto que envían esos clientes.

const twa = {
  types: { TransferWithAuthorization: [
    { name: 'from', type: 'address' }, { name: 'to', type: 'address' },
    { name: 'value', type: 'uint256' }, { name: 'validAfter', type: 'uint256' },
    { name: 'validBefore', type: 'uint256' }, { name: 'nonce', type: 'bytes32' } ] },
  primary_type: 'TransferWithAuthorization',
};

{
  version: '1.0', name: 'Agent pays LLM4Agents on Base', chain_type: 'ethereum',
  rules: [{
    name: 'LLM4Agents, max 0.25 USDC per signature',
    method: 'eth_signTypedData_v4', action: 'ALLOW',
    conditions: [
      { field_source: 'ethereum_typed_data_domain', field: 'chainId', operator: 'eq', value: '8453' },
      { field_source: 'ethereum_typed_data_domain', field: 'verifyingContract', operator: 'eq',
        value: '0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913' },
      { field_source: 'ethereum_typed_data_message', typed_data: twa, field: 'to', operator: 'eq',
        value: '0x0D741Ab0968906f8338C60f79b81B49c23258C12' },
      { field_source: 'ethereum_typed_data_message', typed_data: twa, field: 'value', operator: 'lte',
        value: '0x3D090' }, // 250000 = 0.25 USDC
    ],
  }],
  // sin regla '*': todos los demás métodos siguen negados por defecto
}

Y el equivalente en Turnkey, para una cuenta de Turnkey que firma a través de un WalletClient hasta que salga el fix del domain. Las direcciones van en minúsculas, como piden los docs de Turnkey.

{
  "policyName": "Agent pays LLM4Agents on Base, max 0.25 USDC per signature",
  "effect": "EFFECT_ALLOW",
  "consensus": "approvers.any(user, user.id == '<AGENT_USER_ID>')",
  "condition": "activity.type == 'ACTIVITY_TYPE_SIGN_RAW_PAYLOAD_V2'
    && activity.params.encoding == 'PAYLOAD_ENCODING_EIP712'
    && wallet.id == '<AGENT_WALLET_ID>'
    && eth.eip_712.primary_type == 'TransferWithAuthorization'
    && eth.eip_712.domain.chain_id == 8453
    && eth.eip_712.domain.verifying_contract == '0x833589fcd6edb6e08f4c7c32d4f71b54bda02913'
    && eth.eip_712.message['to'] == '0x0d741ab0968906f8338c60f79b81b49c23258c12'
    && eth.eip_712.message['value'] <= 250000"
}

La condición aparece en varias líneas para leerla mejor. En la API es un solo string. Combínala con la regla de deny documentada por Turnkey para payloads HASH_FUNCTION_NO_OP que no sean EIP-712.

Qué significa para LLM4Agents

Un signer roto del comprador parece un vendedor roto. Un agente de Turnkey que sigue la ruta x402 documentada nos envía una firma sobre un domain vacío. La verificación falla y el agente recibe otro 402. Desde el lado del comprador, nuestro endpoint simplemente se niega a aceptar el pago. Deberíamos reconocer ese caso y decir qué es.

Nuestro 402 es la forma fácil, y vale la pena conservarla. Exact EIP-3009 significa un tipo de mensaje, un mapa de types, el domain propio del token y un destinatario de primer nivel. Es la forma que mejor maneja cada engine de esta auditoría. Si agregamos rutas Permit2 o upto, los compradores necesitan más reglas, un chequeo de destinatario en una ruta anidada y posiblemente una aprobación ilimitada a Permit2. Ese costo tiene que entrar en la decisión.

Nuestro payTo ya es parte de la configuración de seguridad de otros. Un comprador con allowlist de destinatarios fija nuestra dirección en su policy. Si la rotamos, cada uno de esos compradores falla cerrado a la vez, sin ningún error de nuestro lado. El payTo tiene que tratarse como una constante publicada y versionada.

Nuestra ventana de 300 segundos es la ventana que reciben los compradores. Ningún engine puede acotar validBefore en relación con ahora, así que el signer de un comprador no puede rechazar una ventana larga nuestra. Mantener corto el maxTimeoutSeconds es responsabilidad nuestra, no de ellos.

Los topes por firma se encuentran con nuestra cotización. Cada tope de esta auditoría compara contra el monto de la autorización, que es nuestra cotización de peor caso, no la factura final. Como en la auditoría del tope de gasto del SDK x402, un tope ajustado del comprador rechaza las llamadas que cotizamos alto. La precisión de la cotización decide si los compradores con tope pueden pagarnos.

Cómo mantenerse en la frontera

1. Detectar la firma con domain vacío. Cuando un pago falla la verificación, recalcular el digest EIP-3009 con un domain vacío y ver si recupera a from. Si es así, devolver un error que diga que el signer del comprador perdió el domain EIP-712 y que apunte al workaround con WalletClient. Son pocas líneas de código, y convierten un rechazo silencioso en una respuesta de soporte.

2. Publicar un kit de policies para compradores. Publicar las dos policies de arriba, más una versión para usuario final de CDP, fijadas a nuestra cadena, token, payTo y un tope sugerido. Incluir los mapas de types exactos para cada cliente y los tres pagos de prueba. Los compradores con límites son los compradores que queremos, así que hay que hacer fácil poner límites.

3. Correr la matriz en engines reales. Privy y Turnkey ofrecen cuentas self-serve. En Base Sepolia, correr los tres pagos de prueba en cada engine, más umbrales hex contra decimales, direcciones con checksum contra minúsculas y la ruta de cuenta sin envolver de Turnkey. Publicar qué hace realmente cada evaluador con los casos que solo pudimos inferir.

4. Congelar y publicar payTo y maxTimeoutSeconds. Listar ambos en nuestra documentación pública como valores versionados. Anunciar cualquier cambio con anticipación, con un período de solapamiento en el que se acepten ambas direcciones.

5. Mantener exact EIP-3009 como rail por defecto. Si agregamos upto para llamadas medidas, publicar al mismo tiempo plantillas de policy para su forma de Witness, y nunca exigir la extensión de aprobación ilimitada.

6. Seguir los dos cambios upstream. Vigilar tkhq/sdk#1520 por el fix del domain y la lista de métodos de aggregation de Privy por soporte de typed data. Cuando cualquiera se mueva, repetir el paso tres. Un tope x402 acumulado dentro del enclave sería el control más útil del lado del comprador en todo este stack.

Los pasos uno y dos son baratos y ayudan a los compradores esta semana. El tres reemplaza inferencia por medición. El cuatro y el cinco nos mantienen fáciles de poner en allowlist. El seis es donde se va a mover la frontera.