💻 ciencias de la computación

Verifiable Delegated Authority for LLM Agents in Banking: A Formal Architecture, Capability Protocol, and Audit Guarantees

Este artículo propone una arquitectura formal para agentes de LLM seguros en la banca que desacopla la autorización del modelo mediante tokens de capacidad atenuados y motores de política deterministas, proporcionando garantías demostrables de contención de autoridad, pérdida financiera limitada e integridad de auditoría contra actores adversarios.

Autores originales: Neeraj Aggarwal

Publicado 2026-10-20

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Neeraj Aggarwal

Artículo original bajo licencia CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

En el mundo de alto riesgo de la banca, la confianza se ha construido tradicionalmente sobre reglas rígidas y actores predecibles. Durante décadas, los bancos han asegurado sus puertas digitales garantizando que cada acción provenga de un humano conocido o de un servicio informático fiable y preprogramado. Estos sistemas operan bajo una premisa sencilla: si una solicitud está firmada por la persona adecuada y sigue los pasos correctos, es segura para su ejecución. Sin embargo, un nuevo tipo de trabajador ha entrado en escena: el agente de inteligencia artificial. A diferencia de un humano o de un programa informático estándar, estos agentes están impulsados por modelos de lenguaje extensos que pueden razonar a través de información compleja y no estructurada, como correos electrónicos o informes. Pueden decidir por sí mismos qué pasos dar a continuación. Esta flexibilidad los hace increíblemente útiles para gestionar tareas administrativas desordenadas, pero también introduce una profunda incertidumbre. Debido a que estos agentes no siempre toman la misma decisión dos veces, incluso ante la misma información, los viejos modelos de seguridad que asumen un actor predecible ya no funcionan. Si a un agente de IA se le dan las llaves para mover dinero, ¿cómo puede un banco estar seguro de que no transferirá fondos que no debería, ya sea por accidente o de forma maliciosa?

Neeraj Aggarwal, un investigador de Infosys, aborda este problema exacto con un nuevo marco diseñado específicamente para la banca. La idea central es dejar de intentar que la propia IA sea perfectamente segura y, en su lugar, construir una jaula segura a su alrededor. En esta nueva arquitectura, la IA se trata no como un tomador de decisiones confiable, sino como un proponente no confiable. Se le permite sugerir acciones, pero nunca se le permite ejecutarlas directamente. En su lugar, cada sugerencia debe pasar por un motor de políticas determinista independiente que actúa como un estricto guardián. Este motor verifica la sugerencia contra un conjunto de reglas y un "token de capacidad" específico que limita exactamente qué puede hacer el agente, cuánto dinero puede mover y durante cuánto tiempo. El sistema está diseñado de tal manera que, incluso si la IA es engañada por un prompt malicioso o confundida por datos erróneos, no puede romper los límites asignados. Los investigadores demuestran matemáticamente que, bajo este diseño, el agente nunca podrá escalar sus propios privilegios para hacer algo para lo que no estaba autorizado, y calculan un límite superior preciso sobre cuánto dinero podría perderse si el sistema es atacado sin intervención humana.

Para asegurar que todo haya ocurrido correctamente, los investigadores también construyeron un sistema de evidencia verificable. Cada paso que el agente da, desde la idea inicial hasta la ejecución final, se registra en un registro seguro e inalterable que está firmado y vinculado entre sí como una cadena. Esto permite que un auditor, o incluso otro ordenador, pueda revisar el registro meses después y verificar que el agente se mantuvo dentro de sus reglas, sin necesidad de ver el proceso de pensamiento interno de la IA o volver a ejecutar la IA misma. El sistema también introduce un método para utilizar múltiples agentes de IA que revisen el trabajo de los demás. Los investigadores descubrieron que simplemente añadir más revisores no garantiza la seguridad; en cambio, la clave es tener revisores que sean diversos, es decir, que estén construidos sobre modelos diferentes o entrenados de forma distinta. Si todos los revisores comparten el mismo punto ciego, todos cometerán el mismo error. Al cuantificar este riesgo, el sistema puede decidir cuándo una segunda opinión realmente vale la pena el coste y cuándo es necesario detenerse y pedir ayuda a un humano.

El equipo probó estas ideas construyendo un prototipo funcional y sometiéndolo a miles de ataques simulados. En estas pruebas, un ordenador adversario —actuando como un agente malicioso, sin un modelo de lenguaje real en el bucle— intentó engañar al sistema para realizar acciones no autorizadas, tales como falsificar tokens, repetir comandos antiguos o manipular los registros. A través de 700.000 intentos, el sistema bloqueó con éxito cada ejecución no autorizada. Las simulaciones, que se basaron en datos sintéticos y utilizaron HMAC-SHA256 para suplantar a las firmas digitales reales, confirmaron que los límites matemáticos de las pérdidas financieras eran precisos; cuando los atacantes intentaron llevar el sistema a su límite absoluto, las pérdidas coincidieron exactamente con el máximo predicho, demostrando que la red de seguridad era hermética. Las pruebas también revelaron dos debilidades específicas en el diseño inicial: una relacionada con cuánto tiempo permanecían válidos los tokens y otra respecto a la capacidad de revertir los registros a un estado anterior. El diseño final cerró estas brechas, asegurando que, incluso si un atacante lograra robar un token, este solo pudiera usarse una vez y dentro de un intervalo de tiempo muy breve.

Este enfoque representa un cambio en la forma en que pensamos sobre la seguridad de los sistemas inteligentes en infraestructuras críticas. En lugar de esperar que la IA siempre se comporte, el sistema asume que podría no hacerlo y construye una capa de ejecución que es independiente del razonamiento de la IA. El resultado es un flujo de trabajo donde la IA puede realizar su trabajo de clasificar información compleja y proponer soluciones, mientras que el banco mantiene el control absoluto sobre la acción final. Los investigadores demostraron que es posible tener agentes potentes y automatizados en un entorno bancario sin crear un riesgo no auditable. Al tratar a la IA como un proponente y a la capa de ejecución como el ejecutor, y al mantener un registro a prueba de manipulaciones de cada decisión, los bancos pueden empezar a utilizar estas herramientas con un nivel de seguridad y responsabilidad que antes era imposible. El trabajo sigue siendo un modelo formal y una simulación, pero proporciona un camino claro y probado para trasladar los agentes de IA de las herramientas experimentales al núcleo de las operaciones financieras reguladas.

Resumen Técnico: Autoridad Delegada Verificable para Agentes de LLM en la Banca

1. Planteamiento del Problema

La integración de agentes de Modelos de Lenguaje de Gran Escala (LLM) en la infraestructura bancaria introduce una brecha de seguridad fundamental. Los modelos de seguridad de API tradicionales dependen de un supuesto de actor estable: ya sea un humano en una sesión autenticada o un servicio determinista que llama a una API con versiones definidas. Los agentes de LLM violan ambos supuestos al leer contexto no estructurado, razonar de forma no determinista y seleccionar secuencias de acciones que pueden variar entre ejecuciones.

Cuando se conectan a sistemas que mueven dinero, este no determinismo crea un riesgo significativo. La investigación de seguridad existente suele centrarse en la detección de inyección de prompts o el filtrado a nivel de modelo. Sin embargo, el autor argumenta que, para la banca regulada, la ejecución de la autoridad debe trasladarse fuera del modelo y hacia el límite de ejecución. El desafío central es proporcionar garantías formales de que un agente, actuando como un proponente estocástico no confiable, no pueda exceder su autoridad delegada, asegurando al mismo tiempo que un tercero (auditor o regulador) pueda verificar el cumplimiento sin confiar en el autoinforme del agente ni acceder a los pesos del modelo.

2. Metodología y Arquitectura del Sistema

El documento propone una arquitectura formal donde el LLM es tratado estrictamente como un proponente no confiable de acciones tipadas, mientras que un motor de políticas determinista y una capa de ejecución imponen toda la autoridad.

Componentes Principales

Modelo Formal de Autoridad:
- Acciones: Definidas como acciones tipadas con espacios de parámetros (por ejemplo, monto, moneda) y exposición de pérdida asociada.
- Cadenas de Delegación: La autoridad se representa como una cadena de concesiones que se atenúan (reducen) con el tiempo. Una cadena válida asegura que ningún agente pueda escalar privilegios; la autoridad efectiva de cualquier agente es un subconjunto de la concesión del principal raíz.
- Base de Computación Confiable (TCB): Incluye el motor de políticas, la capa de ejecución, el registro de solo adición y la infraestructura de identidad. El LLM se excluye explícitamente de la TCB.
Protocolo de Sobres de Intención y Tokens Firmados:
- Sobres de Intención: Las acciones propuestas se envuelven en sobres firmados que contienen la acción, la identidad del agente, la cadena de delegación y el caso de negocio.
- Tokens de Capacidad: Tras la aprobación de la política, el motor emite un token de un solo uso y con límites de parámetros. Crucialmente, la ventana de validez del token ( $t_{exp}$ ) está estrictamente limitada por la expiración de la cadena de delegación subyacente.
- Verificación de Ejecución: La capa de ejecución verifica la firma del token, comprueba que la acción coincida con el tipo y los límites de parámetros del token, asegura que el token esté dentro de su ventana de tiempo y verifica que el identificador no haya sido utilizado.
Flujo de Trabajo Verificable:
- Cada transición de estado emite un evento firmado a un registro encadenado por hash y de solo adición.
- Un verificador basado únicamente en evidencia puede validar todo el flujo de trabajo utilizando solo el registro, las claves públicas y las versiones de las políticas, sin necesidad de replantear el LLM.
Consenso Multi-Agente:
- Para intenciones de alto riesgo, se introduce un segundo agente revisor configurado de forma independiente.
- El documento modela fallos de "causa común" (por ejemplo, puntos ciegos compartidos en el entrenamiento) para demostrar que la diversidad del revisor (diferentes familias de modelos/prompts) es más crítica que el número de revisores para reducir el riesgo residual.

3. Contribuciones Clave

El documento proporciona cinco contribuciones teóricas y prácticas específicas:

Modelo Formal: Una definición de autoridad delegada para agentes de LLM en la banca, que presenta acciones financieras tipadas, cadenas de delegación atenuantes y un motor de política ABAC (Control de Acceso Basado en Atributos) determinista con un ciclo de vida de aprobación humana.
Protocolo de Autorización y Pruebas:
- Teorema 1 (Contención de Autoridad): Demuestra que, bajo un proponente adversario arbitrario, cada acción ejecutada está contenida dentro de la autoridad efectiva de una cadena de delegación válida, siempre que el motor de políticas y los esquemas de firma sean seguros.
- Teorema 2 (Pérdida No Acompañada Limitada): Deriva un límite superior cerrado para la pérdida financiera en acciones ejecutadas sin aprobación humana, basado en topes por tipo y límites de tasa de ventana deslizante.
Análisis de Consenso Multi-Agente:
- Proposición 1: Cuantifica el riesgo residual del consenso, mostrando que añadir revisores ofrece rendimientos decrecientes a menos que se reduzca la probabilidad de fallo de "causa común" ( $\gamma$ ) mediante la diversidad.
- Proposición 2: Establece una regla consciente de los costos para invocar la revisión humana o de agentes basada en la probabilidad de daño y el costo de la revisión.
Definición de Flujo de Trabajo Verificable:
- Teorema 3 (Evidencia de Manipulación): Demuestra que un registro con una cabeza firmada y un testigo independiente (para prevenir ataques de reversión) asegura que cualquier secuencia de evidencia aceptada concuerde con el registro genuino.
- Teorema 4 (Solidez): Demuestra que un verificador basado únicamente en evidencia puede certificar sólidamente que las acciones ejecutadas fueron autorizadas y estaban dentro de los límites, sin acceso al modelo.
- Proposición 3: Proporciona un límite de complejidad de muestreo para detectar la deriva de la política cuando cambian las versiones del modelo.
Implementación de Referencia y Simulación:
- Una implementación en Python probada contra un proponente adversario (sin LLM en el bucle) para validar la contención, los límites de pérdida y la evidencia de manipulación.

4. Resultados

La implementación de referencia y la simulación arrojaron los siguientes resultados:

Contención: En 700,000 intentos de un proponente adversario (que cubren nueve clases de ataque, incluyendo falsificación de tokens, replay y manipulación de parámetros), hubo cero ejecuciones no autorizadas que violaran los teoremas de contención.
Ajuste del Límite de Pérdida: Un adversario que satura el límite de tasa alcanzó exposiciones máximas que coincidían exactamente con el límite teórico del Teorema 2, confirmando que el límite es ajustado.
Brechas de Protocolo Identificadas: La simulación expuso dos brechas críticas en los diseños iniciales:
1. Expiración de Token: Sin la regla $t_{exp} \le t_k$ (expiración del token $\le$ expiración de la cadena), 12,383 de 20,000 intentos se ejecutaron después de que la concesión de delegación hubiera expirado.
2. Reversión de Registro (Rollback): Sin una verificación de testigo independiente, un atacante podría revertir con éxito el registro a una cabeza firmada anterior; con la verificación del testigo, la detección fue del 100%.
Rendimiento: El pipeline de ejecución (verificación de sobre, política, emisión de token, ejecución, registro) incurrió en un overhead mediano de 45 microsegundos por acción, lo que sugiere que el costo de ejecución no es un cuello de botella.
Modelado de Consenso: Las simulaciones de Monte Carlo del modelo de causa común coincidieron con las predicciones analíticas de la Proposición 1 dentro de los márgenes de error.

5. Significado y Reivindicaciones

El autor posiciona este trabajo como un tratamiento formal diseñado específicamente para la banca regulada, distinguiéndolo de la investigación general de seguridad multi-agente.

Cambio en el Límite de Confianza: El documento afirma que, al trasladar la ejecución al límite de ejecución y tratar al LLM como un proponente no confiable, los bancos pueden lograr una contención de autoridad demostrable y límites de pérdida cuantificables que no dependen del razonamiento o alineación del modelo.
Auditabilidad: Una reivindicación significativa es la capacidad de los terceros (auditores/reguladores) para verificar el cumplimiento mediante un verificador basado únicamente en evidencia. Esto permite la auditabilidad sin requerir acceso al modelo propietario o a sus pesos.
Gestión Cuantitativa de Riesgos: El trabajo proporciona un marco cuantitativo para la revisión multi-agente, argumentando que la diversidad de los revisores es el principal palanca para reducir el riesgo residual, más que simplemente aumentar el número de revisores.
Modestia en el Alcance: El autor establece explícitamente que los resultados asumen que el LLM actúa dentro de un límite aplicado. No pretende resolver el problema de si la inyección de prompts puede desviar a un agente hacia acciones permitidas pero indeseables (por ejemplo, reenviar un pago incorrecto dentro de los límites), aunque señala que el consenso reduce la probabilidad de tales eventos. También reconoce que las pruebas son "de papel y lápiz" y no mecanizadas, y que la simulación utiliza datos sintéticos sin LLM reales en el bucle, dejando la resistencia a la inyección en el mundo real y la evaluación de la utilidad como trabajo futuro.

En conclusión, el documento argumenta que, sin tal arquitectura formal, la integración de agentes en los flujos de trabajo centrales de la banca crea una "superficie de ataque ampliamente no auditada". Con esta arquitectura, las instituciones pueden extender la automatización de agentes hacia los flujos de trabajo de back-office con garantías formales de contención y verificabilidad.