Con el estándar ERC-8004 (Agentes Sin Confianza) desplegado oficialmente en la red principal de Ethereum, la gestión de identidad y reputación de los Agentes de IA ha entrado en una nueva etapa verificable y sin confianza. Este estándar proporciona a los agentes un "sistema de identidad" verificable en cadena a través de tres registros centrales: el Registro de Identidad, el Registro de Reputación y el Registro de Verificación. Este artículo, desde una perspectiva de auditoría de seguridad y combinando los detalles técnicos de ERC-8004, analizará los puntos clave de riesgo de cada registro, ofreciendo una guía de auditoría práctica para desarrolladores y auditores.
Detalles Técnicos y Puntos Clave de Auditoría
La clave de ERC-8004 radica en sus tres registros (Registry):
1. Registro de Identidad (Identity Registry)
Un identificador mínimo en cadena (handle) basado en ERC-721, con extensión URIStorage, que se resuelve en el archivo de registro del agente, proporcionando un identificador portable y resistente a la censura para cada agente.
En la arquitectura de ERC-8004, el Registro de Identidad se construye sobre ERC-721 y extiende la funcionalidad URIStorage. En otras palabras, cada agente corresponde a un NFT único en cadena, a este NFT se le llama AgentID.
Cuando un desarrollador crea un agente, llama a la función `register` del contrato del registro, acuñando un nuevo AgentID. Este token está vinculado a un `tokenURI`, que apunta a un archivo JSON almacenado fuera de cadena: el llamado "archivo de registro del agente". El archivo de registro debe seguir una estricta especificación, que generalmente incluye tres tipos de contenido central:
- Información básica, como nombre, descripción, URL del avatar;
- Puntos finales de servicio (service endpoints), es decir, las direcciones de red a las que se puede acceder al agente, compatible con varios protocolos como HTTP, WebSocket, Libp2p, A2A, MCP;
- Declaraciones de capacidad (capability claims), es decir, la lista de tareas que el agente puede ejecutar, como generación de imágenes, arbitraje de transacciones o auditoría de código.
Las autodeclaraciones por sí solas son insuficientes para generar confianza, por lo que ERC-8004 introduce un mecanismo de verificación de dominio. El agente debe alojar un archivo de firma en el dominio que declara, en la ruta `/.well-known/agent-card.json`. El registro en cadena verifica este enlace, vinculando así el AgentID en cadena con el correspondiente dominio DNS. El propósito de este paso es prevenir ataques de phishing y suplantación de identidad; un agente no puede simplemente afirmar pertenecer a un dominio, debe probar el control del mismo con una firma criptográfica.
Puntos Clave de Auditoría:
● Verificar el control de acceso de la función `setTokenURI`, asegurando que solo permita actualizar la URI al propietario del agente o a roles autorizados (como `onlyOwnerAfterMint`).
● Revisar si la URI admite esquemas de almacenamiento inmutables (como IPFS, Arweave). Si se utiliza un enlace HTTP centralizado, es necesario evaluar la seguridad del control del dominio para prevenir el secuestro de DNS (DNS hijacking).
● Verificar la validez del formato de la URI, evitando excepciones en el contrato debido a punteros nulos o URI inválidos.
● Verificar que el contrato aplique estrictamente la verificación de firmas criptográficas (como EIP-712) al validar la firma del dominio, para prevenir la falsificación de firmas o ataques de repetición (replay attacks).
● Comprobar el mecanismo de caducidad (expiration) de la prueba de propiedad del dominio, para evitar que firmas válidas por largo tiempo sean reutilizadas.
● Asegurar que el proceso de resolución de dominios no dependa de oráculos centralizados, evitando puntos únicos de fallo o manipulación.
2. Registro de Reputación (Reputation Registry)
Una interfaz estándar para publicar y obtener señales de retroalimentación. La puntuación y agregación ocurren tanto en cadena (composabilidad) como fuera de cadena (algoritmos complejos), permitiendo la realización de un ecosistema de servicios profesionales como puntuación de agentes, redes de auditoría y pólizas de seguro (insurance pools).
Se utiliza para evaluar y dar retroalimentación sobre los Agentes de IA ya registrados. La retroalimentación simple se envía en cadena, permitiendo expansión fuera de cadena para procesos complejos, que luego son agregados y subidos a cadena.
ERC-8004 también puede prevenir la manipulación de puntuaciones maliciosas mediante un mecanismo de "Vinculación de Prueba de Pago" (Payment-Proof Linking). Cuando el Agente A completa una evaluación del Agente B, llama a la función `giveFeedback`. Esta función no solo acepta una puntuación (0-100) y un hash del comentario, sino que también permite incluir un campo `paymentProof`, normalmente el hash de una transacción x402. Esto hace que el coste de inflar las evaluaciones sea extremadamente alto, reduciendo enormemente la posibilidad de ataques Sybil. Finalmente, el sistema recompensará naturalmente a los agentes con un rendimiento estable y de alta calidad.
Puntos Clave de Auditoría:
● Verificar si la función `giveFeedback` exige obligatoriamente el parámetro `paymentProof`, y comprobar si este parámetro es un hash de transacción x402 válido (o cumple con otro estándar de pago). Se debe asegurar que la prueba de pago no sea reutilizable (por ejemplo, registrando los hashes ya usados), para evitar múltiples evaluaciones con un solo pago.
● Comprobar si el rango de puntuación (0-100) está forzado a nivel de contrato, evitando que puntuaciones fuera de los límites dañen la lógica de agregación.
● Evaluar la resistencia a la manipulación del algoritmo de agregación fuera de cadena: por ejemplo, si utiliza la mediana, recorta valores extremos o hace un promedio ponderado, y si penaliza comportamientos anómalos (como un gran volumen de evaluaciones en un tiempo muy corto).
● Revisar si las condiciones de confiscación (slashing conditions) son claras y verificables, por ejemplo, si dependen de evidencias en cadena o de la presentación de pruebas de fraude (fraud proofs) por parte de oráculos de terceros.
● Asegurar que la lógica de confiscación no incluya privilegios centralizados (como que un administrador pueda confiscar fondos apostados arbitrariamente); las condiciones para activar la confiscación deben ser ejecutadas automáticamente únicamente por el contrato inteligente.
● Probar el período de bloqueo (lock-up period) y las condiciones para retirar los fondos apostados, para evitar que un agente retire urgentemente los fondos justo antes de enfrentar una confiscación.
3. Registro de Verificación (Validation Registry)
Un gancho (hook) genérico para solicitar y registrar comprobaciones de verificadores independientes (por ejemplo, verificadores zkML, oráculos TEE, evaluadores confiables).
La reputación refleja el pasado, pero en escenarios de alto riesgo (como la gestión de grandes cantidades de fondos), el historial por sí solo no es suficiente. El Registro de Verificación permite a los agentes enviar los resultados para su verificación por parte de sistemas automatizados o de terceros, utilizando, por ejemplo, re-ejecución de razonamiento seguro con staking, verificadores zkML u oráculos TEE para verificar o rechazar solicitudes.
El primer modelo es la verificación criptoeconómica, basada en un diseño de seguridad de teoría de juegos. El agente debe apostar (stake) una cierta cantidad de criptomoneda nativa o stablecoin en el registro. Si el agente incumple o proporciona un resultado erróneo, la red de verificadores puede presentar una prueba de fraude, activando la confiscación automática de sus fondos apostados por el contrato inteligente. Este modelo es adecuado para tareas donde el resultado es fácil de verificar pero el proceso de cálculo no es transparente, como la extracción de datos o servicios simples de API.
El segundo modelo es la verificación criptográfica, basada en principios matemáticos de seguridad. La attestation TEE (Trusted Execution Environment) permite que el agente se ejecute en un entorno de hardware reforzado, como Intel SGX o AWS Nitro. El Registro de Verificación puede almacenar y verificar informes de attestation remota del hardware, demostrando que el agente ejecuta efectivamente una versión específica de código no alterado.
zkML (Zero-Knowledge Machine Learning) es otra forma de verificación criptográfica. El agente, al enviar un resultado de inferencia, envía simultáneamente una prueba de conocimiento cero (zero-knowledge proof). Esta prueba puede ser verificada por un coste muy bajo por un contrato de verificación en cadena, garantizando matemáticamente que dicha salida fue indeed generada por un modelo específico (por ejemplo, Llama-3-70B) con una entrada específica. Esto previene el ataque de "sustitución de modelo" (model swapping attack), donde un proveedor de servicios afirma usar un modelo de alta gama pero en realidad usa uno inferior para ahorrar costes.
Puntos Clave de Auditoría
Para verificación criptoeconómica, verificar:
● Comprobar el período de ventana (window period) para presentar pruebas de fraude: ¿Se da a los verificadores suficiente tiempo para detectar y presentar pruebas? Un período demasiado corto puede dejar pasar comportamientos maliciosos, mientras que uno demasiado largo mantiene los fondos bloqueados durante mucho tiempo.
● Verificar la lógica de arbitraje de las pruebas de fraude: ¿Depende de un conjunto de verificadores multisignatura? Si es así, revisar el grado de descentralización en la selección de verificadores y la configuración del umbral (threshold); si el arbitraje es completamente en cadena, asegurar que existe una base para la decisión (por ejemplo, un resultado verificable en cadena) y que no es ambigua.
● Asegurar que la cantidad de fondos apostados (stake) sea proporcional al riesgo, para prevenir comportamientos maliciosos de bajo coste (por ejemplo, apostar muy poco, donde el beneficio de actuar mal supera con creces la pérdida).
Para attestation TEE, verificar:
● Comprobar si el contrato verifica la vigencia (timeliness) de la prueba TEE (por ejemplo, incluyendo una marca de tiempo o altura de bloque), para evitar que se acepten pruebas caducadas.
● Verificar si el contenido de la prueba incluye el hash del código del agente, resúmenes de entrada/salida, asegurando que la prueba esté vinculada a la tarea específica y evitando su reutilización entre diferentes tareas.
● Evaluar si la lógica de verificación de la prueba TEE depende de oráculos externos (como Intel IAS). Si depende, auditar la seguridad y el grado de descentralización del oráculo.
Para verificación zkML, verificar:
● Confirmar que el contrato integra una biblioteca de verificación zk auditada (como SnarkVerifier), y que la clave de verificación está configurada correctamente para el sistema de pruebas específico (como Groth16, PLONK).
● Comprobar si el contrato de verificación restringe los modelos y el rango de entradas aplicables a la prueba, para prevenir ataques de sustitución de modelo (por ejemplo, que la prueba se genere para un modelo pequeño pero se afirme que es la salida de un modelo grande).
● Evaluar el grado de descentralización de la generación de pruebas: ¿Depende de un único probador (prover)? Si existen múltiples probadores, es necesario diseñar un mecanismo de consenso para prevenir probadores maliciosos.
Conclusión
ERC-8004 proporciona un estándar para establecer confianza en los Agentes de IA, y su seguridad es clave para todo el ecosistema de agentes en cadena. El trabajo de auditoría de seguridad debe comprender en profundidad la intención de diseño y los riesgos potenciales de los tres registros. Además, la complejidad de las interacciones entre contratos y las vulnerabilidades convencionales no deben pasarse por alto. Es necesario asegurar, a través de auditorías exhaustivas y rigurosas, que ERC-8004 cumpla verdaderamente su promesa de "sin confianza" (trustless), sentando una base segura para el futuro de los agentes autónomos.
