Autor: Xiao Bai
Este artículo es una contribución original del autor. Las opiniones expresadas pertenecen únicamente al autor. ETHPanda ha editado y organizado el contenido.
Cuando los Agentes de IA están en la cadena de bloques, el problema ya no es solo "si pueden chatear".
Pueden firmar, recibir pagos, iniciar transacciones, desplegar contratos, gestionar carteras, llamar a APIs, e incluso colaborar con otros agentes para completar tareas. En este punto, lo que realmente preocupa al usuario no es si tiene un nombre bonito, sino:
¿Es este agente realmente confiable?
¿Está su cartera limpia? ¿Existe realmente el contrato al que está asociado? ¿Su sitio web y API tienen riesgos? ¿El contenido multimedia que publica está falsificado? ¿Tiene su código Solidity vulnerabilidades evidentes? ¿Ha sido atacado antes?
ERC-8126 apunta precisamente a este tipo de problemas de verificación.
En pocas palabras, ERC-8126 es la capa de verificación para los Agentes de IA. Se construye sobre el registro de identidad (agent registration) de ERC-8004, permitiendo que proveedores de verificación independientes realicen múltiples capas de verificación en torno a la misma identidad del agente, y conviertan los resultados en señales de riesgo que carteras, mercados, aplicaciones y otros agentes puedan consumir.
No pretende demostrar que un agente sea siempre confiable, sino estandarizar "cómo verificar un agente, cómo expresar los resultados de la verificación y cómo otros sistemas pueden leer esos resultados".
Tener identidad no equivale a ser confiable
ERC-8004 resuelve el problema de la identidad del agente.
Puedes entenderlo así: primero, dar a un Agente de IA una identidad en cadena que pueda registrarse, descubrirse e indexarse. Esta identidad corresponderá a un agentId, y a través de metadatos describirá información como el nombre, cartera, endpoint, sitio web, dirección del contrato, etc., de este agente.
Pero la identidad en sí misma no es igual a confianza.
Un agente malicioso también puede registrar una identidad. Un agente de phishing también puede escribir unos metadatos atractivos. Que un agente funcione hoy no significa que mañana su endpoint no pueda ser secuestrado. Que un agente tenga un avatar, un sitio web oficial y una dirección de cartera, tampoco significa que su contrato sea seguro, su cartera esté limpia o su contenido sea auténtico.
Así que, ERC-8004 se parece más a responder:
¿Quién es este agente?
ERC-8126 pregunta además:
¿Vale la pena interactuar con este agente?
¿Cómo hace la verificación ERC-8126?
Primero, la solicitud de verificación hará referencia al agentId del Registro de Identidades ERC-8004. El proveedor de verificación (Verification provider) leerá luego los metadatos correspondientes a través de este agentId, analizará de ellos información como carteras, contratos, sitios web, endpoints, contenido multimedia, etc., y finalmente generará una puntuación de riesgo y una prueba de verificación.
Este flujo se puede desglosar en cuatro pasos:
- El Agente de IA primero registra su identidad a través de ERC-8004.
- El proveedor ERC-8126 lee el agentId y los metadatos de este agente.
- El proveedor realiza una verificación multicapa del agente.
- Los resultados de la verificación son consumidos por carteras, mercados, dApps u otros agentes en forma de risk score, proof, attestation, etc.
El punto clave aquí es: ERC-8126 no introduce una única "autoridad de certificación oficial".
Se parece más a un mercado abierto de proveedores de verificación. Diferentes proveedores pueden usar sus propios métodos para realizar comprobaciones de seguridad, pero los resultados de salida deben expresarse en un formato estandarizado. Así, carteras, mercados de agentes, mercados de tareas y otras aplicaciones pueden leer estas señales de forma transversal.
Esto va un paso más allá de que "el propio proyecto diga que es seguro": divide el juicio de confianza en señales que pueden ser verificadas, registradas y leídas por terceros.
Cinco capas de verificación: desglosando al agente
ERC-8126 define principalmente cinco tipos de verificación, cubriendo respectivamente varias áreas donde los agentes en cadena son más propensos a tener problemas: contratos, medios, código, web y cartera. Estandariza el tipo de verificación, la expresión del resultado y las interfaces consumibles, no convierte cada comprobación de seguridad en un único método de auditoría oficial. Diferentes proveedores de verificación aún pueden usar sus propios procesos de detección y modelos de riesgo.
ETV: Verificación de Token / Contrato
ETV comprueba el token o contrato asociado al agente.
Si en los metadatos del agente se escribe una contractAddress, el proveedor verificará si esta dirección realmente tiene código de contrato en la cadena correspondiente, si existe un riesgo evidente, o si es simplemente una dirección falsa introducida al azar.
Para el usuario, ETV responde a:
¿Los activos en cadena o contratos que este agente afirma estar asociados, son realmente reales?
Porque una vez que un agente comienza a recibir pagos, emitir tokens, hacer staking, ejecutar estrategias, el contrato detrás deja de ser un adorno y se convierte en el lugar donde realmente interactúan los fondos de los usuarios.
MCV: Verificación de Contenido Multimedia
MCV verifica el contenido multimedia utilizado por el agente, como avatares, imágenes, material de marca, imágenes de certificación, etc.
Esto puede no sonar como un problema central, pero es importante en el contexto de los Agentes de IA. Un agente falso puede suplantar el logo de un proyecto, falsificar capturas de pantalla oficiales, e incluso usar imágenes generadas por IA para crear una sensación de respaldo.
MCV debe verificar la fuente del contenido, integridad, rastros de manipulación, marcas de agua, firmas, etc.
Responde a:
¿El contenido que este agente muestra al usuario ha sido falsificado o manipulado?
SCV: Verificación de Código Solidity
SCV verifica el código Solidity o la seguridad del contrato asociado al agente.
Si los metadatos contienen información relevante del código o contrato, el proveedor puede comprobar riesgos comunes, como reentradas, problemas de permisos, llamadas peligrosas, superficie de ataque de flash loans, etc.
SCV puede reducir algunos riesgos comunes de contratos, pero no equivale a una auditoría manual completa.
Se parece más a un conjunto estandarizado de puntos de entrada para la verificación de seguridad de contratos. Pasar SCV no significa que el contrato sea absolutamente seguro; indica que el código o contrato de este agente ha pasado la comprobación de un proveedor y ha generado señales de riesgo consumibles.
WAV: Verificación de Aplicación Web
WAV verifica el sitio web, API y endpoints del agente.
Muchos agentes, aunque tengan identidad en cadena, la entrada real de interacción sigue estando fuera de la cadena, como el sitio web oficial, API, servidor MCP, endpoint A2A o panel de control.
Una vez que estos lugares tienen problemas, el riesgo puede no ser menor que el de un contrato. Si el certificado del sitio web caduca, el usuario podría sufrir un ataque de intermediario; si la API es secuestrada, el agente podría ejecutar instrucciones erróneas; si se inyecta un script malicioso en el frontend, el usuario podría firmar una transacción peligrosa.
WAV responde a:
¿Son seguros los puntos de entrada web y los endpoints de servicio de este agente?
WV: Verificación de Cartera
WV verifica el riesgo de la cartera del agente.
Observará si esta cartera tiene historial de transacciones, si es una cáscara vacía recién creada, si está asociada con direcciones de alto riesgo, direcciones de phishing, direcciones de atacantes u otros objetos en bases de datos de inteligencia de amenazas.
WV responde a:
¿El registro de comportamiento en cadena de este agente está limpio?
Puntuación de riesgo unificada: haciendo que las carteras y aplicaciones realmente la utilicen
ERC-8126 convertirá los resultados de la verificación en una puntuación de riesgo de 0 a 100.
Cuanto más baja la puntuación, menor el riesgo; cuanto más alta, mayor el riesgo.
- 0-20: Riesgo bajo
- 21-40: Riesgo medio
- 41-60: Riesgo creciente
- 61-80: Riesgo alto
- 81-100: Riesgo grave
El significado de producto de este diseño es muy directo.
Una cartera no puede pedir a los usuarios comunes que lean un informe completo de seguridad cada vez. Un Marketplace tampoco es adecuado para ordenar solo en base a las autodescripciones de los proyectos. Una puntuación de riesgo unificada puede convertirse en la entrada para las estrategias de producto.
Por ejemplo:
- Si la puntuación de riesgo es demasiado alta, la cartera puede advertir o bloquear la interacción.
- Si no hay resultados de verificación, el marketplace puede reducir el peso de visualización.
- Si el riesgo de la cartera es anómalo, el mercado de tareas puede limitar la aceptación de pedidos.
- Si el riesgo del endpoint web es alto, el frontend puede advertir al usuario que acceda con precaución.
Sin embargo, una puntuación total no puede representar toda la situación.
El riesgo de contrato, riesgo de cartera, riesgo de sitio web, riesgo de medios, son en realidad diferentes tipos de riesgo. Un mejor diseño de producto es mostrar simultáneamente la puntuación total y las puntuaciones por categoría, para que el usuario sepa exactamente dónde está el problema.
PDV y ZKP: Demostrar que se pasó la verificación no significa revelar todos los detalles
Verificar un agente implicará mucha información sensible.
Como el código fuente, configuración de infraestructura, informes de seguridad, registros privados, perfil de la cartera, etc. Si todo se hace público, podría ampliar la superficie de ataque.
Por eso ERC-8126 introduce PDV y ZKP.
PDV es Verificación de Datos Privados (Private Data Verification), ZKP es Prueba de Conocimiento Cero (Zero-Knowledge Proof). Su función es: permitir que el agente demuestre que ha pasado una determinada verificación, sin tener que revelar todos los detalles subyacentes.
Puedes entenderlo así:
El mundo exterior ve "pasó la verificación, cuál es la puntuación de riesgo, dónde está la prueba", no todos los materiales de seguridad internos completos.
Esto hace que ERC-8126 se asemeje más a un resumen verificable de due diligence, en lugar de desplegar todos los datos directamente para que toda la red los vea.
ERC-8004 / ERC-8126 / ERC-8183: Identidad, Verificación, Comercio
Si desglosamos la economía de los Agentes de IA en tres capas, se puede entender así. Es necesario aclarar el estado aquí: ERC-8126 ya está en estado Final, mientras que ERC-8004 y ERC-8183 aún están en fase de Borrador (Draft), por lo que los tres son más adecuados para entenderse como una dirección de infraestructura que se está formando, no como una pila de protocolos completamente definida.
- ERC-8004: Identidad – Da identidad al agente, lo hace registrable, descubrible.
- ERC-8126: Verificación – Hace que las señales de seguridad y riesgo del agente sean verificables y consumibles.
- ERC-8183: Comercio – Permite que el agente acepte tareas, presente resultados, entre en procesos de custodia y liquidación.
De forma más directa:
- ERC-8004 responde: ¿Quién eres?
- ERC-8126 responde: ¿Eres confiable?
- ERC-8183 responde: ¿Puedes trabajar, cobrar, liquidar?
Estos tres juntos presentan una narrativa bastante clara de la economía de agentes:
Primero la identidad, luego la verificación, y finalmente es más fácil entrar en transacciones y liquidaciones.
Esta relación también se puede detallar un poco más. ERC-8126 efectivamente se construye sobre ERC-8004; ERC-8183 y ERC-8126 se asemejan más a complementos naturales, que a una relación de dependencia estricta.
En otras palabras, protocolos de comercio de agentes como ERC-8183 pueden consumir naturalmente las señales de verificación de ERC-8126, por ejemplo, comprobar la puntuación de riesgo de un agente antes de que acepte una tarea, verificar la prueba antes de que el evaluator libere los fondos. Pero esto se parece más a una dirección de combinación de ingeniería, no a una dependencia rígida de ERC-8183 en ERC-8126.
¿Qué significa para los desarrolladores?
Si solo se mira a los Agentes de IA desde la narrativa del mercado, la discusión fácilmente se queda en token, lanzamiento, marketplace y calor de las transacciones. Pero para quienes realmente quieren hacer productos de agentes, integración de carteras, redes de tareas o infraestructura de protocolos, la pregunta más crucial es: cuando un agente comienza a gestionar activos, llamar servicios, presentar resultados, colaborar con otros agentes, ¿quién asume el costo de la confianza?
En el pasado, este costo se trasladaba principalmente al usuario. El usuario juzgaba si el proyecto era confiable, revisaba si el contrato estaba auditado, verificaba si la cartera estaba limpia, identificaba si el sitio web oficial era falso, y finalmente asumía las consecuencias de ser estafado o de que la interacción fallara.
El valor de ERC-8126 radica en que intenta dividir estos juicios en señales de verificación estandarizadas, componibles y legibles por productos.
No eliminará el riesgo, ni puede garantizar que un agente sea siempre confiable. Pero si este tipo de señales de verificación son adoptadas por más carteras, marketplaces, dApps y redes de agentes, muchas decisiones de producto podrán dejar de depender únicamente de las autodescripciones de los proyectos.
Concretamente:
Para las carteras, el risk score puede convertirse en la entrada para el control de riesgos previo a la transacción y las advertencias de riesgo.
Para los marketplaces de agentes, los resultados de la verificación pueden afectar al ordenamiento, filtrado, peso de visualización y etiquetas de riesgo.
Para las aplicaciones AI x ETH, puede convertirse en una comprobación de seguridad antes de que un agente se integre.
Para la colaboración entre agentes, puede ayudar a que los agentes filtren objetos claramente de alto riesgo antes de cooperar.
Este es también el lugar donde ERC-8126 merece atención: no es otro ERC conceptual de IA, sino un intento de llevar a los agentes en cadena de "registrables" a "verificables, gestionables en riesgo".
Sigue siendo un estándar, no una red ya en funcionamiento
Esta parte se puede ver desde otra perspectiva.
ERC-8126 define interfaces estándar y un marco de verificación. Explica cómo se puede hacer la verificación, cómo se pueden expresar los resultados, pero no equivale a que ahora exista una red de verificación pública madura, unificada entre cadenas, que funcione transversalmente en carteras y marketplaces.
Según la especificación actual, ya ha dejado claro varias cosas:
- ERC-8126 define el flujo estándar para la verificación de agentes.
- Requiere que la verificación se ancle al agentId de ERC-8004.
- Cubre cinco categorías de riesgo: token/contrato, medios, Solidity, Web, cartera.
- Soporta puntuación de riesgo, proof y attestation.
- Proporciona una base para que carteras, marketplaces, dApps consuman señales de verificación.
Que estas capacidades realmente funcionen, aún depende de cuántos proveedores, carteras, marketplaces y aplicaciones estén dispuestos a adoptarlas posteriormente. En otras palabras, aún no se encuentra en un estado como el siguiente:
- Todas las carteras ya están integradas.
- Todos los marketplaces de agentes ya lo han adoptado.
- Todos los proveedores usan exactamente el mismo estándar de puntuación.
- La industria en su conjunto ya ha formado una red de verificación madura.
- ZKP y la puntuación de riesgo ya están completamente unificados en entornos de producción.
En otras palabras:
ERC-8126 primero estandariza el lenguaje de verificación de los Agentes de IA. Para convertirse en una capa de confianza pública, aún necesita que más proveedores, carteras, mercados y aplicaciones se integren.
Conclusión
Después de que los Agentes de IA entren en la economía en cadena, la identidad es solo el punto de partida, y luego se encontrará un problema más práctico: si puede ser verificado.
ERC-8004 da identidad al agente. ERC-8126 hace que los riesgos detrás de esa identidad puedan ser verificados. ERC-8183, a su vez, da al agente la oportunidad de usar estas señales de verificación en escenarios de tareas, custodia y liquidación.
Por lo tanto, el significado de ERC-8126 no es otorgar al agente una medalla de "confiable permanentemente", sino estandarizar un problema más realista:
Cuando un Agente de IA va a entrar en el flujo de carteras, mercados, redes de tareas y transacciones en cadena, ¿cómo deberíamos verificarlo? ¿Cómo deben expresarse los resultados de la verificación? ¿Y cómo deben consumir esos resultados otros sistemas?
Esta es quizás la capa de confianza que la economía de los Agentes de IA necesita complementar a continuación.
Referencias
- ERC-8126: AI Agent Verification
- ERC-8126 Raw Markdown
- ERC-8004: Trustless Agents
- ERC-8183: Agentic Commerce
- Ethereum Magicians: ERC-8126 Discussion
- DonJohnson X Thread: Introducing ERC-8126
- Cybercentry Web3 Security & Verification Services
- ERC-8126 Scan
