Agentes de remediação da Tamnoon nunca carregam credencial. A decisão de design que vale copiar

O agente mais seguro para mudar infraestrutura de produção é aquele que não consegue mudá-la. Parece contradição até você separar o decidir do fazer, que é exatamente o que o design da Tamnoon faz.

A AWS publicou a arquitetura da Tamnoon em 14 de outubro. A Tamnoon vende remediação de segurança de nuvem: pega os findings das ferramentas de segurança de nuvem e corrige as configurações erradas por trás deles. O sistema de IA dela, que chama os modelos Claude da Anthropic no Amazon Bedrock, investiga cada finding, decide se a correção é segura e escreve a remediação. Segundo o post, “a IA nunca carrega credenciais de nuvem”. A execução roda em um ambiente separado e isolado, com credenciais de curta duração e escopo por tenant, sob uma confiança que o cliente controla.

Quatro agentes, um gate após o outro

O trabalho é dividido entre quatro agentes especializados, e cada etapa restringe o que a próxima pode fazer.

1. Investigar: plano somente leitura, checado por um juiz
2. Pontuar segurança: SAFE, RISKY ou AWAITING DATA
3. Planejar: backup, remediar, verificar, rollback
4. Gerar código, e um revisor separado aprova
5. Executar em isolamento com acesso de curta duração

Raciocínio do modelo, sem credenciais de nuvemExecução, confiança controlada pelo cliente

Investigação reúne contexto e produz um plano validado como estritamente somente leitura, checado por uma camada de LLM-as-a-judge. Pontuação de segurança monta uma cadeia de evidências por ativo e classifica cada finding como SAFE, RISKY ou AWAITING DATA; o post descreve essa etapa como deliberadamente conservadora, rebaixando a classificação quando tem dúvida. Planejamento roda só nos findings classificados como seguros, e cada passo segue backup, remediar e verificar, com orientação de rollback. Geração de código transforma os passos do plano em remediação executável depois que um guardrail de entrada filtra relevância e prompt injection, e um agente revisor separado precisa aprovar cada artefato.

Três escolhas que sustentam o design

A credencial fica onde o modelo não está. Se um atacante manipular o agente de investigação por meio de uma tag de recurso envenenada ou de uma linha de log forjada, o pior resultado é um plano ruim, que os próximos gates conseguem pegar. Não é um bucket deletado. É o padrão que vemos se repetir em implantações sérias: o agente de rede da Microsoft nunca carrega a credencial de execução, e a pesquisa da Zenity sobre o AgentCore mostrou o que acontece no caso contrário: o papel de nuvem do agente decide o estrago.

“Não sei” é uma resposta válida. AWAITING DATA é um desfecho de primeira classe. A maioria dos designs de agente força um veredito; este deixa a etapa de segurança se recusar a decidir, e encaminha os findings RISKY e AWAITING DATA para os engenheiros de nuvem da Tamnoon. As ações SAFE podem executar automaticamente por um workflow de aprovação com trilha de auditoria completa.

Toda mudança carrega o próprio desfazer. Backup e rollback fazem parte do formato do plano, não são um detalhe esquecido em um runbook.

As versões de modelo são fixadas a identificadores com data, o que também torna o sistema testável quando um fornecedor aposenta um modelo.

Leia os resultados junto com a fonte

A Tamnoon relata uma redução de mais de 90% na exposição crítica de nuvem em 90 days, “sem nenhum problema em produção”. A própria tabela de resultados do post diz “até 90%”, e outros números dele vêm de pesquisa da Tamnoon. São resultados relatados pelo fornecedor, não uma auditoria, e dependem da configuração e das definições de aprovação de cada cliente.

O que perguntar a qualquer agente de remediação

Se você compra um serviço assim ou constrói o seu, a arquitetura entrega as perguntas:

1. Qual componente carrega as credenciais de produção, e existe algum modelo dentro dele?
2. A etapa de segurança consegue dizer “não há dados suficientes”, e o que acontece depois?
3. Quem decide quais classes de finding executam sem uma pessoa, e onde isso está escrito?
4. Toda mudança vem acompanhada do próprio backup, verificação e rollback?
5. O revisor que aprova o código gerado é independente do que o escreveu?

Um fornecedor que responde à primeira pergunta com “o agente tem um papel de menor privilégio” não separou o decidir do fazer. Só fez o fazer ficar menor.