Agent Security Meets Regulatory Reality -- A Practitioner Systematization of Autonomous-Agent Threats and Controls in Regulated Financial Systems

Resumo Técnico: A Segurança de Agentes Encontra a Realidade Regulatória

Declaração do Problema
O artigo aborda um descompasso crítico entre a literatura acadêmica sobre a segurança de agentes de Grandes Modelos de Linguagem (LLMs) e as realidades práticas de implantação desses sistemas em ambientes financeiros regulados. Embora a pesquisa de segurança existente tenha catalogado sistematicamente as superfícies de ataque de agentes (ex: injeção de prompt, abuso de ferramentas, manipulação de identidade), este trabalho é predominantemente baseado em laboratório e carece de conexão com os modelos de ameaças formais exigidos pela regulação. Por outro lado, as orientações para prática de IA regulada (ex: SOC 2, GDPR, Lei de IA da UE) oferecem listas de verificação de conformidade, mas falham em fundamentar essas obrigações nos modos específicos de falha das arquiteturas de agentes autônomos. Consequentemente, instituições financeiras que implantam agentes para tarefas como o Know Your Customer (KYC) carecem de um framework para mapear categorias de ameaças estabelecidas às suas obrigações específicas de responsabilidade legal e auditoria.

Metodologia
Os autores preenchem essa lacuna por meio de uma sistematização baseada em experiência, derivada de uma implantação em produção de agentes MCP (Model Context Protocol), RAG (Retrieval-Augmented Generation) e A2A (Agent-to-Agent) para o onboarding de crédito ao consumidor via KYC. A metodologia envolve três etapas primárias:

1. Mapeamento de Ameaças para Regulações: Os autores pegam seis categorias estabelecidas de ameaças de agentes (injeção de prompt, identidade/autorização, auditabilidade de ação, abuso de ferramenta, residência de dados e aplicação de política de fronteira) e analisam como as regulamentações financeiras (US ECOA/Regulation B, Lei de IA da UE, Artigo 22 do GDPR e orientações da FINRA) amplificam essas ameaças. Eles argumentam que, em um contexto regulado, a severidade de uma ameaça não é apenas seu potencial para ação não autorizada, mas sua capacidade de criar decisões inexplicáveis ou falhas de auditoria.
2. Documentação de Padrões Arquiteturais: O artigo detalha quatro padrões arquiteturais específicos implementados no sistema de produção para satisfazer essas restrições regulatórias amplificadas.
3. Relato de Resultados Negativos: Os autores documentam explicitamente três resultados onde os controles falharam ou atingiram limites, incluindo questões detectadas apenas por auditoria interna e segmentos populacionais que o sistema não pôde atender.

Principais Contribuições e Padrões Arquiteturais
A principal contribuição do artigo é um mapeamento de ameaças de agentes para obrigações de controle regulatório, demonstrando que "segurar agentes sob regulação" exige tornar a auditabilidade, a autorização de privilégio mínimo e a aplicação de política de fronteira reais em escala de produção. Os autores observaram e validaram quatro padrões arquiteturais:

• Coreografia de Conformidade A2A: Um agente orquestrador coordena uma sequência determinística de subagentes (verificação de identidade, recuperação de bureau, verificações de política). Este padrão garante que cada decisão seja composta de saídas estruturadas, criando uma trilha de auditoria consistente que satisfaz os requisitos do ECOA para o raciocínio de ação adversa.
• Grounded-RAG-for-Audit (RAG Fundamentado para Auditoria): Para evitar o uso de políticas obsoletas, os documentos de política são ingeridos em um repositório de recuperação com um portão obrigatório de aprovação humana. Cada chamada de ferramenta registra a versão e o hash do documento específico, garantindo que cada decisão automatizada seja rastreável a uma política atualmente aprovada.
• Propagação de Case-ID: Reconhecendo que os logs padrão de ferramentas MCP carecem de contexto, os autores impuseram um cabeçalho de identificador de caso obrigatório em cada chamada de ferramenta. Isso permite que os auditores reconstruam toda a cadeia de chamadas de ferramentas e verificações de política para um solicitante específico a partir de um único ID de caso, satisfazendo o requisito estatutário para fatores de decisão rastreáveis.
• Proxy de Redação na Camada de Inferência: Para abordar a injeção de prompt e a residência de dados (GDPR), documentos brutos nunca são enviados ao modelo. Uma etapa de extração estruturada coleta apenas os campos necessários, que são então redigidos ou tokenizados por um proxy antes de chegarem ao endpoint de inferência. Isso garante que o modelo de terceiros processe nenhum PII residente, estreitando a obrigação de residência de dados para a camada de extração controlada.

Resultados e Descobertas Negativas
A implantação moveu com sucesso um processo de KYC manual de vários dias para resolução automatizada no mesmo dia para aproximadamente 80% dos casos (4 em cada 5), com os 20% restantes sendo encaminhados para revisão humana. O sistema escalou horizontalmente sem aumentar o quadro de funcionários. No entanto, o artigo destaca três resultados negativos significativos:

1. Falha de Política Obsoleta: Ocorreu uma falha de controle onde o agente aplicou uma versão de política substituída porque o portão de aprovação humana ainda não havia aprovado a atualização. Isso resultou em uma superverificação sistemática de clientes, uma lacuna de conformidade identificada apenas pela auditoria interna, não pelo próprio sistema do agente.
2. Retrofit de Interface MCP: A implementação da propagação de Case-ID revelou que as ferramentas MCP existentes não foram projetadas com a auditabilidade em mente. O retrofit de cada ferramenta para aceitar e propagar identificadores de caso exigiu mudanças significativas nos contratos de interface e revalidação, um custo não antecipado pelas taxonomias de segurança atuais.
3. Exclusão Sistêmica: Aproximadamente um em cada nove candidatos não pôde ser atendido pela pipeline automatizada porque careciam de dois canais de contato ativos necessários para a autenticação de dois fatores. Isso representa um limite de design onde a arquitetura não consegue resolver a exclusão de candidatos legítimos, levantando questões não resolvidas sobre impacto díspar sob estruturas de justiça de crédito (fair lending).

Significância
O artigo conclui que o hiato entre os modelos de ameaças de laboratório e a produção regulada é o principal desafio para a segurança de agentes no setor financeiro. Os autores argumentam que segurar agentes sob regulação é menos sobre descobrir novas classes de ataques e mais sobre engenharia de soluções em escala de produção para auditabilidade, autorização de privilégio mínimo e aplicação de política de fronteira — requisitos que os frameworks de agentes atuais deixam para o engenheiro de implantação. Ao oferecer um mapeamento reproduzível de ameaças para obrigações legais e documentar tanto os padrões bem-sucedidos quanto os limites rígidos, o artigo visa fornecer uma base transferível para o trabalho revisado por pares e fundamentado em implantação na interseção entre a segurança de agentes e a prática regulatória.