Coinbase Agent SDK: ¿Quién controla la clave?

Coinbase lanzó el jueves un nuevo kit de desarrollo de software que permite a los agentes de IA ejecutar operaciones, realizar pagos y gestionar carteras de criptoactivos en nombre de los usuarios. Los titulares se centrarán en la funcionalidad de trading —un agente de IA que puede intercambiar tokens o reequilibrar una cartera es una demo atractiva—. Pero la arquitectura subyacente revela una cuestión más fundamental que toda empresa que construye infraestructura de pagos agentivos se ve ahora obligada a responder: ¿quién posee la clave privada y qué sucede cuando el agente hace algo que el usuario no esperaba? La respuesta de Coinbase es un modelo de custodia basado en monederos de computación multiparte y límites de gasto preautorizados, y nos dice exactamente dónde está trazando la industria la línea entre autonomía y control.

El monedero MPC: por qué el agente nunca ve la clave

La primitiva de custodia central del SDK es un monedero de computación multiparte. En una configuración MPC, la clave privada nunca se ensambla en un solo lugar. Se divide en fragmentos distribuidos entre múltiples partes —en este caso, la infraestructura de Coinbase y el dispositivo del usuario— y las transacciones se firman mediante un cálculo colaborativo que nunca reconstruye la clave completa. Para un agente de IA, esto significa que el propio agente nunca posee una clave privada sin procesar. Puede solicitar una transacción, pero el proceso de firma requiere que se ejecute el protocolo MPC, el cual Coinbase puede controlar con verificaciones de políticas.

Esto no es un detalle de implementación menor. Es la decisión arquitectónica que separa “el agente tiene un monedero” de “el agente tiene permiso para solicitar un pago”. Lo primero implica que el agente puede mover fondos unilateralmente. Lo segundo implica que un custodio se sitúa entre la intención del agente y la liquidación en cadena. Coinbase eligió lo segundo, y los límites de gasto son el mecanismo que refuerza la frontera. Los usuarios establecen topes por agente, por transacción y por período de tiempo. Si un agente intenta excederlos, la ceremonia de firma MPC falla. El agente se queda con una solicitud que no puede ser satisfecha, no con una clave de la que se pueda abusar.

La estructura de dos capas se está convirtiendo en estándar de la industria

Escribimos a principios de semana que Visa y Mastercard están convergiendo en una arquitectura de dos capas para pagos agentivos: la identidad y la autorización residen en raíles heredados o controlados por el custodio, mientras que la liquidación ocurre en cadena con stablecoins. El SDK de Coinbase encaja precisamente en este patrón. El monedero MPC y los límites de gasto forman la capa de autorización. La liquidación real —la transferencia de USDC, el intercambio de tokens, la ejecución de la operación— ocurre en Base o Ethereum. El agente interactúa con la capa de autorización a través de una API. Nunca toca directamente la capa de liquidación.

Este es el mismo patrón que utiliza el protocolo AP4M de Mastercard, con su conjunto de validadores autorizados verificando la identidad del agente antes de permitir la liquidación. Es el mismo patrón que Visa está construyendo con su marco de Puntuación de Agentes y el piloto de Canton Network. La diferencia es que Coinbase es un custodio nativo de cripto en lugar de una red de tarjetas, por lo que la capa de autorización es una política aplicada por contrato inteligente en lugar de una aprobación mediada por un banco. Pero la lógica estructural es idéntica: separar la decisión de pagar del acto de pagar, y poner un guardián en medio.

Lo que el agente puede hacer realmente —y lo que no puede—

El SDK expone tres categorías de capacidades. Primero, pagos: un agente puede enviar USDC a una dirección especificada, dentro de los límites de gasto. Segundo, trading: el agente puede ejecutar intercambios, colocar órdenes limitadas y reequilibrar una cartera entre los activos disponibles en Coinbase. Tercero, gestión de carteras: el agente puede leer saldos, seguir el rendimiento y generar informes. Todas estas son llamadas a la API que el monedero MPC firma si y solo si la verificación de políticas se supera.

Lo que el agente no puede hacer es cambiar la política. No puede aumentar su propio límite de gasto. No puede eliminar el fragmento MPC que posee Coinbase. No puede exportar la clave privada. Estas restricciones no son aplicadas por el código del agente —son aplicadas por la infraestructura de custodia—. Esa es la distinción crítica. El código de un agente puede tener errores, ser liberado o recibir inyección de prompts. Se supone que la capa de custodia es el interruptor de seguridad que se mantiene incluso cuando la lógica del agente falla. Si realmente lo hace es una cuestión de calidad de implementación, pero la arquitectura al menos reconoce el problema.

La pregunta sin respuesta: ¿quién es responsable cuando el agente se equivoca?

La documentación de Coinbase no parece abordar la responsabilidad por transacciones iniciadas por el agente que cumplen con la política pero producen resultados indeseables. Si un usuario establece un límite diario de 1.000 $ y el agente ejecuta una serie de malas operaciones que pierden el importe total, el monedero MPC firmará cada una de ellas. La política se cumplió. El agente hizo exactamente lo que se le permitía hacer. La pérdida es del usuario.

Esta es la frontera que nadie ha resuelto todavía. Los límites de gasto protegen contra un agente comprometido que vacía un monedero instantáneamente. No protegen contra un agente que simplemente es malo en su trabajo, o uno que es manipulado mediante inyección de prompts para tomar una serie de decisiones individualmente permisibles pero colectivamente ruinosas. La industria está construyendo los raíles para el comercio agentivo a una velocidad notable, pero el marco de responsabilidad sigue siendo una página en blanco. El SDK de Coinbase es una respuesta sofisticada a la cuestión de la custodia. La cuestión de la responsabilidad sigue completamente abierta.