Agentes de IA empresariais estão superando as bases de segurança

O Google News trouxe um alerta contundente para as empresas: os agentes de IA já estão atuando dentro das companhias, apesar de os controles de segurança terem sido criados para softwares previsíveis e usuários humanos.

A questão já não é se um funcionário pode pedir a um chatbot que resuma um documento. Os agentes podem recuperar registros, chamar ferramentas, atualizar sistemas, escrever código e iniciar fluxos de trabalho com várias etapas. Essa autoridade ampliada transforma uma resposta de IA em uma possível ação de negócios.

O conflito central é capacidade versus controle. As empresas querem que os agentes realizem trabalhos úteis com supervisão limitada. As equipes de segurança ainda precisam identificar cada agente, restringir seu acesso, rastrear suas decisões e interrompê-lo quando seu comportamento mudar.

Essa pressão está atingindo simultaneamente as equipes de identidade, segurança, conformidade e plataforma. Fornecedores como Microsoft, Cisco, Google, Amazon e Salesforce estão adicionando recursos de gerenciamento de agentes. Ainda assim, a tecnologia por si só não pode resolver responsabilidades pouco claras ou regras operacionais fragmentadas.

Por isso, uma manchete exibida pelo Google News aponta para uma mudança maior. O perímetro de segurança empresarial agora inclui atores de software que interpretam objetivos, escolhem etapas intermediárias e interagem com outros atores de software. As bases existentes continuam relevantes, mas muitas precisam de adaptações significativas.

O alerta do Google News é sobre ações, não respostas

Um agente de IA se torna uma preocupação de segurança quando recebe autoridade suficiente para alterar algo fora do modelo.

Assistentes de IA generativa produzem principalmente conteúdo para uma pessoa revisar. Um agente pode avançar da geração para a execução. Ele pode consultar registros de clientes, abrir um chamado de suporte, enviar código, agendar um pagamento ou reconfigurar um serviço de nuvem.

Essa distinção cria o acontecimento por trás da manchete. A adoção empresarial avançou além de interfaces de chat isoladas e passou para fluxos de trabalho conectados a sistemas operacionais. Agora, o agente pode cruzar limites que as equipes de segurança antes gerenciavam por meio de aplicações separadas e aprovações humanas.

A Microsoft define agentes como sistemas de software que acessam dados, tomam decisões e realizam ações com autoridade delegada. Sua atual base de governança recomenda políticas centralizadas que cubram identidade, propriedade, acesso, monitoramento, dados e padrões de desenvolvimento.

Autoridade delegada significa que o agente atua usando permissões concedidas por uma pessoa, serviço ou organização. O agente não é dono dessa autoridade. No entanto, suas ações ainda podem gerar consequências antes que o delegante original perceba um problema.

Considere um agente de suporte conectado a registros de clientes e a uma plataforma de tickets. Ler o histórico de uma conta envolve risco de confidencialidade. Atualizar um direito de acesso acrescenta risco de integridade. Emitir um reembolso introduz risco financeiro e cria uma necessidade maior de controles de aprovação.

Um agente de programação apresenta uma versão diferente do mesmo problema. Ele pode inspecionar repositórios, gerar alterações, executar testes e enviar um pull request. Se também puder fazer merge de código ou obter credenciais de implantação, uma instrução equivocada poderá chegar à produção.

Essas não são extensões teóricas de um chatbot. São privilégios comuns de automação combinados com tomada de decisão probabilística. O modelo pode interpretar mal o contexto, seguir conteúdo malicioso ou selecionar uma ferramenta inesperada ao perseguir um objetivo válido.

Um agente também opera em uma cadeia mais longa do que a maioria das aplicações tradicionais. Ele recebe uma meta, elabora um plano, seleciona ferramentas, recupera contexto, avalia resultados e ajusta sua próxima etapa. Cada transição cria mais um ponto onde a autorização ou o monitoramento pode falhar.

As equipes de segurança normalmente entendem uma aplicação por meio de fluxos predeterminados. Os agentes tornam alguns fluxos dinâmicos. Uma consulta permitida ao banco de dados e uma mensagem externa aprovada podem se tornar perigosas quando um agente as combina sem reconhecer a divulgação de informações.

É por isso que o enquadramento do Google News importa. A manchete não é mais uma previsão sobre inteligência artificial futura. Ela reflete uma mudança atual sobre onde está a autoridade do software e com que rapidez essa autoridade pode ser exercida.

A primeira pergunta de segurança, portanto, é concreta: quais agentes podem realizar ações hoje? Se uma organização não consegue produzir esse inventário, suas políticas se aplicam apenas aos agentes que ela já conhece.

A adoção empresarial está superando o plano de controle

A lacuna de adoção não é apenas uma implantação rápida; é a diferença entre experimentar agentes e governar cada agente como um recurso empresarial responsável.

A Cisco afirmou em março de 2026 que 85% dos grandes clientes empresariais pesquisados estavam experimentando agentes de IA. Apenas 5% haviam levado a tecnologia agêntica à produção, segundo sua pesquisa empresarial.

Esses números vêm da Cisco e devem ser lidos como pesquisa de fornecedor, não como um censo universal. Ainda assim, eles ilustram um ponto de pressão importante. A experimentação cria identidades, credenciais, conexões com ferramentas e fluxos de dados antes que um projeto receba status formal de produção.

Um protótipo pode acessar informações reais mesmo quando seus desenvolvedores o chamam de teste. Funcionários podem conectar serviços de IA para consumidores a contas corporativas. Equipes de negócios podem criar agentes de fluxo de trabalho sem envolver a segurança central. Desenvolvedores podem distribuir credenciais por meio de frameworks que as operações de segurança não conseguem descobrir facilmente.

Isso produz agentes sombra, ou seja, agentes que operam sem inventário ou aprovação organizacional completos. Agentes sombra se assemelham à shadow IT, mas podem tomar decisões e iniciar ações em diversos serviços conectados.

Inventários tradicionais de ativos podem registrar uma carga de trabalho em nuvem, um cliente de API ou uma conta de serviço. Muitas vezes, porém, eles não mostram que um agente de IA controla esses componentes. A equipe de segurança vê as credenciais sem enxergar o sistema de raciocínio que as utiliza.

A propriedade também pode se tornar igualmente pouco clara. Um gestor de negócios solicitou o fluxo de trabalho, um desenvolvedor o montou, uma equipe de plataforma o hospeda e um fornecedor disponibiliza o modelo. Quando o agente se comporta incorretamente, cada participante é responsável por apenas uma camada.

Leitores do Google News podem encontrar a segurança de agentes como uma nova categoria de produto. Para as empresas, porém, a exigência imediata é um modelo operacional. Alguém deve autorizar a finalidade do agente, aprovar seu acesso, revisar seu comportamento e desativá-lo quando essa finalidade terminar.

Os atuais controles de identidade de agentes da Microsoft exigem que toda identidade de agente tenha um patrocinador humano. O patrocinador continua responsável pela finalidade, pelas decisões de ciclo de vida e pelas revisões de acesso.

Esse modelo aborda uma questão básica, mas muitas vezes negligenciada: quem responde por um ator não humano? Atribuir um patrocinador não torna o agente seguro. Isso estabelece uma pessoa que pode aprovar mudanças e receber escalonamentos quando seu acesso deixar de corresponder à sua função.

O plano de controle também precisa de um registro confiável. Cada registro deve vincular o agente a seu proprietário, finalidade, modelo, ferramentas, fontes de dados, credenciais, ambiente e regras de aprovação. Uma lista de assinaturas de modelos não pode fornecer essa visão.

A descoberta precisa continuar após o registro. Agentes podem criar processos de curta duração, delegar tarefas ou chamar outros agentes. Uma planilha estática rapidamente se torna incompleta quando as instâncias em execução diferem do projeto aprovado.

As compras criam outra lacuna. Um recurso de software pode adicionar comportamento de agente por meio de uma atualização rotineira. A organização pode adquirir autonomia dentro de uma plataforma existente sem iniciar um projeto de IA separado ou acionar uma revisão dedicada.

Consequentemente, a pressão de segurança se desloca para a descoberta contínua. Plataformas de identidade, gateways de API, telemetria de endpoints, logs de nuvem e controles de dados precisam trabalhar juntos. Nenhuma fonte isolada revelará toda a cadeia.

As empresas sob maior pressão são aquelas com compras descentralizadas de software e sistemas de identidade fragmentados. Suas equipes podem implantar agentes mais rapidamente, mas investigadores podem ter dificuldade para reconstruir quem autorizou uma ação.

Esse desequilíbrio explica por que as bases empresariais importam mais do que uma pontuação isolada de segurança do modelo. Um modelo mais seguro não pode compensar credenciais compartilhadas, permissões excessivas, logs ausentes ou um fluxo de trabalho de produção sem responsável.

A identidade deve acompanhar o agente em cada chamada de ferramenta

Um agente identificado com acesso permanente e excessivo continua inseguro; a identidade deve ser associada a uma autorização restrita e atribuição completa.

A identidade é a primeira base porque todo controle posterior precisa de um sujeito. Os sistemas de segurança devem saber qual agente solicitou acesso, qual pessoa ou serviço delegou autoridade e qual instância realizou a ação.

Usar uma conta de serviço compartilhada quebra essa cadeia. Investigadores podem descobrir que uma conta consultou um banco de dados, mas não qual agente iniciou a solicitação. Eles também podem deixar de saber se a ação decorreu de uma tarefa humana aprovada.

Uma identidade distinta deve persistir nas chamadas de modelo do agente, nos componentes de planejamento, nas ferramentas e nos serviços posteriores. A identidade não precisa de uma credencial permanente. Ela precisa de uma relação rastreável entre cada credencial temporária e o agente original.

A autorização determina o que essa identidade pode fazer. O princípio do menor privilégio limita o acesso aos recursos e ações mínimos necessários para uma finalidade aprovada. Para agentes, o escopo também deve refletir tempo, tarefa e autoridade delegada pelo usuário.

Um agente de despesas pode precisar ler o recibo de um funcionário e criar um único reembolso em rascunho. Ele não deve consultar todos os registros de funcionários nem aprovar seu próprio pagamento. A permissão deve expirar quando a tarefa terminar.

Isso é mais rigoroso do que conceder ao agente as mesmas permissões de seu patrocinador humano. Um gestor pode acessar milhares de registros para muitas funções legítimas. Um agente que executa uma tarefa delegada deve receber apenas o subconjunto relevante.

Projetos modernos usam cada vez mais autorização just-in-time. O agente solicita acesso com escopo restrito quando necessário, e um mecanismo de política avalia essa solicitação. Ações de maior risco podem exigir que uma pessoa aprove a operação exata.

Model Context Protocol, comumente chamado de MCP, padroniza a forma como aplicações de IA se conectam a ferramentas e fontes de dados. A padronização pode melhorar a visibilidade, mas o MCP não torna automaticamente uma integração segura.

O servidor ainda exige autenticação, autorização, validação de entrada e registro em logs. O cliente ainda pode ser manipulado por conteúdo hostil. Um servidor MCP com privilégios amplos pode transformar uma integração conveniente em uma falha concentrada de controle.

O mesmo alerta se aplica à comunicação entre agentes. Um agente pode delegar pesquisa a outro e então usar o resultado para acionar uma ação. Os registros de segurança devem preservar essa cadeia de delegação, em vez de tratar a solicitação final como um evento isolado.

A autenticação responde qual identidade fez uma solicitação. A autorização responde se essa solicitação era permitida. A segurança de agentes também precisa avaliar se a solicitação se encaixa no objetivo aprovado e no contexto atual.

Essa verificação final é difícil. Um agente de compras pode ter permissão legítima para consultar fornecedores. A mesma permissão se torna suspeita se ele, de repente, extrair todo o banco de dados de fornecedores após ler um documento malicioso.

É aqui que o monitoramento comportamental complementa a política estática. O sistema deve comparar a atividade atual com a finalidade declarada do agente, a sequência habitual de ferramentas, o escopo dos dados e os limites de transação. Desvios inesperados merecem revisão ou suspensão automática.

A estrutura AEGIS da Forrester argumenta que a segurança de agentes deve conectar governança, identidade, dados, segurança de aplicações, operações contra ameaças e zero trust. Seu ponto central é que a autonomia abrange controles antes administrados como disciplinas separadas.

Zero trust significa que cada solicitação recebe uma avaliação explícita, em vez de herdar confiança da localização na rede. Aplicado a agentes, isso exige identidade verificada, acesso restrito, verificações contextuais e observação contínua.

Essa base também melhora a segurança operacional. Um agente mal configurado e um agente comprometido podem produzir ações semelhantes. Identidade e autorização robustas ajudam a conter ambos sem exigir que o sistema de segurança determine primeiro a intenção.

O título encontrado no Google News questiona se as bases empresariais estão prontas. A identidade oferece um teste prático: a empresa consegue interromper um agente sem desativar todos os fluxos de trabalho que compartilham suas credenciais?

Se a resposta for não, a organização ainda não possui controle no nível do agente. Ela tem acesso à aplicação com uma camada de IA acoplada.

A Injeção de Prompt Transforma Dados Confiáveis em uma Via de Ataque

Os agentes não apenas consomem texto não confiável; eles podem transformar esse texto em instruções com acesso a ferramentas empresariais.

A injeção de prompt ocorre quando um conteúdo influencia um modelo a ignorar ou reinterpretar suas instruções previstas. A orientação maliciosa pode aparecer em uma página da web, e-mail, documento, ticket de suporte, comentário de código ou registro de conhecimento recuperado.

Um leitor humano pode reconhecer linguagem suspeita e recusá-la. Um agente pode processar o mesmo conteúdo como contexto útil. Se o agente puder chamar ferramentas, o texto do invasor poderá influenciar ações que vão além do modelo.

Imagine um agente revisando documentos de fornecedores. Um documento contém texto oculto instruindo o agente a recuperar preços confidenciais e enviá-los para um endereço externo. A solicitação é maliciosa, embora o arquivo tenha chegado por um repositório aprovado.

A filtragem de entrada pode detectar instruções óbvias, mas não consegue resolver todo conflito entre dados e comandos. A linguagem natural desempenha os dois papéis. O agente precisa interpretar qual conteúdo descreve a tarefa e qual tenta alterá-la.

Essa ambiguidade separa a segurança de agentes da varredura convencional de malware. Um documento não precisa conter código executável. Ele pode explorar o comportamento do modelo de seguir instruções usando linguagem comum.

Os riscos de agentes da OWASP incluem sequestro de objetivos, uso indevido de ferramentas, abuso de identidade, envenenamento de memória, comunicação insegura entre agentes e falhas em cascata. Essas categorias conectam o comportamento do modelo a consequências de segurança familiares.

As restrições de ferramentas fornecem uma defesa. Um agente de pesquisa que apenas lê fontes aprovadas não pode enviar e-mail nem modificar registros de clientes. Sua saída comprometida ainda pode induzir uma pessoa ao erro, mas seu raio de impacto direto permanece menor.

A separação de funções oferece outra proteção. Um componente pode preparar uma ação enquanto um serviço de política distinto a aprova. O agente não deve decidir, autorizar e executar uma transação de alto impacto pelo mesmo caminho de raciocínio não verificado.

A classificação de dados também importa. A camada de ferramentas deve saber se as informações solicitadas são públicas, internas, confidenciais ou regulamentadas. O plano gerado pelo agente não deve substituir uma política que bloqueie a transmissão de dados restritos.

A memória introduz um risco menos visível. Os agentes podem armazenar resumos, preferências, fatos recuperados ou instruções anteriores para tarefas futuras. Um invasor que envenena essa memória pode influenciar comportamentos futuros depois que a entrada maliciosa original desaparece.

As equipes precisam distinguir o contexto de trabalho da memória duradoura. Dados temporários de tarefas devem expirar. Registros persistentes devem identificar sua origem, hora de criação, política de acesso e status de validação.

Isso é relevante para qualquer organização que esteja construindo uma base de conhecimento de IA. Uma recuperação útil depende de procedência, permissões e separação clara entre registros autoritativos e material não confiável.

Os desenvolvedores também devem presumir que as salvaguardas falham. Um modelo que recusa uma solicitação perigosa durante os testes não garante um comportamento consistente diante de formulações, ferramentas e contextos recuperados diferentes.

Os testes antes da implantação devem incluir ataques em múltiplas etapas, não apenas prompts maliciosos isolados. O teste deve examinar se um agente altera seu plano, busca ferramentas alternativas ou transporta instruções contaminadas para outro agente.

Os controles em tempo de execução continuam necessários porque o ambiente operacional muda. Novos documentos chegam, as permissões se expandem, as ferramentas recebem atualizações e os modelos mudam. Um resultado seguro em teste é evidência sobre uma configuração em um momento específico.

Isso cria o principal dilema do artigo. Mais contexto e mais ferramentas tornam os agentes úteis, mas também aumentam o número de caminhos entre entradas não confiáveis e ações consequentes.

As empresas não precisam eliminar toda decisão incerta do modelo. Elas precisam de uma arquitetura que impeça decisões incertas de receber autoridade ilimitada.

Os Logs de Auditoria Devem Registrar Decisões, Delegação e Consequências

Os logs tradicionais registram eventos de sistema, mas investigações sobre agentes exigem o caminho completo, da solicitação humana à decisão do modelo e à ação externa.

Um registro útil de agente começa com a tarefa iniciadora. Ele deve identificar o solicitante, o agente, a finalidade aprovada, a versão da política, a configuração do modelo, as ferramentas, as fontes de dados e as permissões delegadas.

Em seguida, o registro deve capturar as solicitações e os resultados das ferramentas. Ele deve mostrar qual identidade agiu, qual recurso acessou, qual política permitiu a operação e se houve aprovação humana.

Registrar o raciocínio interno apresenta complicações jurídicas, de privacidade e técnicas. Rastros de raciocínio do modelo podem conter informações sensíveis e talvez não expliquem de forma confiável o comportamento do modelo. As empresas devem priorizar entradas observáveis, decisões, chamadas de ferramentas e resultados.

Essa distinção importa durante um incidente. Os investigadores precisam de evidências suficientes para reproduzir a sequência. Eles não precisam de uma narrativa sem respaldo que afirme revelar exatamente o que o modelo “pensou”.

Os logs precisam resistir a alterações. Um agente com permissão para alterar um sistema não deve conseguir apagar a única evidência que descreve essa mudança. Registros de segurança exigem controles de acesso separados, regras de retenção e proteção de integridade.

A observabilidade também precisa de correlação entre plataformas. Um fluxo de trabalho pode começar em uma aplicação de colaboração, invocar um modelo hospedado, consultar um banco de dados em nuvem, chamar uma API externa e atualizar uma plataforma de clientes.

Cada serviço pode produzir um log tecnicamente correto enquanto a história geral permanece invisível. Um identificador de transação compartilhado deve conectar a solicitação original a cada etapa delegada.

As equipes devem decidir o que aciona uma intervenção. Uma falha de login é fácil de classificar. Um agente que altera sua sequência de ferramentas pode representar uma adaptação benigna ou evidência inicial de manipulação.

A política pode começar com limites de alta confiança. Sistemas de segurança podem bloquear destinos não aprovados, escalonamento de privilégios, recuperação excessiva de dados, transações proibidas e ações fora dos períodos de trabalho definidos.

A análise comportamental pode então identificar desvios mais sutis. Os exemplos incluem combinações incomuns de ferramentas, solicitações negadas repetidas, enumeração rápida de dados, novos padrões de delegação ou acesso sem relação com o objetivo declarado.

A revisão humana deve se concentrar nesses casos ambíguos. Exigir aprovação para toda ação de baixo risco destrói a eficiência que os agentes prometem. Permitir toda ação elimina a responsabilização de que as empresas precisam.

Portanto, a organização precisa de níveis de risco. Ler uma página pública da web é diferente de exportar dados de clientes. Redigir uma mensagem é diferente de enviá-la. Preparar uma alteração de código é diferente de implantá-la.

Cada nível deve especificar requisitos de autonomia, aprovação, registro, testes e reversão. A classificação pertence ao processo de negócios, não apenas ao modelo.

A reversão merece atenção especial. Algumas ações podem ser desfeitas, enquanto outras não. Um arquivo de staging excluído pode ser recuperável. Um segredo divulgado, um pagamento concluído ou uma mensagem pública podem gerar consequências permanentes.

Os planos de resposta a incidentes devem incluir a contenção de agentes. As equipes precisam de um método rápido para suspender uma identidade, revogar credenciais temporárias, isolar a memória afetada, preservar registros e identificar agentes dependentes.

O setor está começando a formalizar como os incidentes com agentes devem ser compartilhados. A proposta SAFE framework abrangeria acesso não autorizado, violações de informações confidenciais, sondagem contínua e certos quase-incidentes.

Segundo a proposta publicada, as evidências relevantes podem incluir prompts, rastros, chamadas de ferramentas, identidades, permissões e credenciais. A iniciativa continua sendo uma proposta, mas sua lista de evidências ilustra quanto contexto um incidente com agente exige.

Relatórios compartilhados poderiam expor padrões recorrentes de falha que empresas individuais não conseguem ver. Eles também poderiam levantar questões difíceis sobre confidencialidade, responsabilidade e medidas comparáveis de gravidade.

Em última análise, o título do Google News testa se as empresas conseguem responder a perguntas forenses básicas. Qual agente agiu, quem o autorizou, quais informações o moldaram, qual política permitiu isso e o que mudou depois?

Se essas respostas exigirem reconstrução manual entre várias equipes, a base de segurança não está pronta para a autonomia rotineira de agentes.

O Que os Líderes de Segurança Devem Acompanhar a Seguir

A próxima fase será medida por controles aplicáveis e falhas relatadas, não pelo número de fornecedores que adicionam um rótulo de agente.

O primeiro sinal é a adoção de identidades distintas para agentes. Microsoft, Cisco e outros provedores de plataformas estão introduzindo recursos de identidade voltados a agentes. As empresas devem observar se os clientes os implementam em agentes de terceiros e personalizados, não apenas no ambiente de um único fornecedor.

Uma ampla cobertura de identidade fortaleceria o argumento de que os programas de identidade existentes podem evoluir para abranger atores não humanos. Uma cobertura limitada deixaria as organizações com registros de agentes separados e aplicação inconsistente.

O segundo sinal é a política em tempo de execução aplicada aos protocolos de ferramentas. MCP e outros padrões de conexão facilitam a criação de integrações de agentes. O progresso em segurança depende de os gateways conseguirem autenticar agentes de forma consistente, restringir permissões, inspecionar contexto e registrar ações.

Um protocolo pode ser amplamente adotado antes que seus controles de governança amadureçam. As equipes de segurança devem medir ações negadas, credenciais temporárias, exceções de política e conexões de ferramentas não registradas, em vez de contar servidores configurados.

O terceiro sinal é a divulgação confiável de incidentes. Os relatórios públicos devem revelar se as falhas envolvem injeção de prompt, permissões excessivas, delegação equivocada, memória envenenada, ferramentas inseguras ou ausência de aprovação humana.

Os registros de incidentes ajudarão as empresas a distinguir falhas operacionais comuns de ameaças especulativas. Eles também testarão se os logs atuais capturam evidências suficientes para uma análise significativa.

Os líderes de segurança não devem esperar por uma manchete descrevendo uma grande perda. Eles podem avaliar a prontidão por meio de exercícios controlados agora.

Dê a um agente de teste um objetivo empresarial válido e insira instruções conflitantes dentro de conteúdo recuperado. Observe se ele segue o conteúdo, solicita acesso mais amplo, tenta outra ferramenta ou interrompe a operação para revisão.

Em seguida, revogue sua identidade durante o fluxo de trabalho. Confirme que todas as ferramentas negam solicitações posteriores e que os agentes dependentes recebem a alteração. Uma revogação que entra em vigor em apenas uma plataforma cria uma falsa sensação de segurança.

Realize um segundo exercício focado em propriedade. Pergunte quem aprova um aumento de permissões, quem recebe um alerta, quem pode suspender o agente e quem decide se ele volta a operar.

As respostas devem indicar funções nomeadas, e não departamentos. “Segurança e TI” não constitui um procedimento operacional com responsabilização clara.

As organizações também devem medir quantos agentes permanecem desconhecidos. Descobertas de inventário, identidades órfãs, credenciais compartilhadas e endpoints de ferramentas não aprovados revelam lacunas de controle com mais clareza do que anúncios de implantação.

Os profissionais do conhecimento têm um papel nesse processo. Eles devem saber quando um agente atua sob sua autoridade e quais ações exigem confirmação. A delegação não deve ocultar a responsabilidade por trás de uma interface automatizada.

Os desenvolvedores precisam de padrões aprovados para identidade, acesso a ferramentas, segredos, logs, testes e memória. Exigir que cada equipe invente essas bases por conta própria garante uma proteção inconsistente.

Compradores empresariais devem perguntar aos fornecedores como as identidades dos agentes se vinculam a patrocinadores humanos, como as permissões expiram e como as ações aparecem nos sistemas de segurança existentes. Também devem testar se os logs continuam disponíveis depois que um agente é desativado.

A principal lição do Google News não é que as empresas devem deixar de usar agentes. É que a autonomia deve seguir uma maturidade de controle verificada.

Uma organização pronta para agentes consegue identificar cada um deles, restringir todas as chamadas de ferramentas, preservar as cadeias de delegação, detectar mudanças de comportamento e revogar autoridade rapidamente. Ela também consegue explicar quem continua responsável quando a automação falha.

Uma organização despreparada vê apenas uma interface útil. Por trás dela, credenciais compartilhadas, permissões amplas, dados com níveis de confiança misturados e logs fragmentados criam uma estrutura de autoridade que ninguém governa plenamente.

Os próximos um a três meses devem esclarecer se plataformas de identidade, gateways de runtime e iniciativas de divulgação estão convergindo em torno de práticas comuns. Essa convergência tornaria a supervisão de agentes mais fácil em ambientes empresariais heterogêneos.

Até lá, toda organização deve tratar a autonomia dos agentes como um acesso conquistado. Comece com tarefas restritas, ações reversíveis, permissões de curta duração e fluxos de trabalho observáveis. Amplie a autoridade apenas quando as evidências mostrarem que os controles funcionam.

A pergunta para os leitores é imediata: se um de seus agentes fizesse uma alteração não autorizada amanhã, sua equipe conseguiria identificá-lo, interrompê-lo e reconstruir toda a cadeia? Caso contrário, use o mais recente alerta do Google News como um incentivo para inventariar agentes, atribuir responsáveis e testar a revogação antes de conceder mais autonomia.