Conclusiones clave
-
La delegación de agentes de IA es el proceso de conceder a un agente de software autónomo una autoridad limitada para actuar en nombre de una persona, organización, aplicación o cuenta de blockchain.
-
La delegación es diferente a entregar a un agente una contraseña, clave privada o cuenta de administrador sin restricciones. Una delegación bien diseñada otorga solo la autoridad mínima necesaria para una tarea específica.
-
Los permisos definen las acciones que un agente puede realizar, como leer archivos, enviar pagos, intercambiar tokens o crear eventos en el calendario.
-
Los alcances (scopes) determinan los límites de esos permisos, incluyendo qué cuentas, aplicaciones, activos, destinatarios, redes y datos puede acceder el agente.
-
Los límites de gasto restringen el valor financiero que un agente puede mover a través de topes por transacción, diarios, por sesión, específicos de token o acumulativos.
-
La autoridad delegada puede implementarse offchain usando tokens de acceso OAuth y motores de políticas de API, o onchain mediante cuentas inteligentes, claves de sesión, módulos de asignación (allowance) y contratos de permisos.
Los agentes de IA van más allá de la generación de texto. Pueden buscar en bases de datos, gestionar calendarios, llamar APIs, ejecutar operaciones, pagar servicios, interactuar con contratos inteligentes y coordinarse con otros agentes. Conforme los agentes se vuelven más capaces, la pregunta central ya no es solo qué pueden comprender, sino qué deberían estar autorizados a hacer.
Otorgar acceso ilimitado a un agente es peligroso. Un agente de viajes puede necesitar permiso para buscar vuelos y reservar hoteles, pero no debería acceder por defecto a todas las cuentas bancarias. Un agente de trading puede requerir reequilibrar un portafolio, pero no debería poder transferir toda la tesorería a una wallet desconocida. Un asistente empresarial puede requerir leer facturas, pero no debería poder aprobar sus propios pagos sin supervisión.
La delegación de agentes de IA resuelve este problema separando la autoridad en permisos limitados y aplicables. Es parecido a cómo una empresa asigna responsabilidades a un empleado, que recibe acceso a ciertos sistemas, presupuestos y tareas sin tener control total sobre la organización. La delegación digital aplica este mismo principio a los agentes de software.
¿Por qué los agentes de IA necesitan autoridad delegada?
Un chatbot básico puede esperar que el usuario apruebe cada paso. Un agente autónomo útil suele tener que actuar sin la presencia activa del usuario. Imagina un agente encargado de gestionar las suscripciones de software de una empresa: debe monitorizar facturas, verificar que los cargos coincidan con contratos activos, pagar a proveedores aprobados, identificar suscripciones duplicadas y alertar al equipo financiero ante pagos inusuales.
Requerir que un humano inicie sesión y apruebe cada pago de $20 eliminaría gran parte del beneficio de la automatización. Dar al agente acceso sin restricciones a la cuenta bancaria corporativa implicaría un riesgo inaceptable. La delegación ofrece un camino intermedio.
La empresa puede autorizar al agente para pagar solo a proveedores de software aprobados, usando una cuenta designada, con un límite de $100 por transacción y $1,000 mensuales. Todo lo que salga de esos límites requeriría aprobación humana. Esto refleja el principio de seguridad de mínimo privilegio: cada usuario o proceso debe recibir solo los recursos y autorizaciones necesarios para cumplir con su función asignada. Por tanto, la delegación de IA no es principalmente para hacer más poderosos a los agentes, sino para que su autonomía sea lo suficientemente segura para ser usada.
Los principales participantes en una delegación de agentes de IA
El Mandante (Principal)
El Agente
El recurso o la cuenta
La capa de autorización
El ejecutor
Autenticación vs. Autorización
Autenticación y autorización están relacionadas, pero son diferentes. Autenticación pregunta: "¿Quién está haciendo esta solicitud?" Autorización pregunta: "¿Qué tiene permitido hacer esa parte autenticada?"
Un agente puede probar exitosamente su identidad usando credenciales de API, firma criptográfica, passkey o dirección de wallet. Pero eso no significa que deba acceder a todas las funciones. Un sistema seguro primero autentica al agente y luego compara la acción solicitada con sus permisos delegados.
Por ejemplo, un agente puede probar que controla una clave de sesión reconocida. La wallet entonces verifica si esa clave está autorizada para transferir USDC, si el destinatario está aprobado, si se excede el límite diario y si el permiso está vigente. Solo tras superar estas comprobaciones debería ejecutarse la acción.
Delegación de agentes de IA offchain
Actualmente, la mayoría de los agentes de IA interactúan con servicios web convencionales en lugar de cuentas blockchain. La delegación offchain suele usar tokens de acceso OAuth, API keys con roles restringidos, control de acceso basado en roles (RBAC), sistemas de identidad en la nube, servicios de gestión de secretos y gateways de cumplimiento de políticas.
Un agente conectado a un correo o calendario puede recibir un token OAuth para leer datos seleccionados sin exponer la contraseña del usuario. Un agente empresarial puede operar a través de una cuenta de servicio capaz de consultar una base de datos, pero sin acceso a herramientas de administración en producción. La autorización MCP sigue este modelo tratando servers MCP protegidos como resource servers OAuth y clientes como aplicaciones que hacen solicitudes en nombre de los propietarios de recursos.
Delegación de agentes de IA onchain
Los agentes blockchain requieren un enfoque distinto: una transacción desde una wallet puede mover activos de forma irreversible. El enfoque inseguro sería darle al agente la clave privada principal de la wallet.
Quien controle esa clave puede realizar cualquier acción desde esa wallet. Un límite de gasto definido solo en el prompt del agente no es un control real de seguridad, ya que el agente o un atacante pueden ignorarlo. La delegación onchain, en cambio, pone las restricciones dentro de la lógica del contrato inteligente o la wallet.
Módulos de allowance y permisos de gasto
Algunos sistemas de wallet ya ofrecen controles de gasto orientados a agentes. La documentación de Safe describe una configuración de tesorería AI donde un módulo de allowance confiere al agente un límite específico por token, de una sola vez o renovable periódicamente (por ejemplo, un allowance diario de USDC). Safe también contempla aprobación humana, autorización multiagente y límites de gasto como modelos de seguridad distintos para agentes de IA.
Coinbase Spend Permissions permite a un usuario designado (spender) utilizar tokens de una smart account dentro de restricciones según el token, monto y periodo de tiempo. Su documentación identifica pagos agentivos y trading algorítmico como posibles casos de uso.
Estos sistemas demuestran un principio de diseño importante: la autoridad de gasto del agente debe ser aplicada en la wallet o contrato, no solo en el software que opera el agente.
Delegación vs. otorgar una clave privada al agente
Dar una clave privada a un agente transfiere el control total. Delegar transfiere solo la autoridad definida.
| Clave privada sin restricción | Delegación con alcances |
| Suele acceder a toda la cuenta | Limitada a acciones específicas |
| Puede transferir cualquier activo | Solo puede transferir activos aprobados |
| No tiene límites de gasto nativos | Pueden imponerse topes de gasto |
| Sigue activa hasta el cambio de clave | Puede expirar automáticamente |
| Difícil de revocar de forma selectiva | Puede revocarse solo una delegación |
| El compromiso puede drenar la cuenta | Las pérdidas pueden ser limitadas |
| El agente puede cambiar la configuración de la cuenta | Las acciones administrativas pueden prohibirse |
Una wallet separada con bajo saldo es más segura que entregar la clave del tesoro principal, pero una smart account bien configurada ofrece controles más robustos al poder imponer permisos incluso con fondos mayores.
Delegación vs. aprobaciones de tokens
Una aprobación ERC-20 permite a un spender transferir tokens hasta cierto allowance. Es una forma básica de delegación, pero suele ser demasiado limitada para agentes sofisticados. Una aprobación de token puede no restringir al destinatario final, protocolo utilizado, slippage, dirección de la operación, horario, exposición agregada ni el motivo de la transacción.
Aprobaciones ilimitadas de token son especialmente peligrosas, ya que un spender comprometido puede transferir todo el saldo aprobado. Los sistemas de delegación para agentes pueden envolver allowances dentro de reglas más amplias, combinando límites de valor con funciones, contratos, destinatarios, periodos de tiempo y aprobaciones humanas.
Casos de uso comunes para delegación de agentes de IA
Pagos agentivos – Un agente puede pagar llamadas a API, datos, cómputo, almacenamiento o servicios digitales. La delegación puede especificar un bajo límite por llamada y un total mayor por sesión para que el agente adquiera recursos sin pedir repetidamente autorización al usuario.
Trading automatizado – Un agente de trading puede colocar órdenes, reequilibrar activos o ejecutar estrategias bajo restricciones sobre mercados soportados, tokens aprobados, tamaño de posición máximo, apalancamiento, slippage y pérdidas diarias.
Gestión de tesorería – Un agente de tesorería AI puede monitorear saldos, transferir capital de trabajo, pagar proveedores o asignar stablecoins inactivas. El diseño más seguro emplea un allowance operativo separado, nunca control total del tesoro.
Gestión de suscripciones – Un agente puede abonar suscripciones periódicas bajo límites mensuales y de comercio, solicitando aprobación para incrementos de precio o nuevos proveedores.
Operaciones DAO – Una DAO puede autorizar a un agente para distribuir grants, pagar colaboradores, recaudar ingresos de protocolo o ejecutar decisiones de gobernanza aprobadas. El agente puede operar desde un Safe u otra smart account con allowances por token y supervisión de signers.
Principales riesgos de seguridad
-
Inyección por prompt – Un documento, sitio, mensaje o respuesta de API externa podría contener instrucciones diseñadas para manipular al agente. Por ejemplo, una factura fraudulenta puede pedir al agente que ignore su tarea y transfiera fondos a otra dirección. Los controles de autorización duros siguen siendo válidos aunque el modelo obedezca a la instrucción maliciosa: el pago debe fallar si el destinatario está fuera de la lista permitida.
-
Permisos excesivos – Los desarrolladores pueden pedir acceso amplio por simplicidad, lo que amplía el alcance de daños en caso de compromiso del agente o credencial.
-
Robo de credenciales – Un atacante que robe un token OAuth, API key, session key o credencial de wallet de agente puede hacer peticiones que parecen legítimas. Credenciales de vida corta, almacenamiento seguro, revocación y límites transaccionales reducen el impacto. Las recomendaciones de MCP sugieren tokens de acceso de vida corta para minimizar daños por filtración.
-
Ataques de "Confused-Deputy" – Un agente confiable puede ser engañado para usar su autoridad en beneficio de un atacante. El agente no está necesariamente comprometido, sino que falla al reconocer el contexto no autorizado. Restricciones de destinatario, verificación de origen, credenciales específicas por tarea y confirmación explícita de parámetros sensibles ayudan a mitigar estos casos.
-
Gasto indirecto – Un agente podría respetar un tope de transferencia, pero generar exposición financiera mayor de otras formas, como aprobando contratos maliciosos, abriendo posiciones apalancadas o brindando liquidez a pools riesgosos. Las políticas deben cubrir aprobaciones de contratos, compromisos financieros y pasivos futuros, no solo transferencias inmediatas de token.
-
Escalada de privilegios – Un agente podría intentar instalar módulos, cambiar un owner, actualizar políticas o crear otra credencial con mayor autoridad. Acciones de administración y gestión de permisos usualmente deben excluirse de los scopes habituales de agentes.
-
Redelegación insegura – Un sub-agente podría recibir autoridad excesiva o poco clara, haciendo difícil auditar o revocar la cadena de delegación.
-
Permisos obsoletos – Un agente podría mantener acceso tras el fin de su proyecto, dispositivo, empleado o relación comercial. La expiración automática y revisiones periódicas de permisos son esenciales.
-
Complejidad cross-chain – Permisos en una blockchain no aplican automáticamente en otra. Puentes, wrapped assets y mensajes cross-chain pueden introducir nuevos contratos y supuestos de seguridad no presentes en la delegación original.
-
Riesgo de oráculos y precios – Un límite basado en valor puede depender de un feed de precios externo. Un agente autorizado a gastar activos por $1,000 podría superar ese valor si la fuente de precios está desactualizada o manipulada. Los topes denominados en tokens y en fiat pueden comportarse distinto.
¿Existen permisos estandarizados para agentes de IA?
Los sistemas offchain dependen en gran medida de acceso limitado tipo OAuth, mientras que MCP aplica autorización OAuth a las conexiones agente-herramienta. El trabajo de account abstraction y delegación en Ethereum incluye ERC-4337, EIP-7702, ERC-7710 y ERC-7715. Estas tecnologías permiten validación programable, capacidades delegadas, solicitudes de permisos de wallet y ejecución de transacciones con alcance. Proveedores de wallets e infraestructura también están implementando sus propios permisos de gasto, módulos de allowances, sistemas de caveats y cuentas de agente.
El futuro probable no es un único formato de permisos universal, sino un conjunto de estándares interoperables que permitan a agentes, wallets, aplicaciones y servidores de autorización intercambiar mandatos legibles máquina a máquina.
¿Qué es la delegación de agentes de IA en una sola frase?
Conclusión
Los agentes de IA se vuelven útiles cuando pueden actuar, pero actuar requiere autoridad. La estrategia más segura no es dar acceso total al agente y confiar en que se comporte, sino codificar límites claros en los sistemas que utiliza. Los permisos determinan qué puede hacer el agente. Los scopes, dónde y bajo qué condiciones. Los límites de gasto, el valor en riesgo. Expiración, revocación, registros de auditoría y aprobación humana añaden controles adicionales.
Estos conceptos se aplican tanto en software convencional como en infraestructura blockchain. Los tokens OAuth pueden restringir el acceso a servicios web, mientras que cuentas inteligentes, claves de sesión, contratos de delegación y módulos de allowance pueden restringir la ejecución onchain. Conforme los pagos agentivos, trading automatizado, agentes de tesorería y el comercio machine-to-machine crezcan, la delegación será infraestructura esencial. Los usuarios necesitarán fórmulas para dar suficiente autoridad a los agentes sin conceder poder para causar pérdidas catastróficas.
El futuro de los sistemas autónomos no solo depende de que los agentes sean más inteligentes, sino de que su autoridad sea precisa, visible, limitada y fácil de revocar.
