Confiança em Profundidade: como dar mais autonomia a agentes de IA sem perder o controle

O dilema central dos agentes de IA em produção

Líderes de tecnologia em grandes empresas compartilham uma mesma tensão: querem que os agentes de Inteligência Artificial (IA) façam mais, mas não confiam que eles façam certo o tempo todo. E essa desconfiança é legítima. A mesma criatividade e autonomia que tornam os agentes úteis é o que os torna difíceis de controlar. Você entrega uma tarefa, e o agente encontra seu próprio caminho para concluí-la — escolhendo ferramentas e encadeando etapas que nenhum desenvolvedor programou explicitamente. Execute a mesma tarefa duas vezes e ele pode percorrer rotas diferentes. Um teste que passa hoje diz pouco sobre o que o agente fará amanhã.

A resposta mais comum ainda é colocar uma pessoa no meio do processo, aprovando cada ação. Isso funciona em pequena escala, mas à medida que os agentes assumem mais trabalho, as aprovações humanas se acumulam e a fadiga de revisão se instala. Quem é solicitado a checar tudo acaba deixando passar o que realmente importa. A cautela vira gargalo, e agentes capazes de muito ficam parados exatamente nas tarefas de maior impacto.

A solução proposta pela AWS é deixar o agente agir por conta própria quando suas ações podem ser verificadas, e reservar o julgamento humano para as decisões que realmente precisam dele.

O que é Trust in Depth

A AWS apresentou o conceito de Trust in Depth (Confiança em Profundidade) como resposta a esse desafio. A ideia se inspira no princípio de “Defense in Depth” (Defesa em Profundidade), que a indústria pratica há duas décadas para limitar o que pode dar errado em sistemas conectados. O Trust in Depth inverte o propósito: em vez de apenas restringir, ele expande o que você pode permitir com segurança.

A confiança é construída respondendo a quatro perguntas em momentos distintos do ciclo de vida do agente:

• Escopo (antes de executar): Para que serve esse agente? Quais capacidades o trabalho exige? O que ele nunca pode fazer?
• Identidade (no momento do deploy): Quem o autorizou? Qual identidade ele carrega? É possível rastrear cada agente que age em seu nome?
• Limites (durante a execução): As ações ficam dentro do que foi definido? O agente ainda consegue concluir o trabalho?
• Observabilidade (após cada execução): É possível reconstruir o que o agente fez e por quê? É possível aprender com isso?

Algumas dessas perguntas podem ser respondidas com regras precisas; outras dependem de contexto e julgamento humano. “Somente um gerente pode aprovar acesso” pode ser verificada matematicamente. “Manter um tom amigável” não pode. Para as regras precisas, a AWS aposta no raciocínio automatizado — lógica matemática que verifica se uma regra se sustenta em todos os casos possíveis, não apenas nos que você antecipou nos testes.

A AWS aplica raciocínio automatizado em produção há mais de uma década, do Gerenciamento de Identidade e Acesso (IAM) processando mais de 2,1 bilhões de requisições por segundo a sistemas críticos como o AWS Nitro Hypervisor, o Amazon S3 Block Public Access e o VPC Reachability Analyzer. Agora essa tecnologia está sendo trazida para o universo dos agentes.

Camada 1 — Escopo: defina o que o agente pode e não pode fazer

A confiança começa antes de o agente executar qualquer coisa, e é aqui que vale investir mais esforço. Problemas identificados nessa fase são baratos de corrigir. Definir o escopo significa decidir qual trabalho o agente possui, quais ferramentas, dados e serviços ele pode acessar, as regras que deve seguir e quais decisões permanecem com uma pessoa.

“Resolva o problema do cliente” diz o que alcançar, não como o agente pode agir para chegar lá. O agente ainda precisa de limites sobre o que pode ver, o que pode fazer e quando deve parar e perguntar. Dê a ele apenas o acesso que o trabalho exige — e nada além. Fique atento a permissões que ninguém concedeu intencionalmente, as que vêm embutidas em uma ferramenta ou papel. Conceda um papel de administrador para uma tarefa e o agente pode herdar permissões em todo o ambiente.

O Kiro, o sistema de codificação agêntica da AWS, traz rigor e práticas maduras de engenharia para a fase de construção. Ele transforma intenções de alto nível em requisitos estruturados e orientados por especificações, usando raciocínio automatizado para identificar contradições, ambiguidades e lacunas antes que qualquer código seja escrito. O Kiro também deriva testes baseados em propriedades que verificam a implementação contra esses requisitos em uma ampla gama de entradas, capturando bugs difíceis de detectar.

O Strands oferece um kit de ferramentas de código aberto para definir o modelo, as instruções e as ferramentas de um agente, além de um ambiente de execução gerenciado. Independentemente do framework escolhido, a responsabilidade de definir o trabalho do agente e seus limites permanece a mesma.

O próximo passo é transformar esses limites em regras que possam ser aplicadas. O Amazon Bedrock AgentCore oferece controles de governança para escalar agentes com segurança. Usando Políticas no Bedrock AgentCore, você descreve em linguagem simples quais ferramentas, APIs e dados o agente pode acessar — e o raciocínio automatizado verifica a política em busca de lacunas e contradições antes que ela entre em vigor.

Camada 2 — Identidade: saiba quem está agindo em seu nome

Não é possível governar o que não se enxerga. Equipes estão criando agentes mais rápido do que qualquer um consegue rastrear, e um agente que ninguém conhece é um agente que ninguém controla. Cada agente precisa de sua própria identidade, verificada a cada ação que realiza. Nenhuma ação deve ficar sem rastreamento. Quando algo dá errado, deve ser possível identificar qual agente fez o quê, e quem o autorizou.

O AWS Agent Registry fornece um catálogo gerenciado e aprovado dos agentes, servidores do Protocolo de Contexto de Modelo (MCP), ferramentas e habilidades em toda a organização. Administradores usam fluxos de aprovação para controlar o que se torna descobrível e remover o que não atende mais aos critérios de segurança, conformidade e qualidade. Tanto pessoas quanto agentes podem encontrar e reutilizar o que já existe, em vez de reconstruir do zero.

Mas um catálogo apenas mostra o que existe. Uma vez que os agentes são conhecidos, o AgentCore emite a cada um sua própria identidade e a verifica em cada requisição — assim, toda ação remonta a um agente específico operando sob uma autoridade conhecida.

Camada 3 — Limites: controle o que o agente diz e faz durante a execução

Definir limites importa porque um agente pode executar dez passos que você aprovou e ainda assim chegar a um resultado que ninguém pretendia. Ele pode expor dados sensíveis, sair do assunto ou combinar ações permitidas de formas que suas políticas proíbem.

Os limites podem falhar nas duas direções: frouxos demais, e o agente faz o que não deveria; apertados demais, e ele não consegue concluir o trabalho. Por isso, deixe o agente escolher como perseguir sua tarefa, mas nunca confie nele para aplicar seus próprios limites. Esses limites pertencem ao ambiente ao redor do agente, aplicados de forma determinística e avaliados ao longo de toda a sequência de ações — não passo a passo.

É aqui que a política definida na fase de Escopo entra em vigor. A Política no AgentCore a aplica em cada chamada de ferramenta roteada pelo AgentCore Gateway, um ponto de entrada seguro para agentes, ferramentas e modelos. Como a aplicação fica fora do raciocínio do agente, as mesmas verificações se mantêm mesmo quando o agente tem bugs, é manipulado ou sofre uma injeção de prompt — ele não pode desativar um controle que não executa.

A autoridade também não precisa ser fixa. Como o risco de uma tarefa muda à medida que ela avança, as políticas temporais consideram o que já aconteceu na sessão e ajustam as permissões conforme o trabalho continua.

O Amazon Bedrock Guardrails governa o que o agente diz e recebe. Ele filtra conteúdo prejudicial ou fora do tópico e redige dados sensíveis. As verificações de Raciocínio Automatizado vão além, provando que uma resposta é consistente com a política definida — não com a interpretação do modelo sobre ela.

Os limites também governam o que um agente pode acessar: quais arquivos pode tocar, quais serviços pode chamar e quais credenciais pode usar. O Strands Box, um sandbox de código aberto, aplica esses limites de fora das instruções do agente, para que ele possa trabalhar com ferramentas e dados reais, mas acessar apenas o que você permite. Os mesmos limites valem desde a primeira sessão local do desenvolvedor até a produção.

Camada 4 — Observabilidade: reconstrua o que aconteceu e melhore

Mesmo com escopo, identidade e limites definidos, um agente pode responder em milissegundos, sem erros e com todos os dashboards no verde — e ainda assim fazer a coisa errada. Ele pode ter recuperado a informação errada, escolhido a ferramenta errada ou seguido um caminho que ninguém esperava. Um sistema saudável não é o mesmo que uma tarefa bem-sucedida.

Para fazer essa distinção, é preciso reconstruir o que o agente realmente fez: o contexto que recebeu, as ferramentas que chamou, as decisões de política aplicadas e o resultado. Testes antes do deploy continuam essenciais. A produção adiciona evidências sobre o comportamento em condições reais e dá às equipes o que precisam para investigar, intervir e melhorar.

O Amazon CloudWatch Omni foi construído para observação contínua. Ele captura cada rastreamento e exibe cada passo que um agente deu — de chamadas de modelo a invocações de ferramentas — em uma linha do tempo que a equipe pode investigar. Seus avaliadores integrados pontuam as respostas do agente em qualidades que o monitoramento padrão não detecta, como correção, fidelidade e se o agente escolheu a ferramenta certa. E os rastreamentos em que o agente errou se tornam o conjunto de dados para testar a correção, unindo operação e melhoria contínua na mesma evidência.

Trust in Depth na prática: o caso do desligamento de um colaborador

Um gerente pede a um agente de help desk que realize o offboarding de Sam, um gerente de contas que está saindo da empresa. O agente precisa remover o acesso de Sam, transferir sua caixa de e-mail para seu sucessor e liberar a licença que a empresa não precisa mais. Mas os e-mails de Sam podem conter evidências necessárias para uma disputa com um cliente. A sequência errada poderia deixar Sam com acesso após a saída ou colocar essas evidências em risco.

Duas regras governam a sequência: o login de Sam deve ser bloqueado antes que sua caixa de e-mail possa ser convertida e compartilhada com o sucessor; e antes de alterar a licença de e-mail, o agente deve verificar se há uma retenção legal — uma exigência de preservar registros para uma disputa — e confirmar que a alteração mantém esses registros protegidos.

Escopo: antes de o agente executar, a equipe escreve essas regras como políticas no AgentCore. O agente recebe exatamente seis ferramentas: bloquear login, verificar retenções legais, aplicar uma retenção, converter caixa de e-mail, conceder acesso ao sucessor e alterar uma licença. Ele não recebe ferramenta para excluir a conta, porque a caixa de e-mail compartilhada precisa que a conta sobreviva.

Identidade: o agente carrega sua própria identidade, então cada alteração na conta de Sam é rastreável.

Limites: o agente tenta converter a caixa de e-mail de Sam para uma compartilhada para Priya, a sucessora. A política no AgentCore, aplicada no AgentCore Gateway, bloqueia a chamada: Sam ainda consegue fazer login, e converter a caixa não mudaria sua senha, então suas credenciais antigas ainda a abririam. O agente bloqueia o login de Sam, depois converte a caixa e dá acesso a Priya. Em seguida, passa para o pedido real do gerente — liberar a licença — mas o gateway bloqueia novamente, porque ninguém verificou a lista de retenções do Jurídico. O agente verifica e descobre que o Jurídico exige que os e-mails de Sam sejam preservados para uma disputa. Ele aplica a retenção, confirma que está em vigor e então altera a licença de Sam para uma que suporte essa proteção. A empresa pode recuperar a licença mais ampla mantendo as evidências intactas.

Observabilidade: cada passo é registrado — o que o agente tentou fazer, o que as regras decidiram, a retenção e o resultado. O agente concluiu a tarefa sem que uma pessoa aprovasse cada etapa.

O que se torna possível quando agentes são confiáveis

Nenhuma camada isolada constrói confiança por si só. Juntas — escopo, identidade, limites e observabilidade, com raciocínio automatizado onde as regras podem ser expressas com precisão — elas formam o Trust in Depth e transformam um agente capaz em um agente confiável para trabalhos importantes.

Você define as linhas: o que um agente pode fazer por conta própria, o que precisa de aprovação humana e quando ele deve parar. Isso libera as pessoas para o que só pessoas podem fazer: pesar as decisões difíceis, resolver as áreas cinzentas e assumir responsabilidade pelas escolhas que você decide manter em mãos humanas. À medida que as evidências se acumulam de que um agente fica dentro dessas linhas, você pode ampliar suas responsabilidades — ou reduzi-las.

A AWS defende que toda organização que implanta agentes, em qualquer plataforma, deveria ser capaz de responder a essas quatro perguntas com evidências — e com provas matemáticas onde for aplicável. Para começar a implementar regras aplicáveis, a AWS recomenda explorar a Política no Amazon Bedrock AgentCore e as verificações de Raciocínio Automatizado no Amazon Bedrock Guardrails.

Fonte

Trust in Depth: Giving agents more autonomy without losing control (https://aws.amazon.com/blogs/machine-learning/trust-in-depth-giving-agents-more-autonomy-without-losing-control/)