¿De qué trata la transición de los agentes de IA a los límites de permisos en la cadena? ERC-8004 está revolucionando la forma en que gestionamos los permisos y la seguridad en las aplicaciones descentralizadas, permitiendo un control más granular y seguro sobre las acciones que los agentes de IA pueden realizar en la blockchain. Este estándar está abriendo nuevas posibilidades para la interoperabilidad y la protección de datos en el ecosistema blockchain.

Autor: CoinW Research Institute

Resumen

Con el desarrollo de aplicaciones como DeFi, abstracción de cuentas y AI Agent, la autorización en la cadena está evolucionando desde una confirmación de firma única y puntual hacia un sistema de permisos con efecto a largo plazo y reutilizables. Al mismo tiempo, también están ocurriendo cambios: los AI Agent ya tienen la capacidad de solicitar servicios automáticamente y completar pagos de forma automática, por ejemplo, el protocolo x402 utiliza el código de estado HTTP 402 para permitir que el Agent pague recursos y servicios en tiempo real con stablecoins sin intervención humana. Esto hace que las acciones en la cadena de bloques ya no sean transacciones aisladas, sino procesos continuos de colaboración automatizada.

En este contexto, el problema de la autorización se amplifica aún más. Los métodos actuales de autorización en el ecosistema Web3 siguen siendo imprecisos y rudimentarios, generalmente solo resuelven si se puede usar un activo, pero no responden claramente qué acciones específicas están permitidas o en qué nivel. ERC-8004 surge precisamente en este escenario. No define nuevos activos ni altera cómo se ejecutan transacciones o pagos, sino que intenta establecer un modelo de permisos en la cadena que pueda ser entendido y verificado por el sistema, haciendo que la autorización sea un objeto describible, restringible y gestionable.

Desde una perspectiva de sistema más amplio, ERC-8004 no compite con la abstracción de cuentas ni con protocolos de pago automatizado como x402, sino que opera en diferentes niveles de división del trabajo: x402 resuelve el intercambio de valor después de que ocurre la acción, mientras que ERC-8004 se centra en quién está autorizado a actuar y si los permisos se exceden antes de que la acción suceda. En escenarios como DeFi, AI Agent, empresas y RWA, esta estructura de permisos previos y pagos posteriores puede impulsar la transición de permisos a nivel de activos hacia permisos a nivel de comportamiento, proporcionando una base controlada para colaboraciones automatizadas más complejas y a largo plazo. Aunque todavía enfrentamos desafíos en costos de aprendizaje, soporte en wallets y experiencia de usuario, ERC-8004 no es solo una herramienta narrativa a corto plazo, sino un estándar fundamental que determinará si Web3 puede soportar sistemas complejos en su funcionamiento.

1. Motivaciones para la propuesta de ERC-8004

Con la evolución continua de la infraestructura en la cadena, la capacidad de poner activos y ejecutar transacciones se ha ido abstraiendo y fortaleciendo. Desde ERC-20, NFT, hasta multi-sig y abstracción de cuentas (ERC-4337), la participación del usuario en actividades en la cadena ha bajado de barrera, y las cuentas se vuelven cada vez más inteligentes.

Pero en este proceso, un problema fundamental no ha sido resuelto de manera sistemática: el mecanismo de autorización en sí mismo no ha evolucionado sustancialmente. En los primeros tiempos de Web3, la autorización significaba una firma de clave privada. El usuario expresaba “estoy de acuerdo” mediante una firma, ya fuera para transferencias, llamadas a contratos o aprobaciones, y esta autorización se consideraba una confirmación única, con riesgos asumidos completamente por el usuario.

Hoy en día, el entorno en la cadena ha cambiado. En DeFi, las aprobaciones suelen ser válidas a largo plazo; en estrategias automatizadas y sistemas de Session Keys, la autorización se reutiliza varias veces; en modos donde AI Agent o bots ejecutan transacciones, el usuario incluso ya no participa directamente en cada operación. La autorización está evolucionando de una confirmación única a una capacidad de ejecución continua, más parecida a delegar el poder de hacer algo durante un período.

El problema es que la infraestructura actual de Web3 casi no ofrece una forma clara y unificada de restringir este estado de autorización a largo plazo. Los límites de permisos son imprecisos, la revocación difícil, y los riesgos impredecibles, lo que genera muchas vulnerabilidades de seguridad. Además, la abstracción de cuentas amplifica esta contradicción: cuando las cuentas pueden ejecutar transacciones automáticamente y pagar Gas por terceros, lo que pueden o no pueden hacer se vuelve aún más difuso.

En este escenario, surge ERC-8004, que intenta completar un eslabón que falta en Web3: establecer un modelo de permisos claro, restringible y comprensible por el sistema para la autorización en sí misma.

2. Contenido central de ERC-8004

El enfoque de ERC-8004 no está en la forma del activo ni en cómo se ejecutan las transacciones, sino en si la autorización puede ser descrita, verificada de forma independiente y gestionada continuamente a nivel del sistema.

2.1 ¿Qué define ERC-8004?

Según la definición en el sitio oficial de Ethereum Improvement Proposals (EIP): ERC-8004 es un protocolo estándar para descubrir, seleccionar e interactuar con agentes autónomos confiables en Ethereum. A través de registro en la cadena, mecanismos de reputación y verificación, construye una infraestructura de agentes descentralizados sin necesidad de confianza previa.

Aquí, los “agentes autónomos” no se limitan a AI Agent, sino que incluyen cualquier entidad que pueda ser autorizada y ejecutar acciones de forma independiente, como contratos, scripts automatizados, multi-sig o procesos de servicio. ERC-8004 se enfoca en si el agente tiene la capacidad de tener permisos y límites claros, siendo AI Agent solo una aplicación típica.

Desde una perspectiva más general, ERC-8004 no es un estándar de activos o un tipo de cuenta nuevo, sino un marco para expresar y verificar permisos en la cadena, que describe en qué condiciones un sujeto puede ejecutar qué acciones, y verificarlo antes de la operación. Por tanto, no trata de “qué es el dinero” o “cómo se ejecuta la transacción”, sino de “qué acciones están permitidas”. No crea nuevos activos ni altera atributos de activos existentes, sino que añade una capa de reglas de permisos clara y verificable sobre activos y cuentas.

Además, ERC-8004 no reemplaza la abstracción de cuentas (ERC-4337). La abstracción de cuentas se ocupa de cómo se ejecutan las transacciones, mientras que ERC-8004 resuelve la decisión de permisos antes de que la transacción ocurra. Si la abstracción de cuentas hace que las cuentas sean más flexibles, ERC-8004 establece límites claros para esa flexibilidad.

El núcleo de ERC-8004 es transformar la autorización, que antes estaba implícita en la firma, en un objeto de permisos que puede ser descrito claramente, verificado de forma independiente y gestionado de manera continua.

2.2 Marco de mecanismos centrales de ERC-8004

Para entender los mecanismos centrales, podemos imaginarlo como una “tarjeta de permisos en la cadena”. En la lógica tradicional, el usuario simplemente decide: “Estoy de acuerdo”, sin distinguir qué puede hacer exactamente, cuánto, o durante cuánto tiempo. En el marco de ERC-8004, una autorización ya no es una simple aprobación difusa, sino que se descompone en un conjunto de reglas claramente describibles y ejecutables por el sistema. Esta “tarjeta de permisos” generalmente incluye cinco tipos clave de información:

Sujeto autorizado (Who): ¿Quién puede ejecutar?
Primero, se define quién recibe los permisos. En ERC-8004, el autorizado no se limita a una dirección fija, sino que puede ser un contrato, un agente automatizado, o incluso una Session Key temporal. Esto permite escenarios más complejos, como que un contrato de estrategia tenga permisos limitados, o que un Agent realice tareas sin firmar repetidamente. Lo importante es que los permisos siempre se otorgan a un “sujeto definido”, no de forma difusa.

Acciones permitidas (What): ¿Qué puede hacer?
Luego, qué acciones específicas están permitidas. La autorización no es un “todo o nada”, sino que puede especificar tipos de operaciones, como solo permitir swaps, transferencias, o llamadas a ciertos métodos, en lugar de abrir todos los permisos. La pregunta aquí no es si se puede usar, sino hasta qué punto.

Condiciones (Under what conditions): ¿Cuándo puede hacerse?
Este es un aspecto clave que diferencia ERC-8004 de autorizaciones tradicionales. La autorización puede incluir restricciones, como límites de monto por operación o acumulado, límites de frecuencia, o que solo funcione en ciertos protocolos o contratos. Estas condiciones deben cumplirse antes de que la acción pueda ejecutarse; no son reglas de monitoreo posterior, sino precondiciones.

Cuándo entra en vigor y cuándo termina (When):
Se puede definir un período de validez, como una ventana temporal, o que la autorización sea solo para una operación, o que pueda ser revocada en cualquier momento. Esto permite gestionar permisos temporales y flexibles, en lugar de permisos permanentes e irrevocables.

Cómo se verifica (How enforced):
Finalmente, estas reglas deben ser verificadas antes de la ejecución. La idea central es que, si una acción no cumple con las reglas definidas, el sistema la rechaza directamente, en lugar de responsabilizar al usuario después. Esto diferencia a ERC-8004 de los enfoques tradicionales de control de riesgos.

2.3 Nuevas capacidades que aporta ERC-8004: ¿Por qué antes no era posible?

A simple vista, ERC-8004 solo hace que la autorización sea más granular, pero en Ethereum, los modelos tradicionales no podían expresar lógica de autorización compleja. Solo verificaban si una dirección podía operar, sin distinguir qué, cuánto o cuándo.

La innovación central de ERC-8004 es que pasa de una “identidad” a una “acción”: el sistema puede decidir si una operación específica cumple con los permisos definidos, en lugar de solo verificar quién la inició. Esto permite incluir condiciones de monto, frecuencia, alcance y validez, sin depender de la revocación manual o monitoreo posterior.

Al estructurar la lógica de autorización, se vuelve componible y reutilizable. Operaciones en múltiples pasos o en diferentes protocolos pueden ser restringidas en la fase de autorización, en lugar de depender de decisiones en tiempo de ejecución. Esto abre espacio para escenarios de agentes automatizados, que ya no necesitan permisos “ilimitados”, sino permisos claros y verificables, que rechacen acciones fuera de rango.

La verdadera innovación de ERC-8004 no es solo hacer la autorización más segura, sino hacer que la lógica sea comprensible y ejecutable por el sistema, diferenciándose de los mecanismos tradicionales.

3. Ámbitos potenciales de aplicación de ERC-8004

ERC-8004 no está diseñado para un producto específico, sino que funciona como un lenguaje universal para capacidades de autorización. Su valor no radica en un escenario único, sino en que diferentes sistemas, ante la creciente complejidad de permisos, compartan una necesidad común de capacidades similares.

DeFi: de autorización a nivel de activos a autorización a nivel de comportamiento

Actualmente, en DeFi, la forma más común de autorización sigue siendo “una sola aprobación con límite infinito”. Por ejemplo, para hacer un swap, préstamo o staking, el usuario aprueba un contrato, entregando control total sobre el activo. Esto es eficiente, pero muy riesgoso: si el contrato se actualiza, se ve comprometido o se usa en lógica no prevista, la autorización se vuelve un vector de riesgo. ERC-8004 permite que los permisos sean específicos a acciones concretas, como: “solo permitir que este contrato use hasta 1,000 USDC en 24 horas para un swap”, en lugar de una autorización ilimitada. Aunque algunos proyectos ya intentan limitar permisos, aún no hay un estándar unificado. ERC-8004 busca estandarizar permisos a nivel de comportamiento, para mejorar la gestión de riesgos y la reutilización.

AI Agent: permisos verificables para ejecución automática

Con la participación de AI Agent en decisiones y ejecuciones en la cadena, la autorización se vuelve aún más importante. Un Agent que opera automáticamente necesita permisos claros y duraderos. Sin una definición precisa, un Agent es solo un programa con control total, con riesgos asociados. ERC-8004 proporciona un marco para definir permisos verificables, que puedan ser revisados antes de la acción, en lugar de depender solo de monitoreo posterior. Solo con permisos estructurados y verificables, la automatización puede ser confiable.

Colaboración con x402: permisos “concedidos” y pagos “resueltos”

En escenarios de Agent, otro problema es cómo realizar el intercambio de valor tras la acción autorizada. Protocolos como x402 intentan resolver esto usando el código HTTP 402 para pagos automáticos en solicitudes de recursos o servicios. En este esquema, ERC-8004 y x402 operan en niveles diferentes pero complementarios: ERC-8004 define quién puede hacer qué, estableciendo permisos y confianza; x402 se ocupa de cómo se realiza el pago y la liquidación. Ambos no dependen uno del otro, pero en conjunto permiten que un Agent, sin intervención humana, pase de tener permisos a completar pagos y valor, en un proceso seguro y desacoplado. Con la expansión de agentes en contenidos, datos y servicios, esta colaboración puede convertirse en una infraestructura escalable.

Empresas y RWA: permisos como base de cumplimiento

En aplicaciones empresariales y RWA, la importancia de ERC-8004 radica en la capacidad de expresar permisos de forma estructurada, que sean auditables y trazables. En el mundo real, la gestión de activos requiere responder quién, en qué condiciones, puede realizar qué acciones. La diferencia con los activos en cadena no es solo si están en la cadena, sino cómo se definen y registran los permisos. ERC-8004 no resuelve directamente la regulación, pero proporciona una base para que los permisos sean claros, verificables y auditables, facilitando la integración con sistemas tradicionales y reduciendo costos de cumplimiento.

En resumen, ERC-8004 no es un estándar “orientado a un escenario” específico, sino una capacidad fundamental que surge ante la creciente complejidad de permisos en la cadena. Cuando las acciones en la cadena evolucionan de operaciones puntuales a sistemas continuos, una forma clara y verificable de expresar permisos se vuelve casi imprescindible.

4. Desafíos y valor a largo plazo de ERC-8004

Desafíos prácticos

Primero, el coste de aprendizaje. La introducción de reglas de permisos más finas requiere que desarrolladores y usuarios entiendan mejor qué significa autorizar en este nivel. Esto lleva tiempo y requiere adopción. Segundo, el soporte en wallets y herramientas. La utilidad de ERC-8004 solo se realiza si las plataformas y SDKs entienden y soportan estas reglas. En etapas iniciales, será una capacidad adicional, no universal. Tercero, la experiencia de usuario. Permisos complejos pueden ser difíciles de entender y manejar para usuarios comunes. La clave será traducir reglas estructuradas en interfaces intuitivas.

ERC-4008 no resuelve el presente, sino la próxima fase

Dado estos obstáculos, ERC-8004 no es solo una narrativa a corto plazo. No generará un crecimiento explosivo inmediato ni nuevos modelos de ingresos. Su valor radica en que, en un entorno cada vez más complejo, permite que los sistemas sigan siendo controlables, comprensibles y verificables. No se trata solo de funciones, sino de dejar una base para que futuras automatizaciones, agentes y participación institucional puedan operar con permisos claros y seguros. En ese sentido, ERC-8004 no es solo un estándar para una temporada, sino una capacidad fundamental que determinará si Web3 puede soportar relaciones de colaboración complejas y duraderas.