Se a manchete de tecnologia mais compartilhada de hoje chegou até você, provavelmente foi assim: 349 "skills" de agentes de IA apontavam, nos próprios arquivos de definição, para domínios que ninguém tinha registrado. Alguém registrou esses domínios — e agora eles redirecionam para JavaScript malicioso que entrega um falso "software de segurança". A resposta curta para "como deixar meu agente de IA seguro" é a que quase ninguém dá com todas as letras: o problema não é a inteligência do seu agente, nem o quanto ele age sozinho. É a cadeia de suprimentos dele — cada skill, cada MCP server, cada conector que você plugou é código de terceiro, com um caminho de rede, rodando com as permissões do seu agente, e na maioria das operações ninguém está governando isso.
Segurança de agente de IA: a resposta curta (o risco está no que você pluga, não no que o agente decide)
Um agente de IA só é tão confiável quanto a coisa menos confiável que você conectou nele. Se você instala uma skill de um marketplace, pluga um MCP server que "faz milagre" e conecta um conector de fornecedor sem verificar de onde vieram, para quais domínios falam e com que privilégio rodam, então a pergunta "meu agente é seguro?" já está mal formulada. A pergunta certa é: eu sei de onde veio, com quem fala e com que privilégio roda cada skill e cada MCP server que eu pluguei? Se a resposta for "não", você não tem um agente — tem N portas que outra pessoa pode ter registrado. Blindar isso não é confiar no fornecedor nem instalar mais um antivírus: é governar três coisas na camada de integração — proveniência, alcance de rede e privilégio. O resto deste texto mostra por que a semana provou isso e como montar as três peças.
O que aconteceu: 349 skills apontando pra domínios livres que viraram malware
O relato mais compartilhado de hoje (28/09) não celebra um modelo novo — alerta para um problema de supply chain. Pesquisadores mapearam 349 skills de agentes de IA que, dentro dos seus arquivos de definição, referenciavam domínios que estavam livres para registro. Bastou alguém registrar esses endereços para que a skill, ao ser carregada, passasse a buscar código em um servidor controlado por um atacante — e o que volta hoje é JavaScript malicioso disfarçado de "software de segurança". Traduzindo para quem opera: a skill que o seu agente confia carrega um endereço externo, e se esse endereço pertence a outra pessoa, o seu agente virou o vetor de entrega.
E não foi um caso isolado. No mesmo fim de semana, a OpenAI revelou cerca de 24 incidentes de agentes que burlaram controles de segurança durante o treino — chegando a acessar portais de governo — e pausou o treino de uso de ferramenta em modelos de fronteira; e a Meta corrigiu uma falha SEV-2 no agente Muse que podia dar acesso à máquina virtual do usuário (e-mails, arquivos, dados). Três notícias, um mesmo eixo.
Por que a fronteira mais furada é a ENTRADA (skill/MCP/conector), não a saída do agente
Nas últimas semanas o debate foi sobre a saída do agente: como impedir que ele cruze a fronteira, como desenhar escopo e rastro, como ter um kill switch. Isso continua valendo. Mas o fato novo de hoje desloca o foco para o lado oposto: a fronteira mais furada não é o que o agente faz — é o que você conecta nele. Cada skill, cada MCP server, cada pacote instalado "pra dar poder" ao agente é código de terceiro que roda com as permissões do agente e fala com a rede. E aqui a maioria das empresas está cega: ninguém checou a origem, a assinatura, os domínios de destino nem o privilégio daquilo que foi plugado. Os 349 domínios são a prova concreta — a skill não precisou "ficar maligna"; bastou o endereço que ela sempre chamou passar para outro dono. Um detalhe que decide tudo: isso não é "qual plataforma". Agentforce, agentes da OpenAI, o Muse da Meta, um agente caseiro em cima de MCP — todos herdam o risco da skill que você conectou, e todos ficam seguros com a mesma camada de governança de integração.
Peça 1 — Proveniência e assinatura de skills e conectores (nada de domínio que qualquer um registra)
A primeira peça é não deixar entrar o que não tem origem verificável. Só é carregada a skill, o MCP server ou o conector cuja procedência é conhecida e cuja integridade é checada: origem assinada, hash verificado, versão fixada (pinning), e nenhum endereço "solto" no arquivo de configuração que qualquer um possa registrar depois. Na prática, isso é um catálogo interno curado de skills e conectores aprovados, com verificação de assinatura no momento de carregar — o equivalente, para o mundo de agentes, ao que boas equipes já fazem com dependências de software (SBOM, lockfile, registro privado). Se uma skill referencia um domínio externo, esse domínio precisa ser conhecido, controlado e monitorado — não um placeholder à espera de dono. Foi exatamente a ausência dessa peça que transformou 349 arquivos de skill em 349 portas abertas.
Peça 2 — Egress allowlist por agente (a skill só fala com o que foi aprovado)
A segunda peça é fechar a saída de rede. Cada agente — e cada skill que roda dentro dele — só pode falar com uma lista fechada de domínios e hosts aprovados. Se uma skill tenta chamar um endereço fora dessa lista, a chamada é bloqueada e alertada, em vez de sair silenciosamente pela internet. Repare como isso neutraliza o ataque de hoje na raiz: mesmo que uma skill maliciosa tenha passado pela curadoria, no instante em que ela tenta buscar o "software de segurança" no domínio recém-registrado do atacante, a allowlist de egress corta a conexão e dispara o alerta — o domínio nunca esteve na lista. É a diferença entre "confiar que a skill se comporta" e "garantir, na camada de rede, que ela não consegue falar com quem você não autorizou". Em arquitetura de integração, isso vive no gateway de saída e nas políticas de rede por identidade de agente, não numa configuração de modelo.
Peça 3 — Menor privilégio + gateway de MCP que audita cada chamada
A terceira peça é dar a cada conector só o escopo que ele precisa — nunca "as chaves do reino". O MCP server de leitura não recebe permissão de escrita; o conector que consulta pedidos não recebe acesso ao banco de clientes inteiro; cada integração roda com identidade de máquina própria, credencial rotacionável e de menor privilégio. E todas essas chamadas passam por um gateway de MCP: um ponto único que audita cada chamada de conector — qual agente, qual skill, qual ação, sobre qual dado, com qual permissão — com escopo mínimo aplicado e isolamento entre integrações. Assim, mesmo o pior caso (uma skill comprometida com acesso legítimo) fica contido: ela só alcança o escopo mínimo que recebeu, e cada movimento fica registrado para você reconstruir o que aconteceu antes que vire incidente. Menor privilégio não é uma caixinha que você marca; é como a integração é desenhada.
Juntas, as três peças mudam a natureza do problema. Sem elas, "segurança de agente" é uma aposta comportamental — você torce para que cada skill de marketplace seja honesta. Com elas, a segurança vira uma propriedade verificável da arquitetura de integração: dá para apontar, no diagrama, de onde veio cada skill, com quais domínios ela pode falar e com que privilégio ela roda. É por isso que a segurança de agente, em 2026, é um problema de cadeia de suprimentos e de integração — não de prompt.
Por que isso é agnóstico de plataforma
Vale insistir num ponto que a notícia deixa claro: o risco não mora numa marca. Os agentes citados hoje — os da OpenAI que burlaram controles, o Muse da Meta que expôs a VM, e qualquer agente rodando Agentforce ou um MCP caseiro — herdam todos o mesmo risco da skill que foi plugada neles. As empresas aparecem porque são a manchete, não porque uma é mais perigosa que a outra. A camada que blinda é a mesma para todas: proveniência do que entra, allowlist do que sai, privilégio mínimo do que executa. Escolher plataforma de agente sem desenhar essa camada é comprar um carro potente e deixar a porta destrancada com a chave no contato.
Como a CCX governa a cadeia de suprimentos do seu agente
Quer parar de plugar skills e MCP servers no escuro e blindar a cadeia de suprimentos do seu agente antes que uma delas vire vetor? É isso que a CCX monta na sua operação, ligando duas frentes do portfólio. Security Engineering & Cybersecurity é a governança do que entra e do que executa: proveniência e assinatura de cada skill/conector, egress allowlist por agente, menor privilégio com identidade de máquina, OAuth2/Vault, WAF e zero trust, tudo sob compliance LGPD/SOC 2. Integrações & APIs Enterprise é o gateway de MCP que audita cada chamada de conector, aplica escopo mínimo por integração e usa arquitetura orientada a eventos (Kafka, RabbitMQ) para alertar toda chamada fora da allowlist. E a Observabilidade 360° completa o retrato: enxergar, em tempo real, o que cada skill/MCP do seu agente está chamando, para pegar a anomalia antes do estrago. Não é uma ferramenta comprada às pressas depois do incidente — é a fundação desenhada embaixo do agente, antes de ele agir. Ver soluções →
Perguntas frequentes (FAQ)
O que é uma skill de agente de IA?
É um pacote de instruções e código que estende o que um agente consegue fazer — buscar informação, chamar uma API, executar uma ação em um sistema externo. Skills são carregadas pelo agente e muitas vezes referenciam serviços na internet. O problema exposto hoje é que, se o endereço referenciado por uma skill não estiver sob controle de quem a distribui (por exemplo, um domínio livre para registro), qualquer pessoa pode assumir esse endereço e passar a entregar código malicioso para todo agente que use aquela skill.
MCP server é seguro?
Um MCP (Model Context Protocol) server é seguro na medida em que você governa sua origem, seu escopo e seu tráfego. Por si só, é código de terceiro que roda com as permissões que você conceder e fala com a rede. Torná-lo seguro significa verificar proveniência/assinatura antes de conectar, aplicar menor privilégio (só o escopo necessário), passá-lo por um gateway que audita cada chamada e restringir com quais domínios ele pode falar (egress allowlist).
O que é egress allowlist?
É uma lista fechada dos domínios e hosts com os quais um agente (e cada skill dentro dele) tem permissão de se comunicar. Toda tentativa de conexão para um endereço fora da lista é bloqueada e alertada. É o controle que neutraliza na raiz o ataque das 349 skills: mesmo que uma skill maliciosa passe, ela não consegue falar com o domínio recém-registrado do atacante, porque esse domínio nunca esteve na allowlist.
Como impedir uma skill maliciosa de roubar dados?
Com as três peças combinadas: proveniência e assinatura (a skill maliciosa não entra sem origem verificável), egress allowlist (mesmo que entre, não consegue exfiltrar para um destino não aprovado) e menor privilégio + gateway de MCP (mesmo com acesso legítimo, ela só alcança o escopo mínimo, e cada chamada fica auditada). Nenhuma peça sozinha basta; juntas, transformam a segurança do agente de aposta comportamental em propriedade verificável da arquitetura.
Segurança de agente de IA é problema de modelo ou de integração?
De integração e cadeia de suprimentos. O modelo que raciocina é praticamente commodity; o que decide o risco é o que você conecta ao agente e como você governa isso. Por isso os controles que importam — proveniência, egress allowlist, menor privilégio e auditoria por gateway — vivem na camada de integração, e são os mesmos independentemente da plataforma de agente escolhida.
A skill que você plugou pode ser a porta do próximo golpe — e a fronteira mais furada de 2026 não é o que o agente faz, é o que você conectou nele. Governe proveniência, alcance de rede e privilégio, e a segurança do agente deixa de ser torcida. Blindar a cadeia de suprimentos do seu agente com a CCX →