A shadow AI agêntica é indiferente ao nome dado à superinteligência

A 29 de setembro de 2026, a Casa Branca assinou a Executive Order 14434, «Inaugurating the Era of Super Intelligence». A ordem determina que as agências federais usem «Super Intelligence» (superinteligência), ou «SI», nas comunicações oficiais em vez de «AI». Procura mudar um termo. Não define nenhuma tecnologia nova nem cria nenhuma nova categoria de risco, pelo que não existe nenhuma Shadow Super Intelligence para a qual seja preciso planear.

O risco que já existe é a shadow AI agêntica: agentes autónomos que funcionam sem autorização nem supervisão. São sistemas de IA que operam dentro da organização sem que uma pessoa aprove cada ação e que têm as suas próprias credenciais, em vez de usarem o início de sessão de alguém. A este tipo de agente é indiferente o nome que o governo federal lhe dá. O agente continua a ter o token OAuth, e o token continua a funcionar, quer os documentos digam AI, quer digam Super Intelligence.

O que muda realmente a ordem «Super Intelligence» (nada)

A Executive Order 14434 é uma diretiva terminológica para o poder executivo dos EUA: as agências devem escrever «Super Intelligence» («SI») em vez de «AI» nos documentos oficiais não legislativos. Não impõe obrigações às empresas privadas e não prevê sanções. Inicia também um processo de 60 dias que poderá terminar numa nova definição legal.

O presidente Trump assinou a ordem a 29 de setembro de 2026. Foi publicada no Federal Register a 2 de outubro (91 Fed. Reg. 63129). As disposições operativas:

• A secção 1 define a política: na máxima medida permitida por lei, o poder executivo usa «SI» em vez de «AI» e «não reconhecerá» os termos antigos em qualquer contexto aplicável.
• A secção 2(a) aplica a regra à correspondência oficial, às comunicações públicas, aos sites, relatórios, documentos de política e outros documentos não legislativos.
• A secção 2(b) estabelece que nada nessa secção obriga a alterar regulamentos, atos presidenciais, contratos, subvenções ou outros documentos históricos existentes.
• A secção 3(a) define «SI» por remissão para a definição legal de AI em vigor no 15 U.S.C. § 9401(3). A definição mantém-se até ser substituída por um ato presidencial ou por uma lei do Congresso.
• A secção 3(b) dá ao conselheiro científico da Casa Branca 60 dias para propor nova redação legislativa, que precisaria de uma ação separada do Congresso para entrar em vigor.
• A secção 4(c) estabelece que a ordem não cria direitos executórios.

Redação rígida, pouco efeito jurídico

A linguagem da ordem é mais rígida do que o seu efeito. A secção 1 diz que o poder executivo «não reconhecerá» o termo AI em qualquer contexto aplicável, mas a própria ordem usa «artificial intelligence» e ancora a sua definição de SI no 15 U.S.C. § 9401(3). Todas as obrigações se aplicam apenas «na máxima medida permitida por lei» e apenas a documentos não legislativos, pelo que leis, regulamentos, contratos e subvenções continuam a dizer AI.

A secção 3(a) faz com que SI signifique exatamente o mesmo que AI significa hoje, e a secção 4(c) não cria direitos executórios. Os advogados da Arnold & Porter observam que a ordem não tem nenhuma disposição sancionatória nem de execução. A publicação do presidente de 8 de outubro, que chamava «O INIMIGO» a quem diga «Artificial Intelligence», foi mais longe do que a ordem, e a ordem não prevê consequências para isso. As agências mudam o vocabulário. A tecnologia e a sua regulação ficam como estavam.

É este todo o alcance da ordem: um exercício de comunicação e uma regra de vocabulário para os documentos de um governo. Os agentes já ligados a sistemas de produção, com as credenciais que já têm, são indiferentes à palavra que aparece nesses documentos.

O que é realmente a shadow AI agêntica

A shadow AI agêntica é a utilização não autorizada ou não supervisionada de agentes autónomos dentro de uma organização. Estes agentes planeiam e encadeiam ações por si próprios, têm as suas próprias credenciais e funcionam sem que uma pessoa aprove cada passo. Ao contrário da shadow IT ou da shadow AI em geral, não precisam de ninguém ao teclado para agir.

A shadow IT tradicional é um colaborador que adota uma ferramenta, como uma aplicação de sincronização de ficheiros ou um gestor de projetos, sem passar pelo departamento de compras. A shadow AI em geral, a que a maioria dos artigos sobre governação aborda, é um colaborador que cola dados num chatbot público. Em ambos os casos, uma pessoa faz uma escolha num dado momento, e ambos acabam por deixar rasto algures: um relatório de despesas, um log de utilização de SaaS, uma entrada no histórico do browser.

A shadow AI agêntica funciona de outra forma. Um agente só deixa rasto uma vez. Alguém liga um bot do Slack, uma integração de ferramentas de vendas ou um script que monitoriza um repositório de código e, a partir daí, o agente atua segundo o seu próprio calendário. Autentica-se com a sua própria chave de API, token OAuth ou conta de serviço. Um token emitido uma vez continua a funcionar até alguém o revogar, pelo que não há nenhuma decisão humana posterior que alguém possa notar ou assinalar.

Porque é que o MCP agrava o problema

Os agentes criados com o Model Context Protocol (MCP) acedem a ferramentas e fontes de dados através da credencial com que a integração foi configurada, seja ela qual for. Herdam todo o acesso dessa credencial. Esse acesso é muitas vezes mais amplo do que a única tarefa para a qual o agente foi criado, e ninguém revê o âmbito depois de a integração funcionar.

Alguns fornecedores chamam a estes sistemas «shadow agents». Este artigo usa sempre «shadow AI agêntica». Os dois rótulos descrevem o mesmo problema: agentes autónomos que ninguém inventariou, com credenciais que ninguém vigia.

Porque é que a shadow AI agêntica é pior do que a shadow IT

A shadow AI agêntica é mais difícil de conter do que a shadow IT porque os agentes são ligados a sistemas reais mais depressa do que as organizações lhes atribuem responsáveis, limitam o âmbito das credenciais ou os inventariam. A shadow IT precisa de uma pessoa que continue a usar a ferramenta. Um agente de IA continua a trabalhar depois de o seu criador passar a outra coisa.

A lacuna é visível em três números publicados.

• A JumpCloud concluiu que 83 % das organizações gerem mais identidades não humanas (NHI), ou seja, contas de serviço, chaves de API e credenciais de agentes, do que utilizadores humanos. Apenas 21 % têm governação de acessos para essas identidades.
• A Cyberhaven Labs registou um aumento homólogo de 509 % na utilização empresarial de agentes de IA baseados em endpoints entre fevereiro de 2025 e fevereiro de 2026. Só os assistentes de programação cresceram 357 %.
• A Gartner previu em agosto de 2025 que 40 % das aplicações empresariais incluiriam agentes de IA para tarefas específicas até ao final de 2026, face a menos de 5 % em 2025.

A adoção está a acelerar e a governação cobre uma pequena parte das identidades envolvidas. A maioria das equipas não consegue responder de imediato à pergunta «a que é que esta credencial tem acesso?». Sem essa resposta, ninguém consegue limitar o âmbito da credencial, rodá-la ou revogá-la.

Quanto custa uma lacuna

O custo de uma violação dá ao problema um valor em dólares. O Cost of a Data Breach Report 2026 da IBM situa o custo médio global de uma violação em 4,99 milhões de dólares, um recorde e um aumento de 12 % face ao ano anterior. A IBM não atribui esse valor aos agentes, pelo que deve ser lido como o preço deste modo de falha, não como o preço da shadow AI agêntica.

Uma credencial sem responsável é a mesma falha, quer seja uma pessoa, quer seja um agente a tê-la. A diferença está na deteção. Uma pessoa que abusa do acesso deixa um evento de início de sessão. Um agente com um token válido produz tráfego que parece automação de rotina.

Dito de forma simples: as organizações estão a acumular identidades não humanas (NHI) e a ligar agentes a sistemas de produção muito antes de criarem os registos de responsáveis, a disciplina na definição de âmbitos e a monitorização.

Como surge a proliferação de agentes de IA nas organizações

Há sete vias que conduzem à proliferação de agentes (agent sprawl) em organizações com governação: ferramentas de desenvolvimento, pilotos que nunca terminam, agentes órfãos, feature flags de fornecedores, plataformas low-code, agentes pessoais e equipas de terceiros. Todas terminam com um agente que tem uma credencial que nenhum responsável central registou.

1. Ferramentas de desenvolvimento. Os assistentes de programação e os servidores MCP executados localmente funcionam com os tokens de repositório e as chaves de cloud que já estão na máquina do programador. Correm no endpoint, pelo que nenhuma consola de administração de SaaS os lista.
2. Um piloto que nunca terminou. Uma equipa configura um agente para resolver uma tarefa incómoda. Poupa horas, os colegas passam a depender dele e ninguém agenda a decisão de o aprovar ou desativar. A chave com que foi criado mantém o âmbito original.
3. Agentes órfãos. A pessoa que criou um agente muda de funções ou sai da empresa, e o agente continua a funcionar. Desativar a conta dessa pessoa no diretório não revoga necessariamente as autorizações OAuth e as chaves de API que criou. Verifique como se comporta cada um dos seus sistemas.
4. Uma feature flag numa ferramenta de confiança. Um fornecedor inclui um agente numa atualização de rotina e ativa-o para todos os tenants. O agente acede aos dados através de ligações que o produto já tem. A análise de segurança arquivada descreve o produto tal como era há um ano.
5. Plataformas low-code para criar agentes. Os utilizadores de negócio montam agentes em plataformas de fluxos de trabalho para as quais a empresa já tem licença. Cada ligação que o agente estabelece é criada com a identidade de quem o montou, pelo que o administrador da plataforma vê aplicações, não as credenciais por trás delas.
6. Um agente pessoal. Um colaborador liga um assistente à sua caixa de correio, ao calendário ou a um repositório de código e deixa-o agir com as suas próprias permissões. Essas permissões foram concedidas para todo o trabalho da pessoa, pelo que o agente tem um alcance muito maior do que a sua única tarefa exige.
7. Equipas de terceiros e de empresas adquiridas. Uma agência, um consultor ou uma empresa recém-adquirida traz agentes que já funcionam com as suas próprias credenciais. Essas credenciais nunca passam pelo processo de integração da organização.

Duas violações de credenciais, com dez meses de intervalo

Dois incidentes identificados, com um ano de intervalo, mostram quanto custa realmente uma credencial de máquina sem governação. Em ambos os casos, um token OAuth ou uma chave de acesso esquecidos estavam ligados a uma integração relacionada com IA sem que ninguém os vigiasse, até um atacante os encontrar primeiro.

Salesloft Drift, agosto de 2025

O agente de ameaças UNC6395, acompanhado pelo Threat Intelligence Group da Google, explorou a integração do chatbot de IA Drift, da Salesloft, com o Salesforce para recolher tokens OAuth de acesso e de atualização. O Drift liga-se à instância do Salesforce do cliente para automatizar conversas de vendas, e essa ligação funciona com uma autorização OAuth permanente e não com um início de sessão pontual.

Assim que o UNC6395 obteve tokens válidos, o ataque avançou à velocidade da máquina: o grupo usou-os para consultar diretamente objetos do Salesforce e extrair todas as credenciais e dados de casos a que esses tokens davam acesso.

A partir daí, o atacante extraiu chaves de acesso da AWS, tokens do Snowflake, palavras-passe armazenadas e dados de casos de suporte dos ambientes ligados. O objetivo foi sempre a exfiltração de dados através de um canal de confiança, já autorizado, e não uma intrusão pela porta da frente. Um analista de ameaças da Google disse ao Cybersecurity Dive que mais de 700 organizações poderiam ter sido afetadas. A Cloudflare, a Zscaler e a Palo Alto Networks confirmaram estar entre elas.

Klue, junho de 2026

A 11 de junho de 2026, um atacante usou um token de acesso pessoal do GitHub para introduzir código não autorizado no serviço de integração da Klue. O código recolheu os tokens OAuth de acesso e de atualização que os clientes tinham concedido à aplicação Klue Battlecards. Com esses tokens, o atacante consultou os tenants do Salesforce dos clientes e exportou contactos, oportunidades, orçamentos e notas de vendas.

Segundo o resumo da investigação da CrowdStrike para a Klue, citado pelo NHI Management Group, o token tinha sido «previamente comprometido». A Huntress descreve-o como um token sem uso há muito tempo, mas ainda ativo. A Klue disse ao TechCrunch que o token foi emitido para um terceiro em 2022, para um piloto limitado. A Salesforce alertou a Klue a 12 de junho, e a Klue revogou os tokens e rodou as credenciais nessa manhã. O grupo de extorsão Icarus reivindicou o ataque.

A Klue não publicou o número de vítimas. Pelo menos onze empresas tinham confirmado impacto até 25 de junho, entre elas a Huntress, a Recorded Future, a Tanium, a Jamf, a Gong, a HackerOne, a Snyk, a OneTrust, a Insurity e a Sprout Social. Um segundo grupo de extorsão reivindicou 195 clientes, uma alegação que não está verificada.

O que os dois incidentes têm em comum

Os pontos de entrada são diferentes. Na Klue, foi um token antigo de controlo de código-fonte. As fontes sobre o Drift descrevem a utilização de tokens OAuth roubados, mas não a forma como foram obtidos. A exposição comum é uma credencial não humana com acesso permanente a dados de clientes, detida por um fornecedor e utilizável sem qualquer evento de início de sessão. O tráfego de um token válido parece o da própria integração.

O token da Klue continuou válido durante cerca de quatro anos depois do fim de um piloto. Os tokens do Drift continuaram válidos até alguém os revogar.

Riscos da shadow AI agêntica

A shadow AI agêntica cria cinco riscos: credenciais de longa duração expostas, atividade que parece tráfego normal, Excessive Agency, encadeamento de credenciais entre agentes e lacunas de conformidade. Todos têm a mesma causa. O agente atua por conta própria com uma credencial que ninguém inventariou, limitou ou reviu.

Credenciais de longa duração que sobrevivem ao seu propósito

Um agente continua a funcionar enquanto a sua chave ou token for válido, e nada no agente obriga a uma revisão. As credenciais de pilotos raramente são rodadas e mantêm muitas vezes o âmbito alargado que tinham durante os testes.

A Klue é o caso mais claro. Segundo o relato da própria empresa, um token emitido em 2022 para um piloto limitado continuava válido quando os atacantes o usaram em junho de 2026. Ninguém tinha decidido mantê-lo. Mas também ninguém tinha decidido retirá-lo.

Atividade que parece tráfego normal

Um agente autentica-se com a sua própria chave de API ou token OAuth, pelo que não existe nenhum evento de início de sessão humano a assinalar. Os seus pedidos vêm de uma integração conhecida, a intervalos regulares, através de API aprovadas. As regras de deteção criadas para palavras-passe de utilizadores roubadas não têm nada a que corresponder.

Por isso, a perda de dados através de um agente tende a ser detetada tarde. O primeiro sinal é muitas vezes um aviso do fornecedor ou uma fatura invulgar, e não um alerta no SIEM.

Excessive Agency

Os agentes que acedem a ferramentas e dados através do MCP herdam as permissões da conta de serviço que os suporta. Essas permissões são normalmente concedidas para um vasto leque de tarefas, e não para a única que o agente executa. Essa diferença é a superfície de ataque.

O OWASP classifica este padrão como Excessive Agency (LLM06:2025) no seu Top 10 para aplicações de LLM. Um agente que lê conteúdo não fiável, como um e-mail ou uma página web, pode ser levado a usar acessos que nunca deveria ter tido. Âmbitos restritos limitam o que uma injeção bem-sucedida consegue alcançar.

Encadeamento de credenciais entre agentes

Quando um agente chama outro, o agente a jusante recebe muitas vezes a credencial do agente a montante ou um token derivado dela. Um comprometimento no agente mais fraco abre então tudo aquilo a que o mais forte tem acesso. Os agentes não registados agravam o problema, porque ninguém mapeou que agente confia em qual.

Lacunas de conformidade e auditoria

Um agente não inventariado processa dados fora dos registos e controlos da organização. O artigo 32.º do RGPD exige «medidas técnicas e organizativas adequadas» para proteger os dados pessoais, e uma credencial sem responsável dificilmente se pode defender como tal. O artigo 21.º da Diretiva NIS2, n.º 2, alínea i), inclui as políticas de controlo de acessos e a gestão de ativos entre as medidas de gestão de riscos exigidas.

Governar a shadow AI agêntica: A lista de verificação de credenciais de agentes em 5 passos

A lista de verificação de credenciais de agentes em 5 passos governa a shadow AI agêntica através das credenciais com que os agentes funcionam. Encontrar cada agente e os seus segredos, atribuir a cada um uma identidade própria com âmbito limitado, nomear um responsável de negócio e um responsável técnico, definir limites de execução e, por fim, registar, testar e revogar de forma periódica.

Passo 1. Descobrir os agentes através das credenciais que têm

Os agentes passam facilmente despercebidos, mas as suas credenciais deixam registos nos sistemas em que tocam. Procure primeiro nestes locais:

• autorizações OAuth e aplicações ligadas em cada consola de administração de SaaS
• contas de serviço e service principals no fornecedor de identidade e nas contas de cloud
• cofres de segredos, variáveis de repositório e definições de CI/CD
• listas de consumidores do gateway de API
• endpoints: assistentes instalados, extensões do browser e ficheiros de configuração do Model Context Protocol (MCP)

Para cada agente, registe aquilo a que pode aceder, que ferramentas ou API chama, que dados lê ou escreve e quem o ativou. A primeira passagem será incompleta. Repita-a periodicamente, porque os novos agentes surgem mais depressa do que as revisões trimestrais.

Passo 2. Atribuir a cada agente uma identidade própria e limitar o seu âmbito

Um agente nunca deve funcionar por trás de uma conta partilhada ou do início de sessão pessoal de um colaborador. Crie uma identidade por agente, associada à respetiva carga de trabalho. Depois, retire as permissões alargadas que o agente acumulou durante os testes, para que o acesso corresponda à única tarefa que executa em produção.

A mesma regra aplica-se aos agentes que chamam outros agentes. Cada agente autentica-se por si próprio, e a credencial de um agente nunca é passada a outro.

No Passwork, uma conta de serviço é uma conta não interativa criada para automação. Uma conta de serviço pode ter vários tokens de API com âmbito limitado, pelo que cada agente ou pipeline recebe o seu. As políticas de cofres definem quem administra cada tipo de cofre, pelo que um cofre para credenciais de agentes tem administradores corporativos desde a criação. Rodar uma credencial não interrompe os pipelines que dependem da conta.

Teste tokens de contas de serviço com âmbito limitado e políticas de cofres nas credenciais dos seus próprios agentes. Experimentar o Passwork grátis na própria infraestrutura.

Passo 3. Nomear um responsável de negócio e um responsável técnico

Cada credencial precisa de duas pessoas. O responsável de negócio assume a responsabilidade pela finalidade do agente e pelo risco que é tolerável. O responsável técnico trata do acesso em execução, do registo de logs e da manutenção. Sem ambos, ninguém consegue dizer se uma credencial ainda deve existir.

A Klue mostra o custo de um campo de responsável vazio. Segundo o relato da própria empresa, um token emitido em 2022 para um piloto limitado continuava válido quando os atacantes o usaram em junho de 2026. Guarde os responsáveis, a finalidade e uma data de revisão junto da credencial. Quando um responsável muda de funções ou sai, reatribua a credencial no mesmo pedido.

Passo 4. Definir limites de execução antes de o agente entrar em produção

Registe por escrito o que o agente pode fazer e o que nunca pode fazer, e ajuste a profundidade da revisão ao seu grau de autonomia. Um agente que apenas lê um calendário precisa de uma lista de verificação curta. Um agente que movimenta dinheiro ou escreve em sistemas externos precisa de uma análise de risco formal e de uma aprovação.

Quando o agente estiver em funcionamento, aplique os limites fora da sua própria camada de raciocínio:

• restringir as ferramentas que pode chamar e validar o que entra e sai de cada chamada
• impedir que segredos e dados pessoais saiam através de carregamentos ou da área de transferência
• exigir aprovação humana para pagamentos, alterações de permissões e escritas em API externas

Proibir todas as ferramentas não aprovadas empurra o trabalho para fora do campo de visão. Ofereça uma via autorizada que seja mais rápida do que a alternativa improvisada, como uma plataforma interna de agentes com estes limites já incorporados.

Passo 5. Registar, testar e desativar

Envie a atividade dos agentes para o SIEM. No Passwork, o registo de atividade regista quem leu ou alterou uma credencial e exporta para Syslog ou para um SIEM. Configure alertas para um token usado a partir de uma nova origem ou com um volume invulgar.

Dois exercícios mostram se os controlos funcionam:

1. Teste de rastreio: escolher uma ação automatizada e segui-la até à pessoa que a autorizou e aos dados que utilizou.
2. Exercício de revogação: medir quanto tempo é necessário para cortar o acesso de um agente em todos os sistemas em que toca.

Reveja cada agente na respetiva data de revisão. Procure permissões que tenham crescido desde o lançamento, rode as suas credenciais e desative os agentes que já não têm finalidade. O Threat Intelligence Group da Google deu aos clientes o mesmo conselho depois da violação do Drift: rever as integrações ligadas e, em seguida, revogar e rodar as respetivas credenciais.

Conclusão

O rótulo mudou a 29 de setembro de 2026. O risco subjacente não mudou. A shadow AI agêntica, um agente autónomo com uma credencial ativa, nunca rodada e sem responsável, era exatamente tão perigosa na véspera da Executive Order 14434 como no dia seguinte. O Salesloft Drift e a Klue, com um ano de intervalo, já o provaram duas vezes.

Comece esta semana pelo primeiro passo da lista de verificação acima: um inventário completo de que agentes têm que credenciais. Nada mais na lista funciona enquanto esse inventário não existir, porque não é possível limitar o âmbito nem rodar o que ainda não foi encontrado. É também o único passo que qualquer equipa de segurança pode iniciar hoje, sem esperar por orçamento, por uma nova plataforma ou por uma revisão de políticas motivada por uma ordem federal que nada tem a ver com as credenciais que estão neste momento no seu ambiente.

A higiene de credenciais dos agentes de IA começa da mesma forma que a dos colaboradores: saber que acessos existem, quem é o responsável e quando foram rodados pela última vez. Experimentar o Passwork grátis.

Perguntas frequentes

Passwork 7.7: Modo offline seguro para aplicações de desktop e móveis

As palavras-passe também funcionam offline. O Passwork 7.7 traz acesso offline seguro com supervisão total por parte do administrador, controlos de anexos de ficheiros em toda a organização e cinco novos guias de integração por função para uma implementação mais fluida.

PassworkPasswork Team

Passwork 7.6: Contas de serviço

A mais recente versão do Passwork acrescenta contas de serviço compatíveis com vários tokens de API, filtros guardados, interface web móvel e limpeza automática do Lixo. Veja o que mudou.

PassworkPasswork Team

O que é a shadow AI: A ameaça oculta que custa às empresas 670 000 dólares por violação

A shadow AI custa às empresas mais 670 000 dólares por violação, e a maior parte deve-se a credenciais coladas em LLM públicos. Saiba como é realmente a shadow AI, porque é mais difícil de travar do que a shadow IT e como governá-la.

PassworkAlex Muntyan