Cuando un agente de IA necesita operar en blockchain, el primer instinto del desarrollador es sencillo: generar una clave, meterle fondos y enviarla a vivir. Ese instinto es el origen de la mayoría de incidentes de agentes onchain. Este artículo revisa el modelo de credenciales que usan las agentic wallets serias: qué piezas existen, cómo encajan y qué comprueba un security auditor antes de dar luz verde.
El modelo de credenciales: identidad, control y sesión
Una agentic wallet separa tres conceptos que la wallet clásica fusiona. La identidad: la dirección / ownership que define quién es el propietario real. El control: quién puede cambiar políticas, rotar claves o eliminar la cuenta. Y la sesión: la credencial delegada que usa el agente para firmar dentro de límites. El propietario nunca entrega la identidad; solo emite sesiones.
Por qué EOA + clave en el servidor es un anti-patrón
La forma ingenua —una Externally Owned Account con la clave almacenada junto al agente— concentra todo el riesgo en un solo factor: quien roba la clave roba la cuenta entera, sin límites, sin rotación, sin revocación diferenciada. Además mezcla identidad y ejecución: no hay forma de distinguir la firma del agente de la firma del propietario. Es aceptable para prototipos de fin de semana, no para capital real.
Claves de sesión con límites
El patrón solvente: la smart account define permisos por sesión (importe máximo por transacción, importe máximo por período, direcciones y tokens permitidos, y tipos de llamada). El agente firma con su sesión; la cuenta valida en la ejecución y devuelve error si se excede. Algunas implementaciones añaden 'gas tank': el agente paga el gas de un monedero delegado y la cuenta controla el gasto total.
Recuperación y rotación de claves
La rotación debe ser un procedimiento de diseño, no una feature añadida después: si se sospecha compromiso, revocar la sesión activa y emitir una nueva debe ser inmediato y no requerir mover fondos. La recuperación del ownership (la identidad) normalmente usa multisig o guardians: el propietario puede recuperar el control aunque pierda su clave, y el agente nunca tiene poder sobre el ownership.
La superficie de ataque del modelo
El eslabón más débil no suele ser la criptografía sino el contexto del modelo: prompt injection, datos de mercado envenenados o instrucciones ocultas en inputs externos pueden hacer que el agente firme lo que no debe. Las defensas son: permisos mínimos (que un error del modelo no supere el límite de la sesión), validación de destino (lista blanca de direcciones), y un módulo de política previa a la firma que no depende del LLM: reglas deterministas de alto riesgo siempre ganan.
Checklist de auditoría para una agentic wallet
1) ¿El ownership está en multisig o en una sola clave? 2) ¿Cada sesión tiene límites de importe y alcance? 3) ¿Hay revocación y rotación sin mover fondos? 4) ¿Existe validación determinista previa a la firma independiente del LLM? 5) ¿El gas y los tokens de gasto están acotados? 6) ¿Las transacciones de riesgo alto requieren aprobación humana o tienen máximo por período? 7) ¿El código del agente y los permisos están auditados por alguien distinto de quien lo escribió? Si fallas cuatro preguntas de siete, no des fondos reales al agente.
Conclusión
Las credenciales de agentes onchain ya están convergiendo en un estándar de facto: smart account + sesiones delegadas + límites + rotación. Para un desarrollador, la curva de aprendizaje es la de ERC-4337 y los SDK de cuentas (Safe, Coinbase, Arc); para un investigador de seguridad, el campo de estudio es fascinante porque combina bugs de smart contract clásicos con toda la clase nueva de vulnerabilidades de contexto de IA.
Preguntas frecuentes (FAQ)
¿Un agente puede tener su propia direción y reputación? Sí, puede tener identidad propia si el propietario le asigna una dirección dedicada, separada del ownership humano. ¿Se puede revocar una sesión comprometida? Sí, de forma inmediata y sin mover fondos. ¿Hace falta multisig para el ownership? No obligatoriamente, pero para capital relevante es el patrón recomendado. ¿Los LLM deben firmar las transacciones? Idealmente no: el LLM emite una intención y la política determinista de la cuenta decide si la firma procede.