Seus endpoints estão executando agentes de IA que você não consegue ver

O que é IA paralela no endpoint?

Shadow AI no endpoint refere-se a softwares de IA locais, LLM e integrações de servidor Model Context Protocol (MCP) implantadas diretamente no hardware do funcionário sem processos de aquisição, avaliação de segurança ou governança de identidade. Embora a IA baseada em navegador apresente riscos de vazamento de dados, os agentes de IA de endpoint interagem diretamente com sistemas de arquivos locais e sistemas SaaS por meio de servidores MCP em segundo plano.

O risco não se limita mais apenas a agentes que se conectam por meio de navegadores. Agora, todos os funcionários podem executar vários agentes de IA em seus laptops. É tão fácil que já não se limita apenas a funções técnicas. Qualquer pessoa pode fazer isso. 

Esses agentes aumentam a velocidade drasticamente, mas criam um problema complexo de identidade: nenhuma aplicação centralizada de identidade, nenhum escopo, nenhuma trilha de auditoria, nenhuma revisão de acesso. 

Como os servidores MCP expandem a superfície de ataque do endpoint

Os agentes de IA não agem sozinhos. Para realizar qualquer tarefa útil, um agente precisa de uma maneira de acessar diferentes sistemas, e hoje em dia isso quase sempre significa o servidor MCP. É o tecido conjuntivo entre um agente e tudo o que ele pode tocar.

Conectar esses agentes aos aplicativos mais sensíveis da sua organização por meio de um servidor MCP requer apenas alguns cliques. O agente reside no dispositivo, mas realiza chamadas que chegam diretamente ao seu CRM, apps SaaS, infraestrutura em nuvem e muito mais.

A Fundação OWASP documenta o "envenenamento de ferramentas MCP" como um vetor de ataque crítico, observando que, como as descrições das ferramentas geralmente são revisadas apenas na conexão inicial, um servidor MCP controlado por um invasor ou comprometido pode alterar os metadados da ferramenta em tempo de execução. Uma vez conectadas, as definições de ferramentas modificadas são carregadas na janela de contexto do modelo para sequestrar a execução e exfiltrar dados.

Em caso de incidente, sua equipe de segurança consegue identificar esses agentes, quem os controla e a quais apps e dados eles têm acesso? Muitos não conseguem.

E se você não consegue responder a isso, também não consegue responder à primeira pergunta do plano para a empresa segura baseada em agentes: Onde estão meus agentes?

Multiplique isso por todos os dispositivos, e a exposição se acumula rapidamente.

Como agentes de IA não monitorados conseguem burlar os controles de segurança corporativos?

Agentes de IA locais contornam os controles de segurança Enterprise usando conexões MCP não revisadas, herdando permissões de usuários humanos sem identidades de agentes distintas, mantendo acesso permanente e executando modificações em ferramentas de tempo de execução — tudo isso sem gerar registros de auditoria de TI centralizados.

Por trás dessas vulnerabilidades reside uma única causa raiz: a falta de visibilidade dos endpoints. Quando as equipes de segurança não conseguem visualizar os agentes de IA ou os servidores MCP aos quais eles se conectam, as estruturas padrão de gerenciamento de identidade e acesso falham. 

Aqui estão as cinco principais maneiras pelas quais os agentes podem burlar seus controles.

1. Os servidores MCP conectam agentes a sistemas empresariais sem o seu conhecimento

Criar e conectar servidores MCP que alcançam sistemas sensíveis é bastante fácil, e usá-los resume-se a executar um único comando no terminal. Conectar um agente de endpoint não aprovado aos seus aplicativos, por exemplo, ao seu locatário do Snowflake, leva apenas alguns minutos. Esse agente de IA agora reside em seu sistema mais sensível e pode consultar todas as tabelas que consegue visualizar sem sua aprovação ou conhecimento.

A promessa de aumento de produtividade leva seus funcionários a conectar esses servidores a agentes de IA sem pensar nas implicações de segurança.  

Quando as medidas de segurança não conseguem acompanhar o ritmo, as conexões críticas permanecem sem monitoramento e sem revisão. Isso significa que uma conexão com seus dados mais sensíveis pode permanecer lá indefinidamente, sem que ninguém seja responsabilizado pelo que ela acessa e sem nenhum registro para verificar quando algo eventualmente der errado. Isso é uma violação prestes a acontecer.

2. Os dados transitam entre sistemas que nunca foram revisados centralmente

Um agente movimenta dados com base em seu próprio julgamento sobre o que é útil para a tarefa em questão. Essa decisão não leva em consideração a classificação dos seus dados, as regras de residência ou quem tem permissão para ver o quê. Ninguém aprovou essa decisão. Não existe uma política que regule o que o agente pode acessar, então ele acaba conectado a vários sistemas ao mesmo tempo, e essa combinação é o que cria o risco. 

Por exemplo, o mesmo agente que consegue ler dados de clientes também pode ser capaz de enviar e-mails para qualquer pessoa. É assim que funcionam as permissões amplas, dando aos seus agentes a capacidade de visualizar mais dados do que o necessário para concluir uma única ação. Resultado: basta um único prompt comprometido para desencadear uma violação de segurança grave.

3. Os agentes atuam por meio do acesso de outra pessoa, sem identidade própria

Normalmente, os agentes se autenticam nos sistemas por meio de uma concessão OAuth ou de uma chave de API armazenada no arquivo de configuração do servidor MCP. Uma vez que a informação esteja lá, não há uma maneira confiável de determinar se uma ação partiu da pessoa ou do agente agindo em seu nome. Eles estão unidos pela mesma identidade. Então, quando algo dá errado, você não consegue responder à primeira pergunta que qualquer um fará: Foi a pessoa ou o agente?

Por exemplo, um agente de um funcionário da área contábil atualiza o registro de pagamento de um fornecedor durante a noite. O registro mostra que a alteração partiu das credenciais do funcionário, mas não há como saber se foi o próprio funcionário ou seu representante que a fez, nem se ela foi revisada.

Responder à pergunta sobre quem agiu significa extrair registros de todos os sistemas que o agente acessou e comparar manualmente os registros de data e hora em formatos que nunca foram projetados para se comunicarem entre si. O que deveria levar minutos acaba se transformando em dias gastos reconstruindo uma única ação em sistemas desconectados.

4. Os agentes pedem permissão apenas uma vez e obtêm acesso permanente.

Até alguns meses atrás, a maioria de nós ainda desconfiava do que os agentes de IA estavam fazendo. Parávamos e verificávamos sempre que um agente precisava de permissões adicionais ou queria acessar uma API do sistema. Agora, deixamos que funcionem de forma autônoma. As ferramentas agênticas incluem modos automáticos nos quais o agente continua a executar chamadas de ferramentas por conta própria, com regras de permissão e negação que você configura uma única vez.

Considere este exemplo: um funcionário atribui ao seu agente uma tarefa complexa e demorada e a configura para ser executada automaticamente. Em algum ponto do processo, o agente decide por conta própria que alterar os registros no Salesforce ou no Snowflake é a maneira correta de concluir a tarefa e o faz. O funcionário nunca aprovou essa ação específica e pode nem mesmo ter percebido que ela ocorreu. Ninguém revisa a mudança até que algo quebre ou pareça errado.

5. O servidor MCP concede aos agentes acesso que você não controla

Um servidor MCP fornece ao seu agente uma lista de ferramentas, cada uma com uma descrição explicando quando e como usá-la. Quem escreveu esse servidor escreveu essas descrições, não suas equipes de TI e segurança. Seu usuário viu um nome em um menu e clicou em “Aprovar”, sem verificar quem construiu o servidor ou o que ele executa.

E as descrições não são fixas. Se o proprietário do servidor MCP editar uma descrição, alterar uma permissão ou adicionar uma ferramenta, seu agente receberá a alteração automaticamente, sem necessidade de nova aprovação ou revisão. O que foi executado na segunda-feira não é necessariamente o que é executado na sexta-feira.

Eis um exemplo: um funcionário adiciona uma ferramenta para seu agente. O proprietário do servidor MCP envia uma atualização que altera seu comportamento. Na próxima vez que o agente se conectar, ele herdará a nova funcionalidade sem alertas ou necessidade de uma segunda aprovação.

Como as equipes de segurança podem descobrir e proteger a IA oculta em endpoints com o Okta for AI Agents

Você não pode definir o escopo, revisar ou revogar um agente que nunca viu, e não pode confiar totalmente em um agente que não esteja sob Identity Governance. 

O Okta for AI Agents foi desenvolvido para preencher essa lacuna.

1. Descoberta de endpoints: visualize cada agente e servidor MCP em execução no endpoint

A Okta se integra com sensores de endpoint existentes, agora disponíveis com o CrowdStrike Falcon EDR, para descobrir agentes de IA e servidores MCP conectados. Não são necessários agentes de endpoint adicionais. Isso amplia a cobertura de descoberta do Okta para agentes que são executados fora do navegador e que, de outra forma, não seriam detectados por meio de concessões de consentimento OAuth. O Okta Verify é a próxima fonte que estamos online, portanto a descoberta de endpoint não depende de nenhum EDR específico, com suporte para plataformas EDR adicionais planejado para depois.

2. Cadastre-se como identidades de primeira classe: inscrição centralizada no diretório

Os agentes são cadastrados no Universal Directory juntamente com suas outras identidades não humanas, agentes de IA e até mesmo identidades humanas. A cada agente é atribuída uma identidade única. Com ela, você pode definir o que esse agente pode acessar e obter uma trilha de auditoria completa.

3. Mapeamento e correlação de identidades: vinculação de agentes a proprietários humanos

Os agentes descobertos são vinculados à conta humana autenticada específica, fornecendo às equipes de segurança visibilidade completa das entidades humanas e não humanas em um só lugar. Esse mapeamento também se mantém válido mesmo com mudanças: à medida que os proprietários mudam de função ou se desligam da empresa, e à medida que subagentes são criados em uma cadeia de delegação, o contexto de propriedade permanece correlacionado, em vez de se perder.

4. Autorização em tempo de execução: aplicação de políticas no ponto de ação

Com o agente Gateway, imponha a política de acesso sempre que uma chamada de ferramenta for executada, e não apenas uma vez na configuração. Os agentes possuem apenas tokens de curta duração, em vez de credenciais permanentes, e o acesso pode ser revogado instantaneamente no gateway, sem precisar esperar pela próxima revisão de acesso para detectar alterações.

5. Governança de acesso contínua: análises de acesso e revogação de acesso

Realize revisões periódicas de acesso que incluam agentes juntamente com identidades humanas, para que as equipes de segurança possam comprovar aos auditores que o acesso de cada agente foi revisado e aprovado. E quando um agente se desvia do padrão ou é comprometido, um mecanismo de desativação o desabilita e interrompe novos acessos em todos os sistemas conectados a ele.

Assuma o controle da IA da sua empresa

Obtenha o guia para a Enterprise com agentes seguros e saiba mais sobre como dimensionar a IA da sua Enterprise com segurança.

Disponibilidade: o recurso Shadow AI agente descoberta para endpoints já está disponível em acesso antecipado para clientes do Identity Security Posture Management e do Okta for AI Agents por meio da integração com o CrowdStrike Falcon EDR. Se você já utiliza o CrowdStrike, o sensor que você possui é a fonte, e nada de novo é enviado para o endpoint.

Estes materiais são destinados apenas para fins informativos gerais e não constituem aconselhamento jurídico, de privacidade, conformidade com a segurança ou de negócios. Você é responsável por obter aconselhamento de segurança, privacidade, conformidade ou negócios dos seus próprios consultores profissionais. Qualquer menção a produtos, recursos, funcionalidades ou certificações futuras neste blog tem caráter meramente informativo. Esses itens não representam compromissos de entrega e não devem ser considerados para fins de decisão de compra. © Okta, Inc. e/ou suas afiliadas 2026.