A IA agêntica está forçando o Zero Trust a enfrentar uma crise de identidade

A IA agêntica chegou ao Google News com uma alegação contundente: sistemas autônomos estão virando a cibersegurança Zero Trust “de cabeça para baixo”. A manchete da Breaking Defense identifica um conflito real, embora os detalhes subjacentes continuem difíceis de verificar de forma independente. As equipes de segurança construíram controles de acesso em torno de pessoas, dispositivos e aplicações previsíveis. Os agentes de IA agora confundem as três categorias enquanto atuam com autoridade delegada.

Isso não torna o Zero Trust obsoleto. Muda o que as organizações precisam verificar, com que frequência devem verificar e qual identidade executou cada ação. Um agente pode interpretar um objetivo, selecionar ferramentas, ler conteúdo externo, chamar APIs e modificar dados. Seu comportamento não é totalmente abrangido pelas permissões atribuídas ao seu proprietário humano.

O resultado é uma inversão desconfortável. O Zero Trust pressupõe que toda solicitação deve ser avaliada, mas os fluxos de trabalho agênticos geram longas cadeias de solicitações na velocidade das máquinas. Portanto, a disputa principal não é IA agêntica versus Zero Trust. É controle de acesso estático versus controle contínuo sobre comportamento autônomo.

A alegação do Google News aponta para uma mudança real na segurança

A mudança importante não é que a IA pode acessar sistemas empresariais, mas que ela pode decidir o que fazer depois de obter acesso.

O software tradicional segue caminhos definidos previamente pelos desenvolvedores. Ele pode conter bugs, aceitar entradas maliciosas ou expor interfaces vulneráveis. No entanto, os defensores geralmente conseguem mapear suas funções pretendidas para contas, processos e conexões de rede estabelecidos.

A IA agêntica adiciona uma camada de tomada de decisão entre a instrução de um usuário e a ação resultante. Um agente pode dividir um objetivo amplo em tarefas menores, escolher entre as ferramentas disponíveis e se adaptar quando um caminho falha. O NIST descreve agentes modernos como modelos de uso geral combinados com software que lhes permite manipular ferramentas além da geração de texto.

Essas ferramentas podem incluir navegadores, bancos de dados, calendários, interpretadores de código, arquivos locais e interfaces administrativas. A taxonomia de uso de ferramentas do NIST distingue o acesso somente leitura do acesso de gravação restrito ou irrestrito. Ela também separa ambientes confiáveis de não confiáveis.

Essa distinção importa porque um único agente frequentemente atravessa várias categorias durante uma atribuição. Ele pode ler um e-mail, extrair um número de cliente, consultar um banco de dados interno e atualizar um registro de suporte. Cada etapa pode parecer permitida quando analisada separadamente.

O fluxo de trabalho combinado ainda pode produzir um resultado inseguro. Um invasor pode inserir instruções ocultas no e-mail. O agente pode interpretar essas instruções como parte de sua tarefa e, em seguida, usar permissões legítimas para divulgar dados.

Esse ataque é chamado de injeção indireta de prompt, o que significa que instruções maliciosas chegam a um agente por meio do conteúdo que ele processa. O invasor não precisa da senha do funcionário. Ele mira na interpretação do agente sobre informações confiáveis e não confiáveis.

A manchete do Google News captura essa mudança com a expressão “de cabeça para baixo”. Antes, as equipes de segurança se preocupavam que pessoas usassem mal o software ou entregassem credenciais. Agora, elas também precisam considerar softwares que interpretam a autoridade de uma pessoa e agem de forma independente dentro dela.

Isso não é apenas mais um endpoint entrando na rede. Normalmente, um endpoint tem uma função, postura e modelo de propriedade relativamente estáveis. Um agente pode mudar seu plano imediato enquanto mantém a mesma identidade, credenciais e conexão.

Isso cria um problema de visibilidade. Um log pode mostrar que uma conta de serviço válida acessou um banco de dados. Ele pode não revelar qual usuário iniciou a tarefa, qual agente formulou o plano ou qual entrada externa influenciou a decisão.

A manchete ainda deve ser tratada como uma tese, não como prova de uma violação específica. Nenhum detalhe verificado de incidente acompanha o item fornecido do Google News. A questão mais ampla de segurança, contudo, é respaldada por pesquisas públicas e pelo trabalho atual de padronização.

As equipes de segurança não estão mais protegendo apenas o acesso de humano para aplicação e de aplicação para aplicação. Elas precisam proteger uma cadeia que conecta um humano, um agente, um modelo, várias ferramentas e múltiplas fontes de dados. A confiança pode vazar em cada transferência.

O Zero Trust foi construído para solicitações, não para objetivos abertos

O Zero Trust continua relevante, mas sua unidade convencional de controle é estreita demais para o trabalho autônomo.

O NIST publicou sua arquitetura fundamental de Zero Trust em 2020. O modelo rejeita a confiança implícita baseada na localização da rede ou na propriedade de ativos. A autenticação e a autorização ocorrem antes que uma sessão alcance um recurso empresarial.

A arquitetura se concentra em recursos, e não em segmentos de rede tradicionais. Ela pressupõe que uma rede já pode estar comprometida. Portanto, o acesso deve permanecer limitado ao menor conjunto de permissões necessário para uma missão específica.

Essa abordagem combate o antigo modelo de perímetro. Na segurança de perímetro, usuários autenticados frequentemente recebiam amplo acesso depois de entrar em uma rede confiável. Invasores podiam então mover-se lateralmente entre sistemas após comprometer uma conta ou dispositivo.

A IA agêntica não invalida esses princípios. Na verdade, o privilégio mínimo e a avaliação contínua tornam-se mais importantes quando máquinas podem executar muitas ações rapidamente. A dificuldade está em traduzir um objetivo amplo do usuário em permissões aplicáveis e de curta duração.

Considere um agente encarregado de preparar um relatório trimestral de risco de clientes. A tarefa parece informativa, mas concluí-la pode exigir várias capacidades. O agente precisa localizar registros, combinar dados, calcular tendências e produzir um documento.

O agente deve receber acesso a todos os registros de clientes durante toda a atribuição? Deve manter essas permissões depois disso? Ele pode enviar o relatório por e-mail, ou a distribuição deve exigir aprovação separada?

Um sistema de acesso convencional pode responder a essas perguntas por meio da função existente do usuário. Se o funcionário pode ler o banco de dados e enviar e-mails, o agente herda ambos os poderes. Essa herança é simples, mas cria autoridade excessiva.

O agente pode executar combinações de ações que o funcionário nunca pretendeu. Também pode repeti-las em uma escala que os fluxos de trabalho manuais raramente alcançam. Um pequeno erro de interpretação pode se transformar em centenas de consultas a bancos de dados ou mensagens.

Objetivos abertos tornam o desenho de políticas mais difícil. “Encontre as evidências relevantes” não especifica quais repositórios devem ser pesquisados. “Resolva o problema” não define se o agente pode emitir um reembolso, modificar uma conta ou executar código.

Tradicionalmente, o Zero Trust avalia solicitações de acesso usando identidade, integridade do dispositivo, sensibilidade do recurso e contexto ambiental. Sistemas agênticos adicionam outra pergunta: esta ação continua coerente com a tarefa que justificou o acesso?

Essa pergunta exige controles conscientes da intenção. Esses controles comparam uma ação com o propósito atribuído ao agente, seu plano atual e a política aprovada. Eles não podem depender apenas de uma conta tecnicamente possuir permissão.

A fronteira de segurança também se move durante o trabalho com múltiplos agentes. Um agente pode delegar pesquisa a outro agente. Esse segundo agente pode chamar um serviço de terceiros, que devolve conteúdo contendo novas instruções.

Cada transferência pode alterar o contexto enquanto preserva uma autorização aparente. Uma política estática vê identidades aprovadas transmitindo dados. Uma política comportamental deve determinar se toda a cadeia ainda atende ao objetivo original.

É por isso que a segurança da IA agêntica não pode parar na segmentação de rede. O plano de controle precisa compreender identidades, tarefas, ferramentas, linhagem de dados e histórico de ações. Ele também precisa preservar essas relações para investigação posterior.

A promessa original do Zero Trust continua válida: nunca conceda confiança apenas porque algo já está dentro. Os fluxos de trabalho agênticos simplesmente revelam que “dentro” pode descrever uma janela de contexto, uma tarefa delegada ou uma cadeia de ferramentas. Já não se refere apenas a uma rede.

Agentes de IA precisam de identidades separadas de seus proprietários

Uma organização não pode governar um agente autônomo se todas as ações aparecerem sob uma conta humana ou de serviço compartilhada.

A identidade é o primeiro ponto de pressão para as equipes de segurança empresarial. Pessoas têm registros de emprego, gestores, funções profissionais e procedimentos de desligamento. Aplicações têm proprietários, processos de lançamento e contas de serviço.

Os agentes combinam características de ambos os grupos. Podem receber objetivos de pessoas, mas executam por meio de software. Podem operar brevemente em uma única tarefa ou continuar funcionando como trabalhadores digitais persistentes.

Tratar um agente como um recurso oculto dentro de uma aplicação obscurece a responsabilização. Tratá-lo como um funcionário comum também cria falsa confiança. O agente precisa de uma identidade de máquina de primeira classe, vinculada ao seu proprietário, propósito e implantação.

Essa identidade não deve substituir a identidade do usuário que iniciou a ação. Ambas devem persistir durante todo o fluxo de trabalho. Os investigadores precisam saber quem solicitou uma ação e qual agente a executou.

Um registro de auditoria útil também deve capturar o modelo, a ferramenta, a política e a fonte de dados envolvidos. Sem esse contexto, um log de banco de dados mostra apenas o acesso final. Ele não consegue explicar por que o agente acreditou que aquele acesso era apropriado.

As equipes de segurança devem evitar credenciais compartilhadas para implantações de agentes. Contas compartilhadas impedem uma atribuição confiável e complicam a revogação. Elas também permitem que agentes abandonados permaneçam ativos depois que seus projetos originais terminam.

Uma identidade de agente precisa de um ciclo de vida. A criação deve identificar um proprietário responsável e um uso aprovado. Revisões periódicas devem confirmar que o agente continua necessário e que suas permissões ainda correspondem ao seu propósito.

A expiração é igualmente importante. Agentes temporários devem perder acesso quando uma tarefa ou projeto termina. Agentes persistentes devem passar por recertificação regular, assim como contas humanas privilegiadas.

As permissões também devem ser específicas para a tarefa e de curta duração. Um agente que prepara um relatório pode receber acesso temporário de leitura a registros selecionados. Enviar esse relatório para fora da organização deve exigir uma permissão separada ou confirmação humana.

Esse desenho reduz o acúmulo de privilégios, que ocorre quando identidades acumulam acessos que já não correspondem às suas responsabilidades. O acúmulo de privilégios já é difícil com funcionários. Agentes autônomos podem multiplicar o problema porque as equipes conseguem criá-los rapidamente.

A descoberta de agentes, portanto, torna-se um requisito operacional. As equipes de segurança precisam de um inventário em serviços SaaS, plataformas de desenvolvimento, sistemas internos de automação e integrações de terceiros. Registros de compras, por si só, não identificarão agentes criados dentro de produtos existentes.

A descoberta precisa distinguir um recurso de IA de uma identidade atuante. Um recurso de resumo que apenas lê um documento apresenta riscos diferentes dos de um agente capaz de pesquisar unidades e enviar mensagens. Ambos podem usar o mesmo modelo.

O proprietário também deve estar visível nas políticas e nos logs. Quando um agente age fora das expectativas, os responsáveis pela resposta precisam de uma pessoa ou equipe capaz de suspendê-lo. A automação anônima cria atrasos durante incidentes.

As organizações já usam identidades não humanas para serviços, cargas de trabalho e máquinas. As identidades de agentes estendem essa disciplina, em vez de substituí-la. A diferença é que a política deve considerar o comportamento variável dentro da mesma função atribuída.

Os principais fornecedores de segurança estão avançando nessa direção. A Cisco anunciou descoberta de agentes, controles de identidade para agentes e aplicação do Model Context Protocol em sua atualização de segurança para agentes. O Model Context Protocol, ou MCP, conecta modelos a ferramentas e dados externos.

Os anúncios de fornecedores não são evidência independente de que os controles funcionem em todas as implantações. Eles mostram, porém, para onde a competição está indo. Plataformas de identidade, intermediários de acesso e gateways de segurança querem se tornar o ponto de controle do tráfego de agentes.

Compradores corporativos devem evitar tratar um único gateway como solução completa. O NIST há muito observa que nenhum fornecedor fornece uma arquitetura Zero Trust inteira. A segurança agêntica adiciona mais componentes e mais oportunidades para aplicação inconsistente.

A pressão imediata recai sobre as equipes de gestão de identidade e acesso. Elas precisam dar suporte a atores de máquina criados rapidamente sem repetir o problema de contas de serviço não gerenciadas. Atribuições estáticas de função não serão suficientes.

O Sequestro de Agentes Expõe os Limites das Verificações Estáticas de Permissão

Um agente corretamente autenticado ainda pode executar a ação errada, porque a autenticação não valida seu raciocínio.

O argumento mais forte para reformular o Zero Trust vem das pesquisas sobre sequestro de agentes. Em março de 2026, o NIST divulgou resultados de uma grande competição pública de red teaming que abrangeu 13 modelos de ponta. Mais de 400 participantes realizaram mais de 250.000 tentativas de ataque.

Pelo menos um ataque de sequestro bem-sucedido foi encontrado contra cada modelo testado. Os modelos diferiram em sua resistência, mas a capacidade não previu a segurança de forma consistente. Algumas famílias de ataque também foram transferidas entre modelos e cenários diferentes.

Esses resultados não significam que todos os agentes implantados sejam facilmente comprometidos. Uma competição incentiva atacantes focados e pode não reproduzir todos os controles de produção. Ainda assim, ela estabelece que a resistência no nível do modelo, por si só, não pode servir como fronteira de segurança.

O NIST define sequestro de agentes como um ataque que insere instruções maliciosas nos dados processados por um agente. O objetivo é redirecionar o agente para um comportamento prejudicial. Os possíveis resultados incluem exfiltração de dados ou execução de código malicioso.

O detalhe crucial é que o agente frequentemente usa ferramentas e credenciais válidas. Um firewall pode enxergar uma conexão aprovada. Um sistema de identidade pode enxergar uma conta autenticada. A etapa perigosa ocorre na interpretação que o agente faz do conteúdo.

Isso torna listas estáticas de permissões incompletas. Permitir que um agente leia e-mails e atualize um banco de dados pode ser necessário para seu trabalho. A política ainda precisa impedir que um e-mail redefina o que a ferramenta de banco de dados deve fazer.

As conclusões de red team relevantes apoiam uma defesa em profundidade. Os modelos precisam de avaliação, mas as implantações também precisam de ferramentas restritas, limites de dados, monitoramento e pontos de aprovação.

As permissões de ferramentas devem refletir a consequência, não a conveniência. Ler uma página pública apresenta riscos diferentes de executar código baixado. Consultar o registro de um cliente é diferente de excluí-lo ou exportá-lo.

Ferramentas de alto impacto devem expor operações restritas. Um agente que precisa agendar uma reunião não deve receber controle irrestrito da caixa de entrada. Um agente financeiro que redige um pagamento também não deve aprová-lo e transmiti-lo.

Esse princípio é chamado de separação de funções. Ele impede que uma identidade controle todas as etapas de um processo sensível. Sistemas agênticos precisam da mesma divisão, mesmo quando a automação torna a consolidação tentadora.

A aprovação humana continua útil em limites irreversíveis. Transferências, exclusões, publicação externa, implantação em produção e alterações de credenciais merecem verificações explícitas. A aprovação deve exibir a ação pretendida e o contexto relevante.

Um botão genérico de “permitir” acrescenta pouca proteção. O revisor precisa saber qual agente solicitou a ação, quais dados ele usou e qual efeito a aprovação produzirá. Caso contrário, a automação apenas transfere a engenharia social para a tela de aprovação.

O monitoramento deve se concentrar em mudanças de comportamento. Um agente que de repente acessa repositórios desconhecidos pode indicar sequestro ou planejamento defeituoso. Chamadas repetidas de ferramentas que falham podem sinalizar que um agente está sondando além de sua função.

Limites de taxa também reduzem os danos causados por erros. A execução em velocidade de máquina pode transformar uma única decisão ruim em um incidente generalizado. Limitar o volume de ações dá aos sistemas de monitoramento e às equipes de resposta tempo para intervir.

O sandboxing continua valioso, mas não deve criar uma suposição de segurança. Um agente pode causar danos sem escapar de seu ambiente de execução. Enviar dados autorizados ao destino errado pode não exigir nenhuma exploração de software.

A incerteza central é se sistemas atentos à intenção podem tomar decisões confiáveis sem bloquear trabalho útil. Os planos dos agentes mudam, as tarefas empresariais contêm ambiguidades e as políticas não podem antecipar todas as exceções legítimas.

Controles excessivamente rígidos produzirão solicitações constantes de aprovação. As equipes podem então conceder permissões mais amplas para restaurar a produtividade. Essa resposta recria exatamente a confiança implícita que o Zero Trust buscava eliminar.

Controles excessivamente permissivos produzem a falha oposta. Os agentes operam sem atritos até que uma entrada maliciosa ou erro de planejamento explore sua autoridade. As equipes de segurança precisam medir tanto o trabalho bloqueado quanto as ações inseguras.

Essa troca impede alegações fáceis de que um produto de “Zero Trust agêntico” resolveu o problema. Demonstrações de produtos normalmente mostram fluxos de trabalho selecionados. Implantações reais contêm sistemas legados, identidades compartilhadas e logs inconsistentes.

A abordagem mais confiável no curto prazo é em camadas. Dê a cada agente uma identidade, restrinja cada ferramenta, preserve o usuário iniciador, valide ações consequentes e monitore o comportamento. Presuma que as salvaguardas do modelo falharão às vezes.

A Batalha Competitiva Está Migrando para o Plano de Controle

Fornecedores de segurança competem para intermediar o comportamento dos agentes, enquanto as empresas ainda não têm um modelo comum para provar que essa intermediação funciona.

A IA agêntica cria oportunidades para provedores de identidade, fornecedores de segurança de rede, plataformas de nuvem e empresas especializadas em segurança de IA. Cada grupo controla uma parte diferente do fluxo de trabalho. Nenhum deles vê automaticamente toda a cadeia.

Fornecedores de identidade sabem quem recebeu acesso. Plataformas de rede observam conexões entre sistemas. Provedores de nuvem podem monitorar cargas de trabalho e chamadas de API. Ferramentas de segurança de IA inspecionam prompts, saídas de modelos e solicitações de ferramentas.

A posição valiosa é o ponto de decisão de política. Em uma arquitetura Zero Trust, esse componente avalia o acesso e decide se a aplicação deve permiti-lo. Sistemas agênticos tornam essa decisão mais rica e mais disputada.

Um fornecedor de rede pode argumentar que a comunicação entre agentes deve passar por um intermediário de segurança. Um fornecedor de identidade pode concentrar a política em identidades de máquina e autorização delegada. Um provedor de segurança de IA pode priorizar a inspeção de prompts e a avaliação comportamental.

As três visões contêm parte da resposta. O contexto de rede não pode revelar todas as instruções maliciosas. A inspeção de prompts não pode, por si só, impedir uma consulta bloqueada ao banco de dados. A verificação de identidade não pode garantir que um agente autenticado siga seu propósito.

O MCP tornou-se um foco porque padroniza conexões entre modelos e ferramentas. Um gateway pode inventariar servidores, restringir operações e registrar chamadas. No entanto, nem todo agente usa MCP, e um gateway não pode governar ferramentas que o contornam.

A comunicação entre agentes apresenta outro desafio. A delegação pode cruzar modelos, fornecedores ou fronteiras organizacionais. O agente receptor precisa de evidências sobre a identidade, a autoridade e o escopo solicitado pelo remetente.

Uma mensagem assinada pode autenticar o remetente. Ela não prova que o plano do remetente é seguro. A política deve separar proveniência, que identifica de onde veio uma solicitação, de autorização, que determina se ela deve prosseguir.

O trabalho de padronização está começando a abordar essas lacunas. O NIST lançou sua iniciativa de padrões para agentes em fevereiro de 2026. Sua agenda inclui interoperabilidade, protocolos abertos, segurança, identidade e adoção confiável.

Essa iniciativa importa porque as organizações precisam de representações comparáveis de identidade e autoridade de agentes. Sem formatos comuns, cada plataforma cria identidades proprietárias e sinais de política próprios. As equipes de segurança então enfrentam dificuldades para aplicar controles em todos os ambientes.

Padrões, por si só, não podem definir a tolerância ao risco. Um hospital, banco, contratante de defesa e agência de marketing atribuirão consequências diferentes à mesma ação de ferramenta. A interoperabilidade fornece infraestrutura compartilhada, não uma política universal.

O enquadramento da Breaking Defense é especialmente relevante para ambientes de alta garantia. Sistemas de defesa frequentemente combinam dados classificados, restrições de missão, equipamentos legados e responsabilização rigorosa. Uma ação autônoma pode ter consequências além da automação comum de escritório.

Esses ambientes também criam pressão para automatizar. Analistas enfrentam grandes volumes de alertas, documentos e dados de sensores. Agentes podem ajudar a correlacionar informações e executar etapas repetitivas, mas maior autonomia aumenta a necessidade de controle rastreável.

A concorrência deve, portanto, ser avaliada por evidências, não por vocabulário de produto. Compradores precisam testar se um controle identifica agentes de forma confiável, vincula ações a responsáveis, limita ferramentas e produz registros de auditoria utilizáveis.

Eles também devem testar casos de falha. O que acontece quando o provedor de identidade fica indisponível? Um agente pode recorrer a permissões armazenadas em cache? Um intermediário falha de forma fechada ou o tráfego contorna a inspeção?

A cobertura entre plataformas importa tanto quanto os recursos individuais. Uma organização pode usar um modelo de uma nuvem, o agente de programação de outro fornecedor e vários assistentes SaaS. Um controle que enxerga apenas um ambiente deixa pontos cegos significativos.

O mercado provavelmente se consolidará em torno de plataformas integradas, mas a integração pode criar seu próprio risco de concentração. Um plano de política comprometido poderia afetar muitos agentes. Registro e aplicação independentes continuam sendo salvaguardas importantes.

O Google News pode amplificar manchetes sobre IA agêntica substituindo modelos de segurança conhecidos. A conclusão mais precisa é mais restrita. Fornecedores existentes precisam estender o Zero Trust das decisões de conexão à governança de identidade, intenção e ação.

O Que as Equipes de Segurança Devem Acompanhar a Seguir

A próxima fase será decidida por evidências mensuráveis de implantação, não por alegações mais amplas sobre segurança autônoma.

O primeiro sinal é se grupos de padrões produzem especificações utilizáveis para identidade de agentes e autorização delegada. O NIST afirmou que sua iniciativa desenvolveria pesquisas, orientações e outras entregas. As empresas devem acompanhar formatos que funcionem entre fornecedores.

Uma especificação de identidade útil deve conectar um agente a um proprietário, propósito, modelo e ferramentas aprovadas. Ela também deve preservar o usuário iniciador durante a delegação. Se as plataformas adotarem representações incompatíveis, a governança continuará fragmentada.

O segundo sinal é o teste de segurança independente. A competição do NIST encontrou ataques bem-sucedidos contra todos os modelos de ponta testados, mas as organizações precisam de avaliações no nível da implantação. Os testes devem incluir modelos, ferramentas, permissões, memória e dados externos.

Testes comparativos devem medir mais do que o sucesso de injeção de prompt. Devem examinar se os agentes excedem o escopo da tarefa, usam mal ferramentas legítimas ou ocultam ações consequentes em fluxos de trabalho longos. Também devem testar a recuperação e a qualidade da auditoria.

Se o sucesso dos ataques cair enquanto os agentes mantêm capacidades úteis, a confiança em controles conscientes da intenção se fortalecerá. Se modelos aprimorados continuarem vulneráveis em implementações ricas em ferramentas, os controles de infraestrutura se tornarão ainda mais importantes.

O terceiro sinal é o comportamento das empresas após os pilotos. As equipes de segurança devem acompanhar quantos agentes recebem identidades únicas, credenciais limitadas e responsáveis definidos. Também devem medir agentes abandonados e permissões não revisadas.

Os números de adoção, por si só, revelam pouco. Uma empresa pode implantar milhares de agentes mantendo-os somente para leitura e isolados. Um único agente com amplo acesso ao ambiente de produção pode representar um risco maior do que toda essa população.

Os relatórios de incidentes oferecerão outra verificação da realidade. Casos públicos devem explicar se as falhas resultaram de injeção de prompt, privilégios excessivos, confusão de identidade ou limites de aprovação ausentes. Sem esse nível de detalhe, o setor não consegue comparar defesas.

Líderes de segurança devem fazer perguntas diretas antes de expandir um piloto:

• Cada agente tem uma identidade única e um responsável que presta contas?

• As permissões podem expirar automaticamente quando a tarefa termina?

• Os logs retêm tanto a pessoa solicitante quanto o agente executor?

• Quais ferramentas podem criar mudanças irreversíveis?

• Conteúdo externo pode influenciar essas chamadas de ferramenta?

• Que volume de ações aciona revisão ou suspensão?

• As equipes de resposta podem desativar um agente sem interromper toda a plataforma?

• Agentes delegados são limitados pela tarefa original?

• O sistema falha de forma fechada quando os serviços de política estão indisponíveis?

• Auditores conseguem reconstruir por que uma ação sensível ocorreu?

Essas perguntas transformam a alegação de “virar de cabeça para baixo” em um teste de implementação. Se uma plataforma não consegue respondê-las, sua linguagem de Zero Trust permanece incompleta. Se consegue, a arquitetura talvez já esteja se adaptando.

A conclusão mais importante é que as organizações não devem abandonar o Zero Trust. Devem aplicá-lo a unidades de autoridade menores e mais dinâmicas. Cada agente, chamada de ferramenta, delegação e ação relevante merece seu próprio contexto de política.

Essa abordagem introduzirá atrito. Algumas tarefas automatizadas exigirão ferramentas mais restritas ou confirmação humana. Alguns pilotos avançarão mais lentamente enquanto as equipes criam inventários e controles de ciclo de vida.

A alternativa é autoridade oculta. Os agentes herdarão permissões humanas amplas, processarão conteúdo não confiável e deixarão registros incompletos. As equipes de segurança então descobrirão fluxos de trabalho autônomos somente após um incidente.

A IA agêntica não derrotou o Zero Trust. Ela expôs onde muitos programas de Zero Trust pararam: na autenticação, no acesso à rede ou na postura do dispositivo. A próxima versão deve governar o que máquinas autenticadas decidem fazer.

Portanto, vale manter a pergunta levantada pelo Google News, mesmo que a manchete exagere a reversão. Sua organização consegue rastrear a identidade, o propósito, as evidências e a autoridade de um agente antes que sua próxima ação seja executada?

Comece com um fluxo de trabalho de produção e reconstrua essa cadeia do início ao fim. Se qualquer transferência se tornar invisível, trate-a como uma lacuna de controle. Esse exercício oferece mais valor do que adotar mais um rótulo de segurança, porque testa se o Zero Trust acompanha o agente durante o trabalho real.