A segurança de agentes de IA tornou-se um problema diferente daquele enfrentado pelos primeiros assistentes generativos. Um chatbot tradicional recebia uma pergunta e produzia uma resposta. Os agentes atuais podem consultar e-mails, abrir arquivos, pesquisar sistemas internos, executar código, atualizar registros, acionar ferramentas e dar continuidade a tarefas sem que uma pessoa aprove cada etapa.
A mudança amplia a utilidade da inteligência artificial, mas desloca o risco para uma camada que muitas empresas ainda administram como se estivessem implantando apenas mais um aplicativo. Para executar trabalho real, o agente recebe permissões. Quando essas permissões são amplas, permanentes ou herdadas de uma conta humana, uma interpretação incorreta deixa de produzir somente uma resposta ruim e passa a gerar consequências nos sistemas conectados.
Em 17 de fevereiro de 2026, o NIST lançou a AI Agent Standards Initiative, reconhecendo que autenticação, identidade, autorização e comunicação entre agentes precisavam de pesquisa e padrões próprios. O órgão observou que agentes já conseguiam trabalhar autonomamente por horas, escrever e depurar código, administrar e-mails e calendários e realizar compras. A utilidade dependia justamente da capacidade de interagir com dados e sistemas externos — a mesma característica que ampliava a superfície de ataque.
O problema central não é a possibilidade abstrata de uma IA “se rebelar”. O risco mais imediato está em um agente obediente, operando com credenciais válidas, interpretar uma instrução manipulada e realizar uma ação que jamais deveria ter sido autorizada naquele contexto.
O salto do texto para a ação rompeu os limites dos controles usados nos chatbots
A segurança de aplicações generativas começou concentrada no conteúdo. Equipes avaliavam vazamento de informações, respostas ofensivas, alucinações, exposição do prompt de sistema e entrada de instruções maliciosas. Esses riscos continuam relevantes, mas já não descrevem todo o impacto de uma aplicação agêntica.
Um agente não termina o trabalho quando produz texto. Depois de interpretar a solicitação, pode escolher uma ferramenta, recuperar documentos, consultar uma API, modificar um banco de dados e enviar o resultado para outra pessoa. Uma falha em qualquer ponto pode ser propagada pelas etapas seguintes sem uma nova intervenção humana.
A Microsoft descreve essa transição como a sobreposição de riscos de aplicação, identidade e dados em um único modelo operacional. Um sistema pode estar funcionando conforme foi configurado e, ainda assim, realizar algo que uma pessoa não aprovaria, porque os limites eram imprecisos, as ferramentas possuíam alcance excessivo ou a credencial permitia ações além da finalidade original.
O OWASP Top 10 for Agentic Applications, publicado em dezembro de 2025 para orientar implantações em 2026, colocou entre os principais riscos o desvio do objetivo do agente, o uso indevido de ferramentas, o abuso de identidade e privilégios, a execução inesperada de código e as falhas que se propagam entre vários agentes. O framework foi desenvolvido com a participação de mais de cem especialistas, pesquisadores e profissionais da indústria.
A diferença operacional é significativa. Quando um chatbot interpreta de maneira errada um e-mail, o usuário pode corrigir o resumo. Quando um agente interpreta o mesmo conteúdo como uma ordem, utiliza uma integração autorizada e altera registros, a correção depende de logs, reversão, contenção e compreensão da cadeia completa de ações.
A credencial válida pode esconder uma decisão que nunca foi autorizada
Sistemas corporativos tradicionais foram projetados para identificar pessoas, dispositivos, aplicativos e contas de serviço. A identidade responde quem realizou a ação. Com agentes, essa resposta tornou-se insuficiente.
Um funcionário pode solicitar uma tarefa. O agente interpreta o pedido, utiliza uma identidade própria ou um token delegado, chama uma ferramenta intermediária e modifica um recurso. O sistema de destino registra a credencial utilizada, mas pode não preservar quem iniciou o processo, qual era a finalidade original e até onde a autorização deveria alcançar.
Essa lacuna cria uma forma de “lavagem de autorização”. Uma pessoa sem acesso direto a um repositório pode solicitar a um agente compartilhado que consulte esse conteúdo. Se o agente possuir a permissão, a operação poderá ser aceita pelo sistema de destino mesmo que o solicitante não pudesse executar a mesma ação sozinho. A identidade do agente demonstra quem realizou a consulta, mas não prova que a pessoa responsável pelo pedido tinha autoridade para receber o resultado.
A Microsoft passou a tratar agentes como identidades próprias no Entra. Cada identidade pode possuir identificador, patrocinador humano, permissões e vínculo com um modelo de identidade. O token também pode distinguir o usuário representado do agente que está atuando. Esse desenho melhora a rastreabilidade e permite aplicar controles de acesso, revogar concessões e identificar um responsável pelo ciclo de vida do agente.
Ter uma identidade separada, porém, resolve apenas uma parte do problema. Continua sendo necessário verificar se o solicitante podia iniciar a ação, se a autorização permanecia válida naquele momento e se o resultado poderia ser exibido ao público que o receberia. Identificar o agente sem preservar o contexto da delegação cria registros tecnicamente corretos e operacionalmente incompletos.
Prompt injection ganhou alcance porque documentos também podem conter ordens
Um agente conectado a e-mails, páginas da internet e documentos precisa interpretar conteúdo externo. O modelo, entretanto, não possui uma separação infalível entre dados destinados à leitura e instruções que deveriam orientar seu comportamento.
Uma ordem maliciosa pode estar escondida em uma página, mensagem, arquivo ou resultado recuperado por uma ferramenta. Se o agente tratar esse conteúdo como comando, o ataque deixa de depender de uma solicitação direta do usuário. Esse mecanismo é conhecido como prompt injection indireta.
O risco cresce quando o mesmo agente reúne acesso a dados privados, capacidade de consumir conteúdo não confiável e possibilidade de enviar informações para fora da organização. Uma instrução incorporada a um documento pode tentar redirecionar o fluxo, localizar conteúdo sensível e utilizar uma integração legítima para transmiti-lo.
O relatório de incidentes do OWASP referente ao primeiro trimestre de 2026 identificou a passagem de riscos teóricos para exploração real. Os casos reunidos atingiam identidades de agentes, camadas de orquestração e cadeias de fornecimento, enquanto permissões mal configuradas, autonomia excessiva e validação insuficiente contribuíam para vazamento de dados, execução remota e falhas encadeadas.
Essa dinâmica torna insuficiente a confiança baseada apenas na origem aparente do usuário. A solicitação pode ter começado de forma legítima e ser desviada por um conteúdo encontrado durante a execução. O agente passa a agir com permissões válidas sob uma intenção que não pertence mais à pessoa que iniciou a tarefa.
Ferramentas transformaram o agente em uma conta privilegiada capaz de improvisar
Conectores, APIs e protocolos de integração deram aos agentes capacidade prática. Um modelo sem ferramentas pode sugerir uma alteração. Com ferramentas, pode executá-la.
O perigo não está somente em ferramentas evidentemente sensíveis. Um agente com leitura de arquivos, navegação, envio de mensagens e execução de scripts pode combinar recursos comuns de uma maneira que não foi prevista no projeto. A sequência criada durante o raciocínio importa tanto quanto a permissão individual de cada integração.
Conceder acesso a uma ferramenta administrativa porque o agente eventualmente poderá precisar dela repete um erro conhecido em infraestrutura corporativa: transformar conveniência em privilégio permanente. Contas de serviço criadas às pressas frequentemente acumulam acessos porque remover uma permissão pode interromper alguma dependência desconhecida. Com agentes, essa dívida cresce mais rapidamente, pois novas integrações são adicionadas para ampliar autonomia e poucas organizações revisam o conjunto após cada mudança.
A experiência acumulada em ambientes de produção mostra que permissões excessivas raramente surgem de uma única decisão. Elas se formam por adições sucessivas. Um acesso temporário permanece ativo, uma integração de teste chega ao ambiente principal e uma conta compartilhada passa a atender novos processos. O incidente revela a extensão do privilégio apenas quando já existe necessidade de contenção.
O OWASP recomenda restringir cada ferramenta à tarefa necessária, separar operações de leitura e escrita, manter conjuntos distintos conforme o nível de confiança e exigir autorização explícita para ações sensíveis. A organização também deve considerar execução de código, sistema de arquivos, navegação e comunicação externa como capacidades de risco próprio, não como recursos neutros do agente.
O agente compartilhado pode revelar dados permitidos para uma pessoa a toda a equipe
Agentes inseridos em canais, grupos e espaços colaborativos criam um problema que não se limita ao acesso à fonte. Mesmo quando a consulta é autorizada, a resposta pode ser apresentada a pessoas que não deveriam receber aquele conteúdo.
Um agente conectado a um CRM pode produzir uma análise legítima para um supervisor. Se a resposta for publicada em um canal compartilhado, informações comerciais, dados de clientes ou observações internas passam a alcançar todos os participantes. A origem permitiu a consulta, mas o destino não foi validado com o mesmo rigor.
A Cloud Security Alliance analisou esse risco ao discutir agentes com identidade própria em canais de colaboração. O agente pode possuir permissões associadas ao espaço e agir para todos os participantes, criando diferenças entre a capacidade do solicitante, a autoridade da identidade compartilhada e a visibilidade final da resposta. Os registros do sistema conectado também podem mostrar apenas a conta do agente, exigindo correlação com outro log para identificar quem iniciou a operação.
Essa distinção altera a arquitetura de segurança. Autorizar a leitura não deve autorizar automaticamente a publicação. Antes de apresentar o resultado, o sistema precisa considerar o público, a classificação da informação e as permissões de quem receberá a resposta.
Aprovação humana perde valor quando aparece sem contexto
Adicionar um botão de confirmação parece resolver ações de maior impacto. Na prática, a aprovação pode tornar-se apenas mais uma etapa automática quando o responsável recebe pouco contexto, várias solicitações semelhantes ou descrições produzidas pelo próprio agente.
Uma confirmação útil precisa explicar qual operação será realizada, quais recursos serão afetados, qual credencial será usada e se existe possibilidade de reversão. Aprovar “prosseguir com a tarefa” não oferece base suficiente quando a execução envolve remover arquivos, alterar permissões, publicar conteúdo ou movimentar informações confidenciais.
O agente também não deveria participar sozinho da definição do risco da própria ação. Se o mesmo modelo interpreta a solicitação, escolhe a ferramenta e decide se precisa de aprovação, uma manipulação pode atingir toda a cadeia. Operações financeiras, administrativas, externas ou irreversíveis exigem uma validação independente da decisão que as produziu. O OWASP trata o abuso de ações de alto impacto e a manipulação dos mecanismos de aprovação como riscos específicos dos sistemas agênticos.
A supervisão humana funciona melhor quando reservada a eventos realmente relevantes. Solicitar autorização para cada leitura leva à fadiga e ao aceite automático. Não solicitar autorização para alterações importantes transfere poder demais ao agente. O desenho precisa distinguir consulta, preparação, simulação, execução e publicação.
Segurança começa separando o que o agente pode consultar do que pode alterar
O princípio do menor privilégio continua aplicável, mas precisa ser convertido em permissões temporárias e relacionadas à tarefa. Um agente que resume documentos não precisa removê-los. Um sistema que prepara respostas não precisa enviá-las sem revisão. Um fluxo que consulta pagamentos não deve possuir automaticamente autoridade para aprová-los.
A identidade exclusiva ajuda a aplicar essas separações. O acesso pode ser limitado ao recurso necessário, ao período da execução e ao tipo de operação. Quando a tarefa termina, a permissão temporária deixa de existir. Esse modelo reduz o alcance de uma instrução maliciosa e facilita distinguir atividade normal de comportamento inesperado.
Navegação, código e processamento de arquivos desconhecidos devem ocorrer em ambientes isolados. O agente não precisa enxergar toda a rede apenas porque precisa consultar um serviço. A restrição de saída também impede que qualquer destino externo seja utilizado para transmitir dados.
Logs precisam acompanhar a cadeia completa: solicitante, agente, ferramenta, recurso, autorização, resultado e destino. Registrar apenas o token final deixa a organização sem condições de reconstruir a intenção durante uma investigação.
O NIST colocou autenticação, identidade e autorização entre os pilares de sua iniciativa para agentes, enquanto a Microsoft incorporou patrocinador humano, consentimento, políticas de acesso e controle de ciclo de vida ao modelo de identidades agênticas. Esse movimento indica que agentes estão deixando de ser tratados como funcionalidades internas de um aplicativo e passando a ser administrados como atores próprios da infraestrutura digital.
A próxima fase será marcada por inventário, identidade e limitação de autonomia
A expansão dos agentes criou um problema semelhante ao surgimento do shadow IT. Departamentos conseguem conectar ferramentas, criar automações e testar agentes antes que segurança e infraestrutura saibam que essas identidades existem. Quando o inventário finalmente é realizado, algumas já possuem acesso a e-mail, arquivos, código e plataformas corporativas.
O avanço de registros centralizados, identidades próprias e controles de acesso demonstra a direção esperada para os próximos ciclos. Em vez de proteger somente o modelo, empresas precisarão conhecer cada agente, seu responsável, suas ferramentas, os dados utilizados e as operações que pode executar.
Também será necessário administrar o fim de vida. Agentes de projetos encerrados não podem permanecer com tokens válidos e integrações ativas. A revogação precisa acompanhar desligamentos, alterações de função, mudança de fornecedor e substituição de processos.
A segurança de agentes de IA não será resolvida por um filtro de prompts instalado na entrada. O problema atravessa identidade, autorização, dados, ferramentas, execução, comunicação e auditoria. Controles de modelo continuam úteis, mas não respondem se aquele agente pode tomar aquela ação sobre aquele recurso, em nome daquela pessoa, naquele momento.
Agentes ganharam capacidade de trabalho antes que as empresas definissem claramente os limites dessa capacidade. O ganho de produtividade é real, mas depende da redução consciente da autonomia. Um agente confiável não é aquele que consegue fazer tudo. É aquele que realiza apenas a tarefa autorizada, preserva a origem da delegação e encontra barreiras técnicas quando tenta ultrapassar o escopo recebido.
Dúvidas sobre permissões e segurança de agentes de IA
Qual é a diferença entre um chatbot e um agente de IA?
Um chatbot produz respostas a partir das informações recebidas. Um agente pode planejar etapas, acessar ferramentas, consultar sistemas e executar ações. Essa capacidade operacional amplia tanto a utilidade quanto o impacto de uma falha.
Por que agentes precisam de identidade própria?
A identidade permite distinguir ações de agentes e usuários, aplicar políticas específicas, revogar acessos e atribuir um responsável pelo ciclo de vida. Ela não substitui a validação da autoridade do solicitante, mas melhora controle e auditoria.
O que são permissões excessivas em um agente?
São acessos mais amplos ou duradouros do que a tarefa exige. Um agente de consulta com permissão de escrita, uma automação com acesso a toda a organização ou um token sem prazo constituem exemplos desse problema.
Prompt injection pode fazer um agente executar ações?
Pode. Uma instrução maliciosa presente em mensagens, documentos ou páginas pode influenciar o comportamento do agente. O impacto depende das ferramentas e permissões disponíveis; quanto maior o privilégio, maior a consequência possível.
Aprovação humana elimina o risco?
Não. A aprovação ajuda quando a pessoa recebe informações claras e a decisão é independente do agente. Confirmações vagas, repetitivas ou produzidas pelo mesmo sistema podem gerar aceites automáticos e não impedir uma ação indevida.
Uma conta de serviço comum pode ser usada por um agente?
Tecnicamente, pode, mas dificulta rastreabilidade, delegação e controle do ciclo de vida. Identidades específicas permitem aplicar políticas e registrar cada agente separadamente, reduzindo a dependência de credenciais compartilhadas.
O agente deve ter acesso direto aos sistemas de produção?
Somente quando a finalidade exigir e houver isolamento, permissão restrita, registro completo e mecanismo de contenção. Testes e desenvolvimento devem permanecer separados, pois credenciais de produção ampliam imediatamente o alcance de uma falha.
O que acontece quando vários agentes trabalham juntos?
Uma falha pode atravessar a comunicação entre agentes e contaminar decisões posteriores. Autenticação entre agentes, validação das mensagens e limitação de confiança são necessárias para impedir falsificação e propagação de ações indevidas.
Empresas pequenas também precisam controlar agentes?
Sim. O porte reduz a quantidade de sistemas, mas não o impacto de um agente com acesso a e-mail, arquivos, finanças ou clientes. Uma identidade separada, permissões mínimas e aprovação para ações sensíveis já oferecem uma base proporcional.
Segurança de agentes é responsabilidade do fornecedor?
O fornecedor responde pela segurança da plataforma dentro das condições contratadas, enquanto a empresa controla integrações, dados, permissões e processos. Conceder acesso excessivo a uma ferramenta segura continua sendo uma decisão de implantação.