Foi o agente’ não pode ser a nova desculpa corporativa

Em uma conversa recente com um colega, auditor de sistemas, discutimos uma preocupação que tenho visto crescer nas empresas: a adoção de agentes de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → está avançando mais rapidamente do que os mecanismos para controlá-los.

A conversa me chamou atenção porque boa parte das discussões sobre agentes ainda se concentra no que eles conseguem fazer. Mas, para auditoria, a perspectiva é outra: qual identidade executou a ação, com que autoridade, sobre quais dados, usando quais ferramentas e como reconstruir posteriormente o que aconteceu.

Essa distinção se torna importante quando passamos de sistemas que apenas geram respostas para sistemas conectados a ferramentas capazes de consultar sistemas corporativos, alterar dados, chamar APIs, enviar mensagens, executar código ou iniciar transações.

Nesse momento, IA deixa de ser apenas uma questão de qualidade da resposta. Passa também a ser uma questão de autoridade para agir. O próprio NIST colocou identidade e autorização de agentes de software em sua agenda de 2026, discutindo identificação, autenticação, delegação de autoridade, mínimo privilégio, auditoria, não repúdio e mecanismos para vincular ações de agentes à autorização humana.

Um dos primeiros problemas que discutimos foi identidade. Se vários agentes utilizam a mesma conta técnica ou uma credencial genérica, o registro pode mostrar qual conta executou uma operação, mas não necessariamente qual agente atuou, em nome de quem, sob qual objetivo e com qual delegação.

Por isso, considero cada vez mais importante tratar agentes como identidades de máquina governáveis, com identidade distinguível, credenciais adequadamente gerenciadas, permissões limitadas e contexto de delegação quando estiverem operando em nome de alguém.

O segundo problema é privilégio excessivo. Um agente precisa consultar pedidos, mas recebe uma ferramenta que também permite alterá-los. Outro deveria preparar um pagamento, mas possui credenciais capazes de executá-lo.

A OWASP chama esse problema de Excessive Agency: funcionalidade, permissões ou autonomia excessivas podem transformar uma saída inadequada ou manipulada do modelo em uma ação real sobre sistemas corporativos.

A solução começa por um velho princípio de segurança: mínimo privilégio. Mas agora ele precisa chegar também às ferramentas utilizadas pelo agente. Capacidade de propor uma ação não significa autoridade para executá-la.

Outro ponto que consideramos crítico é a trilha de auditoria. Registrar apenas a entrada enviada ao modelo e sua resposta final é insuficiente em sistemas agênticos. Precisamos conseguir reconstruir a execução: identidade, objetivo, contexto relevante, ferramentas acionadas, ações solicitadas, políticas aplicadas, decisões de autorização, aprovações humanas, resultados e falhas.

A própria OWASP recomenda registrar e monitorar atividades de ferramentas e sistemas de destino e, para agentes, validar chamadas de ferramentas contra permissões e contexto da sessão.

Há ainda o problema de prompt injection indireto. Um agente pode processar um e-mail, documento ou página contendo instruções maliciosas e tratá-las como parte de sua tarefa. Se tiver ferramentas e privilégios excessivos, uma manipulação do modelo pode ultrapassar a geração de uma resposta errada e produzir consequências sobre dados ou sistemas.

Por isso, nunca me pareceu suficiente tentar resolver esse problema apenas com um prompt mais elaborado.

A autorização precisa existir fora do modelo, nos sistemas e ferramentas que efetivamente executam as ações. A OWASP recomenda explicitamente que sistemas de destino validem as requisições segundo suas políticas, em vez de confiar no próprio LLM para decidir se uma ação é permitida.

Finalmente existe a responsabilidade. “Foi o agente” não pode se tornar a versão moderna de “foi o sistema”. Todo agente em produção deve ter proprietário, finalidade definida, ferramentas e dados autorizados, classificação de risco, limites de autonomia e critérios de escalonamento humano.

Saí daquela conversa ainda mais convencido de que auditoria de agentes não pode ser algo acrescentado depois que eles entram em produção. Identidade, mínimo privilégio, segregação de funções, autorização independente, observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps →, trilhas de auditoria, supervisão humana proporcional ao risco, reversibilidade e mecanismos de interrupção precisam fazer parte da arquitetura.

Agentes não tornam obsoletos os princípios tradicionais de controle interno. Fazem exatamente o contrário. Transformam esses princípios em parte da arquitetura da IA. Quando software deixa apenas de recomendar e passa a executar ações, auditar somente o resultado já não basta.

Precisamos auditar não apenas o que o agente fez, mas por que estava autorizado a fazer, em nome de quem agiu e se conseguimos reconstruir toda a cadeia que transformou uma saída probabilística do modelo em uma ação real.