Claves de sesión y permisos: delegación en agentes onchain

Las claves de sesión y los permisos de agente son una forma en que una cuenta inteligente puede delegar un mandato estrictamente definido a una aplicación o agente de IA, aplicado en la cadena por la lógica de validación de la billetera.

El objetivo es la ejecución autónoma en la cadena sin convertir a un agente en un firmante de pleno poder, utilizando límites como ventanas de tiempo, listas de permitidos y un límite de gasto que el contrato puede negarse a superar.

Puntos Clave

• Una clave de sesión es una credencial de firma temporal con autoridad limitada, diseñada para que una aprobación pueda cubrir un conjunto limitado de acciones dentro de un alcance definido.
• La mejora de seguridad proviene de cuentas inteligentes que aplican políticas en la cadena, no de que la clave sea "temporal".
• ERC-4337 hace que la ejecución delegada sea operativa a través de UserOperations, agrupadores y un contrato EntryPoint canónico, con pagadores opcionales que pueden patrocinar.gas.
• ERC-8196 propone el siguiente paso para el diseño de billeteras de agentes: prueba criptográfica de cumplimiento de políticas más un hash encadenado.auditoríarastro de la actividad de la sesión.

Conceptos básicos sobre claves de sesión y permisos de agentes

La delegación comienza con una simple división: una credencial mantiene el control total, mientras que otra credencial recibe una tarea específica. En una configuración de cuenta inteligente, la clave maestra del propietario permanece como "raíz", mientras que se acuña o autoriza una clave de sesión para una ventana y un alcance específicos. Ese alcance es lo que la gente entiende por permisos de agente o acceso de agente con alcance. La aplicación o el agente pueden firmar, pero solo dentro del marco que el contrato de la billetera reconoce.

Este marco es importante para la ejecución autónoma en la cadena porque los agentes ya saben cómo firmar transacciones. El modo de fallo consiste en darles una clave de acceso total y esperar que el anfitrión, el aviso, el árbol de dependencias y la interfaz de usuario nunca te traicionen. Las claves de sesión son la postura opuesta.

Son un presupuesto de riesgo que puedes valorar: tiempo + objetivos + límites de valor, con el contrato de la billetera actuando como el portero.

Un modelo mental útil es "insignia, no llave maestra". La insignia puede abrir algunas puertas, durante unas pocas horas, para una tarea específica. Si la insignia se filtra, el radio de explosión se supone que está limitado por diseño. Por eso, la frase claves de sesión en cripto a menudo aparece junto a cuentas inteligentes y billeteras integradas. El objetivo es tener menos aprobaciones repetidas sin entregar control permanente y ilimitado a una aplicación.

Hay dos detalles que son fáciles de pasar por alto. Primero, "temporal" no es la propiedad de seguridad. El alcance lo es. Segundo, las claves de sesión no están estandarizadas en todas partes hoy en día. Las implementaciones siguen siendo de billetera a billetera, lo que significa que la semántica exacta de revocación, listas de permitidos y casos extremos varía entre proveedores.

Cómo las cuentas inteligentes aplican permisos

ERC-4337 cambia dónde ocurre la autorización. En lugar de que un EOA transmita una transacción normal al mempool público, una cuenta inteligente espera una UserOperation que puede validar según sus propias reglas antes de que se ejecute cualquier cosa. El agente firma la UserOperation con una clave autorizada, un bundler agrega UserOperations, y el bundler llama a un contrato EntryPoint canónico que las procesa. El sistema de permisos reside en la capa de validación de la cuenta inteligente, no en la interfaz de usuario.

Esa arquitectura es la razón por la cual “confía en la aplicación” puede ser reemplazada por “el contrato se niega.” RebelFi captura el cambio con dos líneas que valen la pena mantener textualmente: “confía en el código de la aplicación del agente para no gastar de más” frente a “el contrato hace cumplir la política de gasto independientemente de lo que haga la aplicación.” La segunda oración es el mecanismo real. Si la política dice que no, la operación no se valida, y EntryPoint no la ejecuta.

Los paymasters son la otra pieza que hace que los agentes se sientan siempre activos. En ERC-4337, un paymaster puede patrocinar el gas, lo que significa que un agente que posee USDC y noETHtodavía se puede realizar transacciones si se configura un paymaster para aceptar USDC a cambio de cubrir los costos de gas de ETH. Eso no es un truco cosmético de UX.

Elimina el requisito operativo de mantener un saldo separado de ETH recargado solo para que el agente pueda seguir funcionando.

Aquí es donde eip 7702entra en la conversación. ZeroDev posiciona su stack como compatible tanto con ERC-4337 como con eip 7702, con claves de sesión como un primitivo de UX de primera clase para la automatización. El hilo común es el mismo: mover la delegación a una billetera que pueda hacer cumplir la política, en lugar de dejarla como una promesa fuera de la cadena.

Ámbitos y límites de permisos comunes

Una política de sesión es tan buena como los controles que expone y hace cumplir. El ejemplo concreto de RebelFi es una plantilla limpia de cómo deberían verse los permisos del agente cuando alguien realmente tiene capital en juego: un gasto máximo por transacción (ejemplo: $50), una lista de destinatarios aprobados, una ventana de expiración (ejemplo: 24 horas) y un presupuesto total de sesión (ejemplo: $500) antes de la re-autorización.

Ese último es importante porque “muchos pequeños golpes” pueden acumularse incluso cuando cada transferencia individual está limitada.

Esos controles se relacionan con cómo las cuentas inteligentes validan la intención:

1. Límites de tiempo. Una ventana validAfter y validUntil hace que la clave sea inútil fuera de la sesión, lo que reduce el valor de robarla. 2. Restricciones de destino. Las listas de permitidos de destinatarios o contratos autorizados evitan que la clave se reutilice para transferencias arbitrarias. 3. Restricciones de valor.

Un límite de gasto por transacción limita el daño de un solo golpe, mientras que un presupuesto total limita el daño por goteo.

La revocación es la red de seguridad operativa. En la arquitectura de RebelFi, la clave raíz de firma mantiene el control total de la cuenta y puede revocar las claves de sesión en cualquier momento. Esa es la diferencia entre delegación y rendición. La clave del propietario no está “compartiendo identidad.” Está emitiendo un mandato que puede ser anulado.

Una matiz más: las claves de sesión a menudo se describen como “temporales claves privadas,” pero esa descripción está incompleta. La clave es solo un firmante. La seguridad proviene de que la cuenta inteligente se niega a validar operaciones que violan la política. Sin esa aplicación en cadena, “temporal” aún puede ser catastrófico dentro de la ventana.

Flujos de trabajo de agentes habilitados por delegación

La delegación no solo se trata de conveniencia. Cambia qué flujos de trabajo son factibles sin convertir cada paso en una nueva ceremonia de firma. El caso de uso obvio son los pagos a agentes. Se puede permitir que una billetera de agente pague a un conjunto de proveedores de servicios preevaluados mientras se bloquea la transferencia de fondos a direcciones arbitrarias.

El agrupamiento atómico es el desbloqueo de segundo orden. Las cuentas inteligentes ERC-4337 pueden ejecutar transacciones de lote atómicas, por lo que secuencias como retirar-de-rendimiento + pagar-por-servicio tienen éxito o fracasan juntas. Eso importa porque previene un estado medio incompleto. Si la parte de pago falla, la parte de retiro se revierte, y los fondos no terminan varados en un estado intermedio no deseado.

El agrupamiento también se presenta como una palanca de costo medible. RebelFi estima que dostransferencias ERC-20por separado son aproximadamente 2 × 65,000 gas frente a alrededor de 1 × 110,000 gas agrupados, lo que representa un ahorro de alrededor del 15%. En una pantalla, esa es la diferencia entre un flujo de trabajo de agente que es económicamente viable a gran escala y uno que genera costos.

El patrocinio de gas une el ciclo para los agentes "sin ETH". Con un pagador, el agente puede operar mientras sostiene solo USDC, asumiendo que el pagador acepta USDC para el gas. Esa es la respuesta práctica a la idea errónea de que los agentes deben tener ETH para funcionar.

El posicionamiento de ZeroDev es consistente con esta visión del flujo de trabajo. Su documentación enmarca las claves de sesión como parte de un conjunto de herramientas de experiencia de usuario de cuentas inteligentes más amplio que incluye agrupamiento y abstracción de gas, y afirma alimentar más de 6 millones de cuentas inteligentes en más de 50 redes para más de 200 equipos.

Esa afirmación de escala no es una garantía de seguridad, pero es una señal de que estos patrones ya se están utilizando en pilas de producción.

Ejecución vinculada a políticas y trazas de auditoría

ERC-8196 es la declaración más clara de hacia dónde se dirigen los permisos de los agentes: billeteras que ejecutan acciones solo cuando están acompañadas de una prueba criptográfica de que la acción cumple con una política definida por el propietario. Esto no es solo "establecer límites en una interfaz de usuario". Es "probar el cumplimiento en el momento de la ejecución", con la billetera actuando como el punto de aplicación.

La propuesta especifica los campos de política requeridos que parecen una versión formalizada de las políticas de sesión actuales: acciones permitidas, contratos permitidos y bloqueados, valor máximo por transacción, una ventana de validez y una puerta de puntuación de verificación mínima.

También introduce un concepto de trazabilidad de auditoría inmutable y encadenada por hash para la actividad de sesión, donde cada entrada de auditoría incluye un hash anterior para la integridad. ERC-8196 permite a las implementaciones almacenar entradas fuera de la cadena y publicar periódicamente raíces en la cadena, lo que es un intercambio pragmático entre costo y verificabilidad.

Este es el juego final implícito por la tesis: las claves de sesión solo se vuelven significativamente seguras cuando la billetera puede hacer cumplir la política en la cadena, y la próxima muralla es el cumplimiento verificable más la auditabilidad. Si un host de agente está comprometido, "los registros dicen que se comportó" no es suficiente.

Un rastro evidente de manipulación más la ejecución vinculada a políticas está más cerca de la postura que las plataformas reguladas y los operadores serios desean.

Dos advertencias pertenecen a la misma frase. ERC-8196 está explícitamente en revisión por pares, por lo que la interfaz y los requisitos pueden cambiar. Por separado, incluso un estándar perfecto no elimina el riesgo de implementación. La lógica de validación de la billetera, las verificaciones de verificación y la plomería de auditoría aún deben construirse correctamente.

Riesgos, advertencias y mejores prácticas

La costosa idea errónea es pensar que una clave de sesión es segura porque es temporal. Los límites de tiempo ayudan, pero un alcance completamente abierto dentro de la ventana sigue siendo un alcance completamente abierto. Una clave de 24 horas que puede transferirse a cualquierdirección es un botón de drenaje de 24 horas.

La segunda idea errónea es la portabilidad. Las claves de sesión no están estandarizadas en todas partes hoy en día, y las implementaciones varían de billetera a billetera. Eso significa que los “permisos de agente” pueden parecer similares entre productos mientras se comportan de manera diferente en los bordes, incluyendo el comportamiento de revocación y cuán estrictamente se aplican las listas de permitidos.

La tercera idea errónea es operativa: los agentes necesitan ETH para operar. Los pagadores ERC-4337 pueden patrocinar gas, permitiendo que un agente que tiene USDC y no ETH realice transacciones si el pagador está configurado para aceptar USDC.

La mejor práctica es redactar políticas como límites de riesgo, no como interruptores de funciones:

1. Comienza con un pequeño límite de gasto por transacción. Esta es la forma más rápida de limitar el daño de un solo golpe. 2. Usa una lista de permitidos rígida de destinatarios o contratos. Si el agente no puede nombrar el objetivo en la política, no debería poder tocarlo. 3. Mantén la ventana de validez corta. La expiración reduce el valor de una clave filtrada. 4. Agrega un presupuesto total de sesión. Esto detiene “muchos pequeños golpes” de desangrar la cuenta.

El agrupamiento también es una herramienta de seguridad, no solo un truco de gas. Los lotes atómicos reducen la posibilidad de terminar con un estado medio completado cuando un flujo de trabajo de agente abarca múltiples pasos.

La revocación debe ser tratada como un control de primera clase. Las fuentes son explícitas en que la clave raíz del propietario puede revocar las claves de sesión. Operativamente, eso implica diseñar para interruptores de apagado rápidos y tratar los nonces y la expiración como controles centrales para reducir problemas de repetición y temporización.

Aquí es donde aterriza la historia más amplia de la ejecución autónoma: los diseños ganadores mueven la delegación fuera de las promesas de la aplicación y hacia límites impuestos por contrato, luego añaden cumplimiento verificable y una pista de auditoría encima.

La conclusión

He visto a equipos tratar “clave temporal” como un argumento de seguridad y luego enviar silenciosamente una sesión que estaba completamente abierta en objetivos o presupuesto. La clave expiró, claro. Los fondos aún estaban desaparecidos dentro de la ventana.

La única versión de esto que se sostiene es cuando la capa de validación de la cuenta inteligente es la que dice que no, no un host de agente o una casilla de verificación en la interfaz de usuario.

La postura limpia es pensar en una clave de sesión como un mandato con precio: reloj corto, lista de permitidos estricta, pequeño límite de gasto por transacción y un presupuesto total rígido. Si el sistema también admite agrupamiento atómico y pagadores, el agente puede sentirse siempre activo sin ser siempre peligroso.

Esa es la dirección en la que está convergiendo la ejecución autónoma en cadena, y ERC-8196 es el primer intento serio de hacer que el cumplimiento y la auditabilidad sean parte del trabajo de la billetera, no un pensamiento posterior.

Fuentes

• RebelFi
• Propuestas de Mejora de Ethereum
• CryptoAdventure
• Documentos de ZeroDev