O Febraban Tech 2026 começa em 24 de agosto, colocando no centro da discussão um tema que diz bastante sobre o momento atual do setor financeiro: agentes inteligentes.

Na abertura, líderes dos maiores bancos do país discutem como a IA e os agentes estão redesenhando escala, confiança e valor. A programação também inclui agentes de IA em rede, engenharia híbrida entre humanos e agentes, identidade digital, real-time intelligent banking, cloud, segurança e finanças embarcadas.

Isso pode parecer apenas mais uma etapa da evolução da IA generativa.

Mas existe uma mudança arquitetural importante escondida nessa conversa.

Há uma diferença enorme entre uma IA que responde e uma IA que age.

Um assistente puramente conversacional errado pode produzir uma resposta ruim.

Um agente com acesso a ferramentas pode produzir um efeito real em outro sistema.

E quando IA começa a interpretar objetivos, selecionar ferramentas e executar ações, autonomia deixa de ser apenas uma característica do modelo.

Ela passa a ser um problema de arquitetura.

Do assistente ao agente

Boa parte das aplicações de IA generativa que usamos até agora segue um fluxo relativamente simples:

Usuário
   |
   v
Pergunta
   |
   v
LLM
   |
   v
Resposta
   |
   v
Usuário decide o que fazer

O modelo interpreta uma entrada e gera uma saída.

Existem riscos importantes: alucinação, vazamento de dados, respostas incorretas, prompt injection.

Mas, em muitos casos, a decisão final continua com o humano.

Com agentes, o fluxo começa a mudar:

Usuário
   |
   v
Objetivo
   |
   v
Agent
   |
   v
Interpreta contexto
   |
   v
Planeja
   |
   v
Escolhe ferramentas
   |
   v
Executa ações

Agora o modelo não está apenas explicando como alguma coisa poderia ser feita.

Ele pode participar da cadeia que realmente faz.

Em um banco, isso pode significar consultar informações, preparar uma transferência, iniciar um processo, atualizar um cadastro, interagir com sistemas de risco ou acionar diferentes capacidades financeiras.

Parece uma evolução incremental do chatbot.

Na prática, muda o modelo de confiança da arquitetura.

A premissa escondida

Grande parte dos sistemas digitais atuais foi construída sobre uma premissa implícita:

Existe uma intenção humana relativamente explícita antes de cada operação relevante.

Considere uma transferência.

No modelo tradicional:

intenção humana
      |
      v
navegação
      |
      v
seleção da funcionalidade
      |
      v
preenchimento
      |
      v
confirmação
      |
      v
requisição
      |
      v
efeito

O usuário escolhe Pix.

Escolhe o destinatário.

Informa o valor.

Revisa.

Confirma.

O software executa um comando relativamente explícito.

Agora imagine outra interação:

“Organize minhas contas deste mês e pague aquilo que estiver vencendo.”

O sistema passa a lidar com algo diferente:

Objetivo
   |
   v
Agent
   |
   v
Interpreta intenção
   |
   v
Busca contexto
   |
   v
Identifica opções
   |
   v
Decide sequência
   |
   v
Escolhe ferramentas
   |
   v
Executa ações

Em qual ponto aconteceu a autorização?

A pergunta deixa de ser apenas:

“O usuário está autenticado?”

E passa a incluir:

“Quais decisões esse agente está autorizado a tomar em nome dele?”

Autenticação continua necessária, assim como sempre foi a autorização.

Com agentes, porém, surge uma camada adicional: precisamos distinguir a autoridade do usuário da autoridade delegada ao agente e determinar quais decisões ele pode tomar em nome daquele usuário.

O blast radius da autonomia

Um agente que apenas gera texto tem um raio de impacto relativamente limitado.

Um agente conectado a ferramentas pode atravessar várias camadas do sistema.

Usuário
   |
   v
Intenção
   |
   v
Agent -----------------------------+
   |                               |
   v                               |
Planner                            |
   |                               |
   v                               |
Policy Engine ----------------------+---> Audit /
   |                               |      Observability
   v                               |          ^
Tool Gateway ------------------------------- +
   |
   +--> Payments API ------> Ledger --> Eventos
   |                                       |
   +--> Customer API ------> Database      +--> Antifraude
   |                                       +--> Analytics
   +--> Investments API                    +--> Integrações
   |                                            externas
   +--> Credit API --------> Risk Engine

Agora uma decisão incorreta pode se propagar por:

Domínio → API → serviços → banco → eventos → antifraude → analytics → integrações externas

A pergunta arquitetural passa a ser:

Se o agente errar, até onde esse erro consegue chegar?

Esse é um princípio antigo de arquitetura aplicado a um componente novo.

Quanto maior a autonomia, mais importante se torna controlar o blast radius.

O agente deveria ter as mesmas permissões do usuário?

Não necessariamente.

Imagine:

Usuário
  |-- consultar saldo          OK
  |-- realizar Pix             OK
  |-- contratar crédito        OK
  |-- alterar cadastro         OK

Agente
  |-- consultar saldo          OK
  |-- listar contas            OK
  |-- preparar Pix             OK
  |-- executar Pix             depende
  |-- contratar crédito        NÃO

Isso cria uma distinção importante:

User permissions
        ⊇
Agent permissions

Em fluxos nos quais o agente atua em nome de alguém, um modelo mental ainda mais útil é pensar a autorização efetiva como a interseção de diferentes limites:

autoridade efetiva
      =
permissões do usuário
      ∩
permissões do agente
      ∩
políticas da operação

Não basta o usuário poder executar uma ação.

Também não basta o agente ter acesso técnico à ferramenta.

A operação precisa satisfazer as fronteiras aplicáveis ao usuário, ao agente e ao contexto daquela ação.

Esse ponto já começa a aparecer nas recomendações de arquitetura para sistemas agentic.

O AWS Well-Architected Agentic AI Lens, por exemplo, recomenda separar identidades humanas e identidades de agentes, aplicar least privilege e propagar o contexto do usuário sem simplesmente transformar o agente no próprio usuário.

Isso importa por dois motivos.

O primeiro é segurança.

O segundo é auditoria.

Se uma operação foi realizada por um agente em nome de uma pessoa, deveríamos conseguir distinguir:

quem solicitou
quem interpretou
quem autorizou
quem executou
qual política foi aplicada
qual foi o resultado

Em sistemas autônomos, atribuição precisa ser explícita.

Tool calling não deveria ser autorização

Um dos riscos mais óbvios seria construir algo assim:

Agent
  |
  v
payment.create
  |
  v
Payments API

O mesmo componente que interpreta linguagem natural também decide sozinho se aquela ação pode acontecer.

Isso cria uma fronteira de confiança frágil.

Uma alternativa mais defensiva:

Agent
  |
  v
Tool Request
  |
  v
Policy / Authorization
  |
  v
Schema & Parameter Validation
  |
  v
Tool Gateway
  |
  v
Domain API

O agente propõe uma ação.

Componentes externos ao raciocínio do modelo determinam se aquela ação pode ser executada e se os parâmetros recebidos são válidos para aquele contexto.

A documentação da AWS para Agentic AI recomenda esse mesmo princípio de separação: a autorização de ferramentas deve ser aplicada externamente ao raciocínio do modelo, com políticas explícitas, propagação de identidade e controles adicionais para operações de maior risco.

Isso representa um princípio importante:

Prompt não é policy.

Podemos instruir o modelo a não fazer determinada coisa.

Mas uma regra crítica não deveria existir apenas como linguagem natural dentro do contexto do LLM.

Se a regra importa para segurança, dinheiro, privacidade ou compliance, ela precisa existir em uma fronteira que o modelo não controla.

Autorizar a tool não significa autorizar qualquer parâmetro

Existe uma segunda fronteira que pode passar despercebida.

Autorização responde:

“Este agente pode chamar esta ferramenta?”

Mas ainda precisamos responder:

“Ele pode chamá-la com estes parâmetros?”

Imagine uma tool:

transfer_money(
    destination="...",
    amount=...
)

Ter permissão para usar transfer_money não deveria significar liberdade irrestrita para escolher qualquer destinatário, qualquer conta de origem ou qualquer valor.

Por isso, entre autorização e execução, faz sentido existir validação estruturada:

Agent
   |
   v
Tool Request
   |
   v
Authorization
   |
   v
Schema Validation
   |
   v
Parameter Policies
   |
   v
Tool Gateway
   |
   v
Domain API

Algumas verificações são puramente estruturais:

amount > 0
currency ∈ supported_currencies
destination matches expected format
required fields are present

Outras dependem do negócio:

amount <= delegated_limit
destination ∈ allowed_recipients
account belongs to authenticated customer
operation allowed for this risk profile

Essa separação é importante porque um modelo pode escolher corretamente a tool e ainda produzir argumentos incorretos, excessivos ou incompatíveis com a política.

A AWS recomenda validar os inputs das tools contra schemas e políticas antes da execução e validar ou sanitizar seus outputs antes de devolvê-los ao agente. A OWASP também enfatiza structured outputs, schema validation, least privilege e controles explícitos para ações sensíveis.

Permissão para usar uma capacidade não é permissão para usá-la de qualquer maneira.

Human-in-the-loop não é um botão de confirmação

Outra resposta fácil seria colocar aprovação humana em tudo.

Mas isso também falha.

Se qualquer operação exigir confirmação, a autonomia praticamente desaparece.

Se nenhuma exigir, podemos criar um sistema com liberdade excessiva.

O problema é encontrar a fronteira.

Uma alternativa é tratar aprovação como política baseada em risco:

Agent
  |
  v
Ação proposta
  |
  v
Risk / Policy
  |
  +-- baixo risco  --> executa
  +-- médio risco  --> confirma
  +-- alto risco   --> bloqueia

Por exemplo:

consultar saldo
    -> automático

listar contas
    -> automático

preparar transferência
    -> automático

executar transferência
    -> depende da política

operação de alto valor
    -> confirmação explícita

contratação sensível
    -> fluxo específico

O próprio Agentic AI Lens chama atenção para dois extremos: revisar tudo gera fadiga e aprovações mecânicas; não revisar nada produz autonomia sem limites.

Portanto:

Human-in-the-loop não deveria significar “um humano em todo lugar”. Deveria significar “um humano nas decisões em que o julgamento realmente muda o risco”.

Agentes não revogam as leis dos sistemas distribuídos

Agora imagine que o agente execute:

POST /payments

A requisição demora.

O agente não sabe se houve sucesso.

Tenta novamente.

tentativa 1 -> timeout
tentativa 2 -> timeout
tentativa 3 -> sucesso

Mas e se as duas primeiras também tiverem sido processadas?

Temos um problema conhecido:

retries + efeitos colaterais.

A diferença é que agora existe uma camada autônoma tomando decisões sobre quando tentar novamente.

Por isso, princípios como idempotência ficam ainda mais importantes.

autonomia
   +
retries
   +
efeitos colaterais
   =
controle explícito de idempotência

O agente pode ser novo.

A física dos sistemas distribuídos continua a mesma.

Essa talvez seja uma das lições mais importantes dessa mudança.

Muitas discussões sobre agentes parecem completamente novas, mas acabam reencontrando problemas clássicos de engenharia:

• retries;
• idempotência;
• consistência;
• autorização;
• observabilidade;
• contratos;
• isolamento;
• rate limiting;
• auditoria;
• resiliência.

A tecnologia muda.

Os fundamentos permanecem.

Observabilidade precisa explicar comportamento

Hoje observamos sistemas principalmente através de métricas como:

latency
error rate
throughput
CPU
memory
availability

Isso continuará sendo necessário.

Mas um agente introduz outra categoria de perguntas:

quantas tools foram chamadas por objetivo?
quantas ações foram bloqueadas?
quantos retries ocorreram?
quantas tarefas exigiram intervenção humana?
qual foi a taxa de conclusão?
qual foi o custo por tarefa?
qual ferramenta foi escolhida?
a escolha foi considerada correta pelas avaliações?
qual política mais bloqueou ações?

Um trace tradicional pode ser:

request
 |-- service A
 |-- service B
 |-- database

Em um sistema agentic, talvez precisemos de algo mais parecido com:

objective
 |-- decision / planning summary
 |-- tool selection
 |    |-- authorization
 |-- tool call
 |    |-- retry
 |    |-- result
 |-- human approval
 |-- outcome

Não basta saber que a API retornou HTTP 200.

Precisamos saber se o sistema alcançou o objetivo correto, usando uma sequência de ações aceitável.

Isso muda o significado de observabilidade.

Não estamos apenas observando infraestrutura. Estamos começando a observar comportamento.

Mas existe uma distinção importante.

Observabilidade ajuda a reconstruir o que aconteceu — idealmente por meio de traces estruturados, decision paths, tool calls, policies e resultados.

Avaliação ajuda a determinar se o comportamento foi adequado.

Um trace pode mostrar que o agente escolheu payment.create, recebeu uma negação de policy e tentou outra estratégia.

Para afirmar que aquela escolha foi correta ou incorreta, precisamos de critérios adicionais: regras determinísticas, ground truth, evaluators, métricas de sucesso ou revisão humana.

As duas capacidades se complementam:

Observability
     |
o que aconteceu?

Evaluation
     |
isso foi adequado?

Em sistemas agentic maduros, provavelmente precisaremos das duas.

Essa telemetria também precisa respeitar fronteiras de privacidade.

Traces e audit logs devem registrar decisões, tool calls, políticas, resultados e artefatos relevantes sem transformar prompts, credenciais, PII ou o raciocínio interno do modelo em logs indiscriminados.

Em ambientes regulados, o objetivo não é persistir tudo o que o modelo “pensou”. É reconstruir com segurança o suficiente para responder perguntas como:

qual objetivo foi recebido?
qual tool foi chamada?
quais parâmetros relevantes foram utilizados?
qual policy permitiu ou bloqueou a ação?
houve aprovação humana?
qual resultado foi produzido?

Isso favorece trilhas estruturadas, redaction de dados sensíveis e, quando necessário, reasoning summaries ou decision artifacts em vez de armazenamento irrestrito de contexto interno.

Talvez este seja apenas o primeiro estágio

Até aqui estamos falando de agentes usando capacidades que já existem.

Mas existe uma transformação potencialmente maior.

Durante décadas construímos software em torno de comandos.

Software tradicional

Humano
  |
  v
Escolhe funcionalidade
  |
  v
Sistema executa

IA como assistente

Humano
  |
  v
Pergunta
  |
  v
IA recomenda
  |
  v
Humano decide
  |
  v
Sistema executa

IA como agente

Humano
  |
  v
Define objetivo
  |
  v
IA interpreta
  |
  v
IA planeja
  |
  v
IA escolhe ações
  |
  v
Sistema executa
  |
  v
Humano supervisiona

A mudança pode ser resumida em uma frase:

Estamos passando de sistemas que recebem comandos para sistemas que recebem objetivos.

Isso é muito maior do que trocar uma tela por uma interface conversacional.

O banco talvez deixe de ser um destino

Hoje um aplicativo bancário costuma funcionar como um mapa das capacidades do banco:

App
 |
 |-- Pix
 |-- Cartões
 |-- Investimentos
 |-- Crédito
 |-- Seguros
 |-- Conta

O usuário precisa aprender essa estrutura.

Se quer pagar alguém, procura Pix.

Se quer investir, procura Investimentos.

Se quer alterar um limite, procura Cartões.

Mas imagine outra interação:

“Quero guardar dinheiro suficiente para viajar em dezembro sem correr risco de faltar dinheiro para minhas contas.”

Um sistema tradicional oferece ferramentas:

saldo
extrato
fatura
investimentos
orçamento

O usuário faz a composição.

Um sistema orientado por objetivos poderia tentar decompor o problema:

Objetivo: viajar em dezembro
        |
        v
     Contexto
        |
        +--> Renda
        +--> Despesas
        +--> Faturas
        +--> Compromissos futuros
        |
        v
     Planner
        |
        +--> Definir reserva mensal
        +--> Simular cenários
        +--> Alertar riscos
        +--> Acompanhar progresso
                |
                v
     Policies / Authorization
                |
                v
     Financial Capabilities

Esse é um cenário de futuro, não uma descrição do banco atual.

Mas ele ajuda a revelar uma possível mudança arquitetural.

O banco deixa de ser apenas uma coleção de telas que expõem produtos.

Pode começar a se tornar uma coleção de capacidades financeiras componíveis, acessadas no contexto em que são necessárias.

Essa direção também conversa com outro tema presente na programação do Febraban Tech: finanças embarcadas e convergência intersetorial.

Talvez o banco do futuro seja menos um lugar para onde o cliente vai e mais uma infraestrutura financeira presente em outras experiências.

Inteligência como capacidade elástica

Uma forma interessante de pensar nessa transformação é comparar IA com aquilo que cloud fez pela infraestrutura.

Cloud nos acostumou a tratar recursos como capacidades elásticas:

compute
storage
network

Se a demanda aumenta, podemos provisionar mais capacidade.

Com modelos generativos, começamos a consumir também:

interpretação
classificação
geração
planejamento
raciocínio
uso de ferramentas

É como se uma nova capacidade começasse a entrar na arquitetura:

compute
storage
network
intelligence

Em uma conversa recente sobre o futuro da IA no setor financeiro, Carlos Mazzei descreve a inteligência como uma capacidade cada vez mais escalável, quase “líquida”, aplicável a diferentes processos e negócios.

Levando essa ideia para a arquitetura, podemos fazer uma analogia com a elasticidade que cloud trouxe para infraestrutura.

“Inteligência elástica” aqui não é um conceito formal atribuído à entrevista, mas uma analogia arquitetural: se cloud tornou compute disponível sob demanda, modelos generativos começam a tornar certas capacidades de interpretação, planejamento e decisão também consumíveis sob demanda.

Mas existe uma diferença essencial.

CPU não decide espontaneamente qual API deve chamar.

Uma camada de inteligência pode.

Portanto:

elastic compute
       →
elastic intelligence

Infraestrutura elástica aumenta capacidade de processamento.

Inteligência elástica pode aumentar capacidade de decisão.

E capacidade de decisão introduz:

authorization
governance
auditability
risk
blast radius

Cloud nos ensinou a projetar sistemas para quando infraestrutura escala.

Talvez a próxima etapa seja aprender a projetar sistemas para quando decisão escala.

APIs ganham um novo tipo de consumidor

Historicamente, muitas APIs corporativas foram desenhadas pensando em consumidores relativamente previsíveis.

Primeiro:

Frontend
   |
   v
API

Depois:

Mobile  --+
Web       +--> BFF --> Services
Partner --+

Agora aparece uma nova classe:

Human UI      --+
Agent           +--> Capabilities / APIs
Other Agents  --+

Isso cria perguntas novas para APIs existentes:

• quais operações um agente pode descobrir?
• quais ferramentas pode chamar?
• quais parâmetros pode escolher autonomamente?
• qual identidade chega ao serviço de domínio?
• quais ações exigem confirmação?
• como impedir loops?
• como controlar frequência de tool calls?
• como garantir idempotência?
• como reconstruir posteriormente o decision path sem registrar dados sensíveis ou raciocínio interno de forma indiscriminada?

Talvez uma API segura para um frontend não seja automaticamente uma API segura para um agente.

E isso pode levar a outra mudança importante.

Em vez de conectar agentes diretamente a dezenas de serviços internos, podemos criar uma capability layer ou tool gateway que exponha capacidades mais restritas e explicitamente governadas.

Compare:

execute_sql(query)

com:

get_customer_balance(customer_id)

A primeira ferramenta oferece liberdade enorme.

A segunda oferece uma capacidade delimitada.

Menos flexibilidade pode significar menor blast radius.

Como eu abordaria

Eu evitaria conectar diretamente o LLM às APIs de domínio.

Pensaria em algo parecido com:

User
  |
  v
Agent
  |
  v
Planner
  |
  v
Policy / Authorization
  |
  +-- deny --------------------------> Blocked
  |
  +-- require approval ---> Human Approval --+
  |                                          |
  +-- allow --------------------------------+
                                              |
                                              v
                          Schema / Parameter Validation
                                              |
                                              v
                                        Tool Gateway
                                              |
                    +----------+----------+----------+
                    v          v          v          v
                 Payments  Customer  Investments   Credit

(Policy/Authorization, Validation e Tool Gateway também
 alimentam Audit Trail e Decision/Agent Tracing em paralelo
 — omitido acima por limitação da representação em texto)

Não como arquitetura universal.

Cada domínio terá riscos diferentes.

Mas alguns princípios me parecem cada vez mais importantes:

1. Separar raciocínio de autorização.
2. Separar identidade humana de identidade do agente.
3. Propagar contexto do usuário sem entregar automaticamente todas as permissões ao agente.
4. Diferenciar leitura de operações mutáveis.
5. Exigir idempotência em ações com efeito colateral.
6. Aplicar rate limiting e limites de execução.
7. Criar trilha de auditoria da intenção até o efeito produzido.
8. Usar human-in-the-loop de acordo com risco.
9. Medir resultado de negócio, não apenas resposta do modelo.
10. Projetar explicitamente o blast radius de cada agente.
11. Validar parâmetros das tools contra schemas e políticas antes da execução e validar ou sanitizar suas respostas antes de retorná-las ao agente.
12. Tratar observabilidade e avaliação como capacidades complementares: uma reconstrói o comportamento; a outra mede se ele foi adequado.

Os trade-offs não desaparecem

Agentes não criam uma arquitetura magicamente melhor.

Criam novas decisões.

Autonomia × controle

Quanto mais passos o agente executa sozinho, mais fluida tende a ser a experiência.

Mas maior pode ser o impacto de uma decisão incorreta.

Aprovação × fricção

Mais checkpoints podem reduzir risco.

Mas também podem destruir o ganho operacional.

Contexto × exposição

Agentes melhores precisam de contexto.

Contexto significa dados, permissões e novas fronteiras de confiança.

Ferramentas genéricas × específicas

Ferramentas genéricas aumentam flexibilidade.

Ferramentas específicas reduzem o espaço de ações possíveis.

Velocidade × flexibilidade arquitetural

Ainda não sabemos qual será a interface dominante para agentes em 2030.

Pode ser conversacional.

Pode ser multimodal.

Pode estar embutida em outros produtos.

Pode se tornar quase invisível.

Por isso, talvez um dos maiores erros seja acoplar o domínio à interface agentic que está na moda hoje.

As interfaces vão mudar.

As capacidades de negócio precisam sobreviver a elas.

O que esse caso ensina sobre construir software?

A discussão do Febraban Tech é sobre agentes inteligentes.

Mas os problemas por trás dela são profundamente familiares para quem constrói sistemas distribuídos.

Quando software começa a decidir quais ações executar, voltamos a falar de:

• contratos;
• identidade;
• autorização;
• least privilege;
• idempotência;
• retries;
• observabilidade;
• auditoria;
• rate limiting;
• isolamento;
• resiliência;
• blast radius.

A novidade não elimina os fundamentos.

Ela aumenta a importância deles.

Durante anos construímos sistemas para executar comandos.

Agora começamos a construir sistemas capazes de decidir quais comandos executar.

Essa diferença muda bastante coisa.

Conclusão

O Febraban Tech 2026 coloca agentes inteligentes no centro da discussão em um momento em que a indústria começa a pensar menos em experimentos isolados e mais em aplicações com escala, confiança e valor.

É tentador enxergar essa mudança apenas como uma nova geração de interfaces.

Chatbots melhores.

Assistentes melhores.

Modelos melhores.

Mas existe uma transformação arquitetural mais profunda.

Quando software deixa de apenas responder e passa a interpretar objetivos, selecionar ferramentas e produzir efeitos no mundo, precisamos reconsiderar identidade, autorização delegada, validação de parâmetros, políticas, auditoria, observabilidade, avaliação, retries e limites de autonomia.

Cloud nos ensinou a projetar sistemas para infraestrutura elástica.

A próxima etapa pode exigir que aprendamos a projetar sistemas para inteligência elástica.

Só que inteligência não apenas processa.

Ela interpreta.

Pode decidir.

E pode agir.

Por isso, talvez a principal pergunta da era dos agentes não seja:

“Até onde a IA consegue ir?”

Mas:

“Até onde nossa arquitetura está preparada para deixá-la ir?”

Fontes

1. Febraban — Presidentes dos maiores bancos debatem no Febraban Tech 2026 o impacto dos agentes inteligentes, 13 ago. 2026.
2. Febraban — Febraban Tech começa na segunda com Galípolo, líderes dos maiores bancos do país e Prêmio Nobel, 21 ago. 2026.
3. McKinsey Talks — “Como a AI está redesenhando os bancos, com o diretor de tecnologia do Itaú” — Carlos Mazzei e Yran Dias, 12 ago. 2026. Referência para a ideia de inteligência escalável e “quase como uma capacidade líquida”, além das discussões sobre agentes, arquitetura flexível e o cenário de serviços financeiros em 2030. A expressão “inteligência elástica” é usada neste artigo como analogia arquitetural do autor.
4. AWS Well-Architected — Agentic AI Lens: Secure agent tool usage.
5. AWS Well-Architected — Implement tool authorization — referência para autorização externa ao raciocínio do agente, propagação de identidade, least privilege, rate limiting e aprovação de operações mutáveis.
6. AWS Well-Architected — Agent identity and permission management.
7. AWS Well-Architected — Separate agent and human user permission.
8. AWS Well-Architected — Human-in-the-loop for critical decisions — referência para aprovação proporcional ao risco e para os anti-patterns de revisar tudo ou não revisar nada.
9. AWS Well-Architected — Validate tool inputs and outputs — referência para validação de inputs e parâmetros antes da execução e para validação/sanitização dos outputs antes de retorná-los ao agente.
10. AWS Well-Architected — Implement idempotent task execution patterns — referência para retries, efeitos colaterais e prevenção de execuções duplicadas.
11. AWS Well-Architected — Observability and monitoring for agentic systems — referência para tracing de reasoning, tool calls, workflows e comportamento de agentes.
12. OWASP — AI Agent Security Cheat Sheet — referência vendor-neutral para least privilege, autorização explícita, schema validation, human-in-the-loop, limites de tool chains e proteção contra excessive autonomy.
13. NIST NCCoE — Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization — concept paper de 2026 sobre identidade e autorização de software agents e AI agents. Não é um padrão final, mas reforça que o problema ultrapassa implementações específicas de um fornecedor.
14. AWS Prescriptive Guidance — Operationalizing agentic AI on AWS — referência complementar para governança, telemetria, traces e decision trails.