A primeira onda de preocupação das empresas com inteligência artificial era simples. Era apenas funcionários colando dados sensíveis em ferramentas de IA públicas. As equipes de segurança responderam com políticas de uso, bloqueios de domínio e regras de DLP (Prevenção de Perda de Dados). Na época, essa resposta fazia sentido.
Hoje, ela não se encaixa mais no problema.
A IA sombra (do inglês Shadow AI) deixou de ser uma preocupação de vazamento de dados e passou a ser um problema de controle de acesso. A ameaça não está no que os funcionários digitam nas ferramentas de IA, mas em quais agentes de IA estão rodando dentro da organização, a quais sistemas corporativos eles estão conectados e quais ações estão autorizados — ou não — a executar.
De ferramentas passivas a atores ativos
Funcionários e áreas de negócio estão criando agentes de IA em um ritmo que a maioria das equipes de segurança não consegue acompanhar. Assistentes personalizados, agentes de codificação, automações de fluxo de trabalho e aplicações agênticas estão sendo criados em diferentes departamentos — alguns em plataformas autorizadas, mas muitos por meio de extensões de navegador, recursos nativos de SaaS (Software como Serviço), ferramentas de desenvolvimento, servidores MCP (Protocolo de Contexto de Modelo), agentes em endpoints e scripts personalizados. Muitos começam como experimentos rápidos. Alguns se tornam parte de processos críticos de negócio em poucos dias.
O perfil de risco desses agentes é fundamentalmente diferente do shadow IT (uso não autorizado de TI — Tecnologia da Informação) tradicional. Um aplicativo SaaS não autorizado é um destino para os dados. Um agente de IA é um ator que pode chamar APIs (Interfaces de Programação de Aplicações), usar credenciais armazenadas, recuperar registros, modificar configurações, disparar fluxos de trabalho a jusante e executar ações em sistemas de produção, frequentemente sem que um humano autorize explicitamente cada etapa.
Um funcionário que cola o registro de um cliente em uma ferramenta de IA pública provoca um incidente de vazamento de dados. Um agente de IA personalizado conectado a Salesforce, Snowflake, GitHub, Gong e Slack é um incidente de controle de acesso esperando para acontecer. Ele pode expor dados, mas também realizar ações de leitura, escrita e exclusão sobre esses dados. Além disso, pode rodar em contas de serviço com permissões que ninguém auditou e permanecer ativo seis meses depois que o funcionário que o criou mudou de função ou deixou a empresa. Uma nova pesquisa da Token Security e da Cloud Security Alliance mostra exatamente quão disseminada essa exposição se tornou.
Por que os controles existentes não alcançam o problema
A maioria dos controles de segurança empresarial foi projetada para identidades humanas e cargas de trabalho determinísticas. Políticas de IAM (Gestão de Identidade e Acesso), regras de DLP e monitoramento de rede partem do pressuposto de comportamento previsível e de caminhos de acesso definidos. Os agentes de IA quebram essas premissas.
Um agente encarregado de resolver uma implantação com falha pode ler logs, consultar sistemas de monitoramento, modificar configurações de infraestrutura, abrir chamados, disparar pipelines de automação e notificar equipes de engenharia — tudo em sequência, usando as mesmas credenciais herdadas. Para evitar quebrar os fluxos de trabalho, os desenvolvedores concedem permissões amplas de antemão. Essas permissões se acumulam. Agentes herdam privilégios no nível do criador, acessos temporários se tornam permanentes, e as equipes de segurança e identidade perdem a visibilidade do que essas identidades estão realmente fazendo.
Bloquear domínios de IA pública não resolve nada disso. Quando um agente já tem credenciais para os sistemas da empresa, a fronteira já foi cruzada. A remediação automatizada de identidades não humanas é o que fecha essa lacuna.
Como é um inventário real de IA sombra
Descobrir a IA sombra exige olhar para os ambientes onde os agentes realmente vivem, como plataformas de IA, aplicativos SaaS com automação integrada, contas em nuvem, ferramentas de desenvolvimento, endpoints e provedores de identidade. Veja seis perguntas para definir se as equipes de segurança têm controle real.
- Onde os agentes estão sendo criados ou instalados? Isso inclui plataformas óbvias de IA, mas também assistentes de codificação, recursos agênticos nativos de SaaS, ferramentas locais de desenvolvimento e aplicações internas que adicionaram capacidades de IA de forma discreta.
- Quem é dono de cada agente e quem pode usá-lo? Sem propriedade, não há responsabilização. Um agente criado para uma equipe financeira de três pessoas e compartilhado pela organização carrega um perfil de risco muito diferente do de um agente restrito a um único usuário.
- A quais recursos e serviços o agente está conectado? Um agente pode parecer inofensivo no nível da plataforma enquanto mantém conexões com bancos de dados sensíveis ou sistemas de produção por meio de credenciais concedidas informalmente e nunca revisadas.
- Quais identidades e segredos ele utiliza? Os agentes se autenticam por meio de contas de serviço, chaves de API, tokens OAuth (protocolo aberto de autorização), perfis de IAM em nuvem e segredos de longa duração. Cada tipo de credencial carrega riscos diferentes.
- Qual é a intenção do agente e o que ele realmente fez? A configuração por si só não mostra se um agente está lendo dados, gravando registros ou acessando sistemas fora do escopo pretendido. Compreender a intenção e o contexto comportamental é necessário para priorizar a resposta.
- O agente ainda está ativo? Os dados do Agentic Pulse, da Token Security, mostraram que 65,4% dos chatbots agênticos nunca foram utilizados desde a criação, mas suas credenciais permanecem ativas. Agentes dormentes com acesso vivo representam uma exposição persistente e subestimada.
A curva de maturidade para garantir a segurança da IA agêntica
A maioria das organizações está no início desse processo e tem pouco ou nenhum inventário de agentes. O próximo passo é ganhar visibilidade parcial para saber quais agentes existem, mesmo sem contexto completo. Depois, é preciso enriquecer e contextualizar para entender a intenção e mapear propriedade, acesso e credenciais de cada agente. A etapa seguinte é aplicar a enforcement (aplicação) com controles automatizados que corrijam permissões excessivas, notifiquem donos de agentes inativos e sinalizem novos agentes se conectando a sistemas sensíveis.
O objetivo não é bloquear a adoção de IA. As equipes estão sob pressão real para usar essas ferramentas, e muitos dos ganhos de produtividade são legítimos. Se a segurança se tornar um bloqueador rígido, o uso migra ainda mais para a clandestinidade, fora do radar. O melhor desfecho é a habilitação governada: oferecer um caminho para que as equipes implantem agentes com controles automatizados rodando continuamente em segundo plano.
Isso exige tratar os agentes de IA da mesma forma que se trataria qualquer outra identidade na empresa, com descoberta contínua, propriedade definida, acesso com escopo definido e gestão de ciclo de vida, da criação ao descomissionamento.
A pergunta sobre IA sombra mudou. Não é mais: quais dados os funcionários estão colocando em IA? Agora é: quais agentes estão operando no nosso ambiente e a que demos acesso a eles? São perguntas diferentes. A segunda é a que define a exposição e o risco de uma organização. Se você está trabalhando nesse inventário agora, vale a pena ver como outros estão abordando o tema.
