Um chatbot que responde incorretamente gera uma experiência ruim. Um AI agent que bloqueia uma conta, altera um limite ou inicia uma operação errada pode gerar prejuízo financeiro, impacto regulatório e uma investigação difícil de reconstruir.
Essa diferença muda o problema de infraestrutura.
AI agents não apenas processam uma entrada e retornam uma resposta. Eles consultam sistemas, escolhem ferramentas, encadeiam ações e usam o resultado de uma etapa para decidir a próxima. No setor financeiro, esse loop pode envolver dados pessoais, motores de crédito, sistemas antifraude, APIs de pagamento e serviços de Open Finance.
Por isso, proteger o endpoint não é suficiente. A instituição precisa controlar o que cada agent pode consultar, recomendar e executar, além de interromper o fluxo quando o comportamento ultrapassa o esperado.
Os principais riscos aparecem quando a autonomia do agent cresce mais rápido do que os controles ao redor dele.
Risco 1: o agent recebe acesso ao sistema, mas não uma identidade própria
Muitos AI agents entram em produção usando as mesmas credenciais de serviços já existentes. A integração funciona, mas a instituição perde a capacidade de distinguir quem realizou cada ação.
Se vários agents compartilham uma conta de serviço, os logs mostram que uma credencial consultou uma API ou alterou um registro. Não mostram qual agent iniciou a ação, qual tarefa estava executando ou quais permissões realmente precisava naquele momento.
O problema aumenta quando a credencial possui escopos amplos. Um agent criado para consultar o status de uma transação pode acabar tecnicamente autorizado a iniciar pagamentos. Outro, destinado a apoiar uma análise de crédito, pode acessar dados de clientes que não fazem parte do caso em avaliação.
Em sistemas tradicionais, permissões excessivas já são um risco. Em agents, elas ganham escala e velocidade: uma decisão equivocada pode ser repetida em centenas de sessões antes que alguém perceba o padrão.
A arquitetura da instituição deve tratar cada agent como uma identidade operacional independente. Isso pode envolver credenciais próprias, escopos mínimos, tokens de curta duração e políticas diferentes para leitura, recomendação e execução.
O fluxo de autenticação machine-to-machine é apenas o começo. Uma credencial válida responde quem está chamando a API. A política de autorização precisa responder o que essa identidade pode fazer, sobre quais recursos, em qual contexto e até qual limite.
Risco 2: uma decisão probabilística produz uma ação financeira determinística
Modelos trabalham com probabilidades. Pagamentos, bloqueios de conta, alterações cadastrais e decisões de crédito produzem efeitos concretos.
Quando um agent conecta essas duas camadas, uma resposta imprecisa deixa de ser apenas conteúdo incorreto e pode virar uma ação executada em um sistema real. O risco não depende somente da qualidade do modelo. Também depende de quais ferramentas estão disponíveis e de quais controles existem entre a decisão e a execução.
Um agent de atendimento pode consultar uma fatura sem aprovação adicional. Para alterar o endereço de cobrança, a instituição pode exigir uma nova validação de identidade. Para aumentar um limite ou iniciar uma transferência, a política pode exigir uma nova autenticação, aprovação humana ou validação por outro sistema.
Essa separação reduz o raio de impacto sem retirar toda a autonomia do agent. A instituição pode definir controles conforme o risco de cada ação:
- consultas de baixo risco podem seguir automaticamente;
- alterações de dados podem exigir validações adicionais;
- decisões com impacto financeiro podem respeitar limites de valor, frequência e destinatário;
- ações críticas podem exigir aprovação humana antes da execução.
O ponto de controle precisa estar fora das instruções do modelo. Um prompt dizendo que o agent não deve aprovar operações acima de determinado valor é uma orientação, não uma barreira de segurança. O limite precisa ser aplicado por um mecanismo que o agent não consiga ignorar ou alterar.
Com oFunctions da Azion, instituições podem executar lógica programável no caminho da requisição antes que ela alcance a API de origem. Essa capacidade pode ser usada como parte da camada de enforcement para avaliar requisições e aplicar regras definidas pela instituição antes de encaminhá-las aos sistemas de origem.
Risco 3: uma ação válida isoladamente pode formar um comportamento perigoso
Nem todo incidente começa com uma requisição malformada ou uma credencial inválida.
Um agent autenticado pode fazer apenas chamadas permitidas e ainda assim apresentar um comportamento incompatível com sua função. Pode consultar clientes demais em pouco tempo, percorrer uma sequência incomum de endpoints, repetir uma ação após resultados inconclusivos ou continuar executando um fluxo que deveria ter sido interrompido.
Cada requisição parece normal quando analisada sozinha. O risco aparece na sequência.
É a mesma diferença entre verificar uma transação e observar uma sessão inteira. Uma consulta de saldo é legítima. Consultar milhares de contas diferentes com a mesma identidade, em poucos minutos, exige investigação. Uma tentativa de pagamento pode ser esperada. Repetir a operação após uma resposta ambígua pode criar duplicidade ou aumentar custos.
Rate limits genéricos por IP não resolvem todo esse problema. A arquitetura de controle de agents precisa considerar fatores como identidade, tipo de ação, frequência, sequência de chamadas e recursos acessados.
OBot Manager da Azion combina sinais comportamentais, fingerprint e reputação de rede para classificar tráfego automatizado. Essa classificação fornece um sinal adicional para políticas de segurança e mitigação de automações indesejadas. A autorização de um AI agent para executar uma determinada ação, porém, deve continuar sendo definida e aplicada pelos mecanismos de identidade e autorização adotados pela instituição.
Risco 4: o volume de entrada não revela o raio de impacto
Em uma aplicação convencional, uma solicitação normalmente gera um conjunto previsível de chamadas. Em um AI agent, uma tarefa pode iniciar um loop com consultas, inferências, chamadas de ferramentas e novas tentativas.
O banco pode receber apenas cem solicitações de clientes, mas o agent transformar cada uma delas em dezenas de interações com APIs internas. Se uma lógica estiver incorreta, o volume de ações downstream cresce sem que o tráfego inicial pareça anômalo.
Por isso, capacidade e risco não devem ser medidos apenas por requisições recebidas. A instituição também precisa acompanhar quantas ações cada tarefa gera, quanto tempo o fluxo permanece ativo, quais sistemas são acionados e quantas vezes o agent tenta novamente.
A arquitetura do agent pode definir circuit breakers e limites contextuais para reduzir esse raio de impacto. Por exemplo, o sistema pode interromper uma tarefa quando ela excede o número esperado de passos, repete excessivamente uma operação ou ultrapassa limites estabelecidos pela instituição.
A implementação desses controles exige que a arquitetura mantenha o contexto e o estado necessários para avaliar o comportamento acumulado da tarefa. Controles no caminho das requisições podem complementar esse desenho aplicando regras sobre chamadas individuais e protegendo os sistemas de origem.
Essas medidas também protegem a operação contra falhas que não são ataques. Um endpoint que responde de forma ambígua, uma integração indisponível ou uma instrução mal interpretada pode manter o agent em loop e consumir capacidade de origem mesmo com credenciais válidas.
Risco 5: logs de API não formam uma trilha de decisão
Dashboards tradicionais respondem se a API estava disponível, quanto tempo levou e quantos erros ocorreram. Para auditar um AI agent, essas informações são necessárias, mas insuficientes.
Quando uma ação financeira é questionada, a instituição precisa reconstruir o fluxo completo:
- qual agent recebeu a tarefa;
- qual identidade e quais permissões utilizou;
- quais dados e sistemas consultou;
- quais ferramentas acionou e em qual ordem;
- qual ação recomendou ou executou;
- qual política autorizou, bloqueou ou encaminhou a ação para aprovação;
- qual foi o resultado em cada sistema envolvido.
Sem um identificador que conecte essas etapas, a investigação fica dividida entre logs de autenticação, APIs, modelos, ferramentas e sistemas transacionais. A instituição sabe que uma operação aconteceu, mas não consegue reconstruir com clareza como o agent chegou até ela.
OReal-Time Events da Azion oferece visibilidade sobre eventos associados ao tráfego processado pela plataforma. OData Stream permite enviar eventos continuamente para destinos de observabilidade e análise, incluindo plataformas como Splunk, Azure Monitor, Datadog e S3.
Quando a aplicação propaga identificadores de contexto consistentes, essa telemetria pode compor, junto aos registros do próprio agent, dos mecanismos de identidade e dos sistemas financeiros, uma trilha correlacionada no ambiente de observabilidade ou SIEM da instituição.
A infraestrutura de tráfego fornece parte dessa visibilidade. A reconstrução completa da decisão depende da instrumentação de todos os componentes envolvidos no fluxo do agent.
Como organizar os controles por nível de autonomia
Nem todo AI agent financeiro precisa da mesma arquitetura. O controle deve acompanhar a autoridade concedida ao sistema.
Nível de autonomia | Exemplo | Controles que a instituição deve considerar |
Consulta | Buscar status de pagamento ou informações de uma conta | Identidade própria, acesso somente de leitura e limites por recurso |
Recomendação | Sugerir uma decisão de crédito ou sinalizar fraude | Registro dos dados consultados, versão da política e revisão humana quando necessária |
Alteração | Atualizar cadastro, bloquear cartão ou ajustar parâmetros | Validação adicional de identidade e contexto, mecanismos de recuperação e rollback |
Transação | Iniciar pagamento, transferência ou concessão de crédito | Limites de valor e frequência, segregação de funções, aprovação e mecanismos de interrupção |
Essa classificação evita dois extremos. O primeiro é aplicar controles tão rígidos que o agent não consegue operar. O segundo é conceder a uma automação de produção a mesma confiança de um serviço interno tradicional, mesmo quando ela decide dinamicamente quais ações executar.
Quanto maior a autonomia, mais a arquitetura precisa assumir que o agent pode errar, ser induzido a agir fora do esperado ou utilizar uma permissão válida em um contexto inadequado.
Uma camada de controle antes dos sistemas financeiros
Nem todos os controles necessários para AI agents pertencem à mesma camada da arquitetura.
Identidade, autorização, aprovação humana, segregação de funções e estado da tarefa precisam ser definidos pelos sistemas e processos apropriados da instituição. Ao mesmo tempo, controles aplicados no caminho das requisições podem impedir que chamadas inadequadas alcancem APIs e sistemas críticos, além de fornecer sinais de segurança e telemetria para investigação.
Nessa camada de tráfego, a arquitetura pode aplicar verificações e proteções sobre as requisições antes de encaminhá-las à origem.
Na plataforma da Azion,Functions permite executar lógica programável no caminho da requisição;Bot Manager utiliza sinais comportamentais, fingerprint e reputação para classificar tráfego automatizado;Web Application Firewall inspeciona e protege requisições na camada de aplicação; eReal-Time Events eData Stream fornecem recursos de visibilidade e envio de telemetria.
Essas capacidades não substituem os mecanismos de identidade, autorização ou workflow transacional da instituição. Elas podem compor uma camada de enforcement, proteção e observabilidade entre agents e APIs, integrada aos demais controles da arquitetura financeira.
A pergunta que vem antes de colocar um agent em produção
Grande parte do debate sobre AI agents no setor financeiro pergunta se o modelo é preciso, se pode apresentar viés ou se está sujeito a alucinações. Essas perguntas continuam importantes. Mas elas não determinam sozinhas se o sistema está pronto para operar.
Antes do deploy, a instituição precisa responder outra pergunta: qual é a ação de maior impacto que este agent consegue executar com as permissões que possui hoje?
A resposta revela os controles necessários.
Se o agent apenas consulta informações, o risco está principalmente no acesso indevido e na exposição de dados. Se recomenda decisões, entram rastreabilidade e revisão. Se altera sistemas ou movimenta recursos, limites transacionais, segregação de funções, aprovação e mecanismos de interrupção passam a fazer parte do desenho de segurança.
AI agents em produção precisam ser tratados como identidades operacionais com autoridade delimitada, não como interfaces inteligentes conectadas a credenciais de serviço.
A diferença entre uma demonstração convincente e uma operação financeira segura não está apenas no modelo. Está na arquitetura capaz de definir, aplicar e demonstrar o que cada agent tinha permissão para fazer — e em controles de infraestrutura capazes de proteger os sistemas que recebem essas ações.
Leia também:
- Segurança de API para AI Agents: rate limits e auth
- Entendendo a infraestrutura de IA agêntica
- Segurança de APIs financeiras
