💻 ciência da computação

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

Este artigo propõe uma arquitetura formal para agentes de LLM seguros no setor bancário que desacopla a autorização do modelo usando tokens de capacidade atenuados e motores de política determinísticos, fornecendo garantias comprováveis de contenção de autoridade, perda financeira limitada e integridade de auditoria contra atores adversários.

Autores originais: Neeraj Aggarwal

Publicado 2026-10-20

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Neeraj Aggarwal

Artigo original sob licença CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

No mundo de alto risco do setor bancário, a confiança tem sido tradicionalmente construída sobre regras rígidas e atores previsíveis. Durante décadas, os bancos garantiram suas portas digitais assegurando que cada ação viesse de um humano conhecido ou de um serviço de computador confiável e pré-programado. Esses sistemas operam sob uma premissa simples: se uma solicitação é assinada pela pessoa certa e segue os passos corretos, ela é segura para ser executada. No entanto, um novo tipo de trabalhador entrou em cena: o agente de inteligência artificial. Diferente de um humano ou de um programa de computador padrão, esses agentes são alimentados por modelos de linguagem de grande escala que podem raciocinar através de informações complexas e não estruturadas, como e-mails ou relatórios. Eles podem decidir por conta própria quais passos tomar a seguir. Essa flexibilidade os torna incrivelmente úteis para lidar com tarefas burocráticas desorganizadas, mas também introduz uma incerteza profunda. Como esses agentes nem sempre tomam a mesma decisão duas vezes, mesmo quando recebem a mesma informação, os antigos modelos de segurança que assumem um ator previsível já não se sustentam. Se um agente de IA receber as chaves para movimentar dinheiro, como um banco pode ter certeza de que ele não transferirá fundos que não deveria, seja por acidente ou de forma maliciosa?

Neeraj Aggarwal, um pesquisador da Infosys, aborda exatamente esse problema com um novo framework projetado especificamente para o setor bancário. A ideia central é parar de tentar tornar a própria IA perfeitamente segura e, em vez disso, construir uma gaiola segura ao redor dela. Nesta nova arquitetura, a IA é tratada não como uma tomadora de decisão confiável, mas como uma proponente não confiável. Ela tem permissão para sugerir ações, mas nunca é permitida a executá-las diretamente. Em vez disso, cada sugestão deve passar por um mecanismo de política determinístico separado, que atua como um guardião rigoroso. Este mecanismo verifica a sugestão contra um conjunto de regras e um "token de capacidade" específico que limita exatamente o que o agente pode fazer, quanto dinheiro pode movimentar e por quanto tempo. O sistema é projetado de modo que, mesmo que a IA seja enganada por um prompt malicioso ou confundida por dados ruins, ela não consiga romper seus limites atribuídos. Os pesquisadores provam matematicamente que, sob este design, o agente nunca poderá escalar seus próprios privilégios para fazer algo para o qual não foi autorizado, e eles calculam um limite superior preciso de quanto dinheiro poderia ser perdido se o sistema for atacado sem intervenção humana.

Para garantir que tudo ocorreu corretamente, os pesquisadores também construíram um sistema de evidências verificáveis. Cada passo que o agente dá, desde a ideia inicial até a execução final, é registrado em um log seguro e imutável, que é assinado e encadeado. Isso permite que um auditor, ou até mesmo outro computador, possa olhar para o registro meses depois e verificar que o agente permaneceu dentro de suas regras, sem a necessidade de ver o processo de pensamento interno da IA ou reexecutar a própria IA. O sistema também introduz um método para usar múltiplos agentes de IA para revisar o trabalho uns dos outros. Os pesquisadores descobriram que simplesmente adicionar mais revisores não garante segurança; em vez disso, a chave é ter revisores que sejam diversos, ou seja, construídos sobre modelos diferentes ou treinados de forma distinta. Se todos os revisores compartilharem o mesmo ponto cego, todos cometerão o mesmo erro. Ao quantificar esse risco, o sistema pode decidir quando uma segunda opinião é realmente digna do custo ou quando é necessário parar e pedir ajuda a um humano.

A equipe testou essas ideias construindo um protótipo funcional e submetendo-o a milhares de ataques simulados. Nesses testes, um computador adversário — atuando como um agente malicioso, sem um modelo de linguagem real no loop — tentou enganar o sistema para realizar ações não autorizadas, como forjar tokens, repetir comandos antigos ou adulterar os logs. Em 700.000 tentativas, o sistema bloqueou com sucesso todas as execuções não autorizadas. As simulações, que utilizaram dados sintéticos e usaram HMAC-SHA256 para representar assinaturas digitais reais, confirmaram que os limites matemáticos de perda financeira eram precisos; quando os atacantes tentaram levar o sistema ao seu limite absoluto, as perdas corresponderam exatamente ao máximo previsto, provando que a rede de segurança era estanque. Os testes também revelaram duas fraquezas específicas no design inicial: uma relacionada à duração da validade dos tokens e outra em relação à capacidade de reverter os logs para um estado anterior. O design final fechou essas lacunas, garantindo que, mesmo que um atacante conseguisse roubar um token, ele só pudesse ser usado uma única vez e apenas dentro de uma janela de tempo muito curta.

Esta abordagem representa uma mudança na forma como pensamos sobre a segurança de sistemas inteligentes em infraestruturas críticas. Em vez de esperar que a IA sempre se comporte, o sistema assume que ela pode não se comportar e constrói uma camada de aplicação que é separada do raciocínio da IA. O resultado é um fluxo de trabalho onde a IA pode realizar seu trabalho de analisar informações complexas e propor soluções, enquanto o banco retém o controle absoluto sobre a ação final. Os pesquisadores demonstraram que é possível ter agentes poderosos e automatizados em um ambiente bancário sem criar um risco não auditável. Ao tratar a IA como uma proponente e a camada de execução como a aplicadora das regras, e ao manter um registro à prova de adulteração de cada decisão, os bancos podem começar a usar essas ferramentas com um nível de segurança e responsabilidade que antes era impossível. O trabalho permanece um modelo formal e uma simulação, mas fornece um caminho claro e comprovado para mover agentes de IA de ferramentas experimentais para o núcleo das operações financeiras regulamentadas.

Resumo Técnico: Autoridade Delegada Verificável para Agentes de LLM no Setor Bancário

1. Definição do Problema

A integração de agentes de Modelos de Linguagem de Grande Escala (LLM) na infraestrutura bancária introduz uma lacuna de segurança fundamental. Os modelos tradicionais de segurança de API dependem de uma suposição de ator estável: ou um humano em uma sessão autenticada ou um serviço determinístico chamando uma API versionada. Os agentes de LLM violam ambas as suposições ao ler contextos não estruturados, raciocinar de forma não determinística e selecionar sequências de ações que podem variar entre as execuções.

Quando conectados a sistemas que movimentam dinheiro, esse não determinismo cria um risco significativo. A pesquisa de segurança existente foca frequentemente na detecção de injeção de prompt ou filtragem ao nível do modelo. No entanto, o autor argumenta que, para o setor bancário regulado, a imposição da autoridade deve ser movida do modelo para a fronteira de execução. O desafio central é fornecer garantias formais de que um agente, atuando como um proponente estocástico não confiável, não possa exceder sua autoridade delegada, garantindo simultaneamente que um terceiro (auditor ou regulador) possa verificar a conformidade sem confiar no autorrelato do agente ou acessar os pesos do modelo.

2. Metodologia e Arquitetura do Sistema

O artigo propõe uma arquitetura formal onde o LLM é tratado estritamente como um proponente não confiável de ações tipadas, enquanto um motor de política determinístico e uma camada de execução impõem toda a autoridade.

Componentes Principais

Modelo Formal de Autoridade:
- Ações: Definidas como ações tipadas com espaços de parâmetros (ex: valor, moeda) e exposição de perda associada.
- Cadeias de Delegação: A autoridade é representada como uma cadeia de concessões que se atenuam (reduzem) ao longo do tempo. Uma cadeia válida garante que nenhum agente possa escalar privilégios; a autoridade efetiva de qualquer agente é um subconjunto da concessão do principal raiz.
- Base de Computação Confiável (TCB): Inclui o motor de política, a camada de execução, o log de anexação única (append-only) e a infraestrutura de identidade. O LLM é explicitamente excluído da TCB.
Protocolo de Envelopes de Intenção Assinados e Tokens:
- Envelopes de Intenção: As ações propostas são encapsuladas em envelopes assinados contendo a ação, a identidade do agente, a cadeia de delegação e o caso de negócio.
- Tokens de Capacidade: Após a aprovação da política, o motor cunha um token de uso único e limitado por parâmetros. Crucialmente, a janela de validade do token ( $t_{exp}$ ) é estritamente limitada pela expiração da cadeia de delegação subjacente.
- Verificação de Execução: A camada de execução verifica a assinatura do token, checa se a ação corresponde ao tipo e aos limites de parâmetros do token, garante que o token esteja dentro de sua janela de tempo e verifica se o identificador ainda não foi utilizado.
Fluxo de Trabalho Verificável:
- Cada transição de estado emite um evento assinado para um log de encadeamento de hash e anexação única.
- Um verificador baseado apenas em evidências pode validar todo o fluxo de trabalho usando apenas o log, chaves públicas e versões de política, sem precisar reexecutar o LLM.
Consenso Multi-Agente:
- Para intenções de alto risco, um segundo agente revisor, configurado de forma independente, é introduzido.
- O artigo modela falhas de "causa comum" (ex: pontos cegos de treinamento compartilhados) para demonstrar que a diversidade do revisor (diferentes famílias de modelos/prompts) é mais crítica do que a contagem de revisores para reduzir o risco residual.

3. Principais Contribuições

O artigo fornece cinco contribuições teóricas e práticas específicas:

Modelo Formal: Uma definição de autoridade delegada para agentes de LLM no setor bancário, apresentando ações financeiras tipadas, cadeias de delegação atenuantes e um motor de política ABAC (Controle de Acesso Baseado em Atributos) determinístico com um ciclo de vida de aprovação humana.
Protocolo de Autorização e Provas:
- Teorema 1 (Contenção de Autoridade): Prova que, sob um proponente adversário arbitrário, toda ação executada está contida na autoridade efetiva de uma cadeia de delegação válida, desde que o motor de política e os esquemas de assinatura sejam seguros.
- Teorema 2 (Perda Não Assistida Limitada): Deriva um limite superior em forma fechada para a perda financeira de ações executadas sem aprovação humana, baseando-se em tetos por tipo e limites de taxa de janela deslizante.
Análise de Consenso Multi-Agente:
- Proposição 1: Quantifica o risco residual de consenso, mostrando que adicionar revisores gera retornos decrescentes, a menos que a probabilidade de falha de "causa comum" ( $\gamma$ ) seja reduzida via diversidade.
- Proposição 2: Estabelece uma regra consciente de custo para invocar revisão humana ou de agente com base na probabilidade de dano e no custo da revisão.
Definição de Fluxo de Trabalho Verificável:
- Teorema 3 (Evidência de Adulteração): Prova que um log com um cabeçalho assinado e uma testemunha independente (para evitar ataques de rollback) garante que qualquer sequência de evidência aceita concorde com o log genuíno.
- Teorema 4 (Correção/Soundness): Demonstra que um verificador baseado apenas em evidências pode certificar de forma íntegra que as ações executadas foram autorizadas e estavam dentro dos limites, sem acesso ao modelo.
- Proposição 3: Fornece um limite de complexidade de amostragem para detectar o desvio de política quando as versões do modelo mudam.
Implementação de Referência e Simulação:
- Uma implementação em Python testada contra um proponente adversário (sem LLM no loop) para validar contenção, limites de perda e evidência de adulteração.

4. Resultados

A implementação de referência e a simulação produziram os seguintes resultados:

Contenção: Em 700.000 tentativas de um proponente adversário (cobrindo nove classes de ataque, incluindo falsificação de tokens, replay e adulteração de parâmetros), houve zero execuções não autorizadas que violaram os teoremas de contenção.
Estreiteza do Limite de Perda: Um adversário saturando o limite de taxa atingiu exposições máximas que corresponderam exatamente ao limite teórico do Teorema 2, confirmando que o limite é estreito (tight).
Lacunas de Protocolo Identificadas: A simulação expôs duas lacunas críticas em designs iniciais:
1. Expiração de Token: Sem a regra $t_{exp} \le t_k$ (expiração do token $\le$ expiração da cadeia), 12.383 de 20.000 tentativas foram executadas após a expiração da concessão de delegação.
2. Rollback de Log: Sem uma verificação de testemunha independente, um atacante poderia realizar o rollback do log para um cabeçalho assinado mais antigo; com a verificação da testemunha, a detecção foi de 100%.
Desempenho: O pipeline de imposição (verificação de envelope, política, cunhagem de token, execução, log) incorreu em um overhead mediano de 45 microssegundos por ação, sugerindo que o custo de imposição não é um gargalo.
Modelagem de Consenso: Simulações de Monte Carlo do modelo de causa comum corresponderam às previsões analíticas da Proposição 1 dentro das margens de erro.

5. Significância e Alegações

O autor posiciona este trabalho como um tratamento formal feito especificamente para o setor bancário regulado, distinguindo-o da pesquisa geral de segurança multi-agente.

Mudança na Fronteira de Confiança: O artigo afirma que, ao mover a imposição para a fronteira de execução e tratar o LLM como um proponente não confiável, os bancos podem alcançar contenção de autoridade provável e limites de perda quantificáveis que não dependem do raciocínio ou alinhamento do modelo.
Auditabilidade: Uma alegação significativa é a capacidade de terceiros (auditores/reguladores) verificarem a conformidade via um verificador baseado apenas em evidências. Isso permite a auditabilidade sem exigir acesso ao modelo proprietário ou seus pesos.
Gestão de Risco Quantitativa: O trabalho fornece um framework quantitativo para revisão multi-agente, argumentando que a diversidade dos revisores é o principal alavancador para reduzir o risco residual, em vez de simplesmente aumentar o número de revisores.
Modéstia de Escopo: O autor declara explicitamente que os resultados assumem que o LLM atua dentro de uma fronteira imposta. Eles não pretendem resolver o problema de injeção de prompt direcionando um agente para ações permitidas, mas indesejáveis (ex: reenviar um pagamento errado dentro dos limites), embora notem que o consenso reduz a probabilidade de tais eventos. Eles também reconhecem que as provas são "de papel e caneta" e não mecanizadas, e que a simulação usa dados sintéticos sem LLMs reais no loop, deixando a resistência à injeção no mundo real e a avaliação de utilidade como trabalhos futuros.

Em conclusão, o artigo argumenta que, sem tal arquitetura formal, a integração de agentes no núcleo da infraestrutura bancária cria uma "superfície de ataque amplamente não auditada". Com esta arquitetura, as instituições podem estender a automação de agentes para fluxos de trabalho de back-office com garantias formais de contenção e verificabilidade.