Segurança de agentes de IA começa na cadeia de software
- 29 de mai.
- 8 min de leitura
Atualizado: 3 de jun.
O caso mostrado na imagem é um alerta importante para qualquer empresa que esteja modernizando software, usando agentes de IA ou conectando LLMs a ferramentas corporativas por meio de MCPs. O incidente envolve versões falsas do pacote Sicoob.Sdk no NuGet, que teriam exfiltrado client IDs, certificados PFX e senhas, além de uma campanha paralela com pacotes npm criados para roubar segredos de AWS, Vault, npm e pipelines de CI/CD. Segundo a análise publicada pelo The Hacker News, as versões 2.0.0 a 2.0.4 do pacote malicioso foram baixadas quase 500 vezes e enviavam dados sensíveis para um endpoint externo.
O problema não está apenas no pacote falso. O risco maior é o modelo de confiança implícita que muitas equipes ainda usam: o desenvolvedor pesquisa uma biblioteca, encontra um pacote com nome plausível, instala no projeto, o CI/CD executa scripts automaticamente e o pacote passa a rodar dentro de um ambiente que pode conter tokens, variáveis de ambiente, certificados, chaves de nuvem e acesso a sistemas internos. A OWASP classifica esse tipo de risco como Dependency Chain Abuse, em que falhas na forma como estações de trabalho e ambientes de build buscam dependências permitem que pacotes maliciosos sejam baixados e executados localmente.
O que aconteceu e por que isso é grave
No caso do pacote falso relacionado ao Sicoob, o impacto potencial é sensível porque certificados PFX e client IDs são materiais de autenticação usados em integrações bancárias. Quando esse tipo de credencial é comprometido, o atacante pode tentar se passar pela integração legítima da empresa, acessar APIs, consultar dados ou abusar de fluxos financeiros.
O relatório recomenda remover o pacote, tratar o material PFX como comprometido, substituir certificados, rotacionar senhas e auditar logs de autenticação e APIs.
O mesmo artigo também menciona 14 pacotes npm publicados por um único ator, com nomes que imitavam bibliotecas de OpenSearch, Elasticsearch, DevOps e configuração de ambiente. Esses pacotes usavam hooks de instalação para coletar credenciais AWS, tokens do HashiCorp Vault, tokens npm e segredos de pipelines.
Essa combinação é perigosa porque ataca a cadeia de software em pontos de alta confiança: ambiente local do desenvolvedor, pipeline de build, registro de pacotes, gerenciador de dependências e credenciais de automação. Em muitos casos, o pacote malicioso não precisa explorar uma vulnerabilidade complexa. Ele só precisa ser instalado em um ambiente com permissões demais.
Por que isso muda a conversa sobre agentes de IA
Agentes de IA aumentam a superfície de ataque porque deixam de ser apenas assistentes de texto e passam a executar ações: consultar repositórios, abrir pull requests, chamar APIs, ler logs, disparar pipelines, acessar bancos de dados, operar cloud e interagir com ferramentas internas. Quando um agente tem acesso a um ambiente contaminado por uma dependência maliciosa, o impacto deixa de ser apenas “um pacote ruim no projeto” e passa a ser um risco operacional.
Um agente conectado a ferramentas corporativas pode acelerar tanto a entrega quanto o dano. Se ele tem permissão para instalar dependências, executar testes, gerar código, publicar artefatos ou operar infraestrutura, um pacote malicioso pode capturar tokens e usar essas credenciais para se mover pela cadeia de desenvolvimento. O risco cresce ainda mais quando o agente trabalha com contexto sensível: arquivos de configuração, variáveis de ambiente, manifests de Kubernetes, secrets de CI/CD, certificados, chaves de API e tokens de publicação.
A OWASP destaca que MCPs criam uma nova superfície de ataque porque agentes passam a executar ferramentas dinamicamente, com base em linguagem natural, e com acesso a sistemas sensíveis. Diferentemente de APIs tradicionais, onde cada chamada é definida diretamente pelo desenvolvedor, o MCP permite que o modelo decida quais ferramentas invocar, quando e com quais parâmetros.
Segurança de Agentes de IA: O impacto específico em MCPs
A segurança de agentes de IA que utlizam tais pacotes em MCPs fica comprometida e o impacto é no mínimo grave.
O MCP é uma camada poderosa porque padroniza a forma como agentes acessam ferramentas, dados e APIs. Esse é exatamente o seu valor. Mas também é o seu risco. Um MCP Server expõe capacidades para o agente: “consultar pedidos”, “abrir ticket”, “executar deploy”, “buscar cliente”, “rodar query”, “listar buckets”, “alterar configuração”. Se o servidor MCP, suas dependências ou seus conectores forem comprometidos, o agente pode passar a operar sobre uma base de confiança falsa.
Existem quatro impactos principais:
1. Roubo de credenciais do servidor MCP: Muitos MCP Servers precisam de tokens para acessar APIs, bancos, cloud, Git, Jira, CRM ou sistemas legados. Um pacote malicioso instalado no servidor pode tentar ler variáveis de ambiente, arquivos locais ou secrets montados no container.
2. Tool poisoning: Um servidor MCP malicioso ou alterado pode expor ferramentas com descrições enganosas. O agente acredita que está chamando uma ferramenta legítima, mas a ferramenta pode executar outra ação, coletar parâmetros sensíveis ou induzir o modelo a tomar decisões erradas.
3. Confused deputy: O agente ou MCP Server pode ser usado como intermediário para acessar recursos que o usuário final não deveria acessar. A documentação oficial de segurança do MCP cita o problema do confused deputy como um vetor relevante em servidores que fazem proxy para APIs de terceiros.
4. Propagação por automação: Agentes integrados a CI/CD podem criar branches, atualizar dependências, gerar PRs, executar builds e publicar pacotes. Sem políticas de aprovação, um pacote malicioso pode entrar no fluxo de entrega com aparência de mudança legítima.
Como evitar o roubo de credenciais na cadeia de suprimentos de software
A primeira mudança é tratar dependência como ativo de risco, não como detalhe técnico. Instalar um pacote é permitir que código de terceiros entre na operação. Em projetos com agentes e MCPs, essa decisão precisa ser governada.
1. Não instale pacotes pela aparência do nome
Antes de instalar um SDK, valide a origem. O pacote está linkado a uma documentação oficial? O domínio é legítimo? O repositório GitHub corresponde ao pacote publicado? O mantenedor é reconhecido? O pacote tem histórico, issues, releases e comunidade real? O caso do Sicoob.Sdk mostrou um ponto crítico: o repositório associado podia parecer limpo enquanto o artefato publicado no NuGet carregava o comportamento malicioso.
Em empresas, a regra deveria ser: dependências novas precisam passar por revisão, especialmente quando acessam rede, filesystem, criptografia, certificados, APIs financeiras, cloud ou CI/CD.
2. Use allowlist e repositório interno de pacotes
Ambientes corporativos não deveriam baixar qualquer pacote diretamente da internet em produção ou em pipelines críticos. O ideal é usar um proxy ou repositório interno, com curadoria, cache e aprovação prévia. Assim, a organização cria uma camada de controle entre o desenvolvedor e o ecossistema público.
Para NuGet, o Package Source Mapping ajuda a definir quais pacotes podem ser restaurados de quais fontes. A Microsoft explica que, por padrão, o NuGet busca em todas as fontes configuradas, e que o mapeamento por fonte permite filtrar, por pacote, onde o NuGet deve procurar. Isso reduz riscos em ambientes com fontes públicas e privadas.
3. Fixe versões e use lockfiles
Pipelines devem ser reprodutíveis. Builds que aceitam versões flutuantes aumentam o risco de baixar uma versão comprometida sem revisão humana. Use package-lock.json, pnpm-lock.yaml, yarn.lock, packages.lock.json, Directory.Packages.props e políticas de atualização por pull request.
A atualização de dependências deve entrar como mudança visível: quem mudou, por que mudou, qual diff do pacote, quais permissões novas aparecem, quais scripts de instalação existem e qual impacto no SBOM.
4. Bloqueie scripts de instalação quando possível
Muitos ataques em npm abusam de preinstall, postinstall e hooks semelhantes. Em ambientes sensíveis, avalie executar instalações com scripts desativados, permitir scripts apenas para pacotes aprovados e rodar instalação em sandbox sem segredos. Isso é especialmente importante em CI/CD, onde variáveis de ambiente costumam carregar tokens de cloud, registry, Git e deploy.
5. Remova segredos long-lived do CI/CD
Tokens estáticos e chaves longas são um convite ao desastre. Sempre que possível, substitua tokens persistentes por identidade federada, OIDC e credenciais curtas. No ecossistema npm, o Trusted Publishing usa OIDC para publicar pacotes a partir de workflows autorizados, reduzindo a necessidade de tokens long-lived e gerando credenciais curtas específicas do workflow.
O GitHub também descreve o Trusted Publishing como forma de publicar pacotes npm sem tokens, com credenciais curtas e prova criptográfica de origem e ambiente de build.
6. Exija assinatura, proveniência e verificação de artefatos
Assinatura não resolve tudo, mas reduz a zona cinzenta. Em NuGet, pacotes assinados permitem verificar integridade de conteúdo e ajudam a confirmar a origem do pacote.
Para ambientes mais maduros, a proteção deve combinar assinatura, proveniência, SBOM, SCA, análise estática, análise comportamental e política de aprovação. O NIST SSDF recomenda práticas seguras ao longo do ciclo de desenvolvimento, incluindo proteger componentes contra adulteração e acesso não autorizado.
7. Faça análise comportamental de dependências
Não basta perguntar se o pacote tem vulnerabilidades conhecidas. Pacotes maliciosos novos podem não ter CVE. A análise precisa observar comportamento: acesso à rede durante instalação, leitura de arquivos sensíveis, execução de shell, acesso a variáveis de ambiente, uso de eval, ofuscação, endpoints externos, scripts incomuns e divergência entre código-fonte e artefato publicado.
Ferramentas de SCA, scanners de malware para pacotes, análise em sandbox e revisão manual para pacotes de alto risco devem fazer parte do pipeline.
8. Crie uma política específica para MCP Servers
Todo MCP Server deve ser tratado como componente privilegiado. A política mínima deveria incluir: origem aprovada, dependências revisadas, manifesto assinado, versão fixa, escopos documentados, permissões mínimas, logs auditáveis, segregação por domínio e revisão de cada ferramenta exposta.
A OWASP recomenda práticas como isolamento multi-servidor, segurança de supply chain, monitoramento, logging, auditoria e segurança de instalação e consentimento em ambientes MCP.
9. Aplique least privilege em agentes e tools
Agentes não devem herdar permissões amplas do ambiente. Cada tool exposta por MCP precisa ter escopo limitado. Um agente que consulta status de pagamento não deve ter permissão para alterar cadastro bancário. Um agente que lê logs não deve conseguir executar comandos no host. Um agente que cria pull requests não deve publicar artefatos em produção.
A regra prática é: separar leitura, escrita e execução. Ações críticas exigem aprovação humana, trilha de auditoria e, em muitos casos, dupla validação.
10. Use sandbox para agentes de desenvolvimento
Agentes que escrevem código ou instalam dependências devem operar em ambientes descartáveis, sem acesso direto a segredos reais. A instalação de pacotes deve ocorrer em runner efêmero, com egress controlado, sem tokens de produção, sem certificados montados e com bloqueio de chamadas externas inesperadas.
Para MCP local, o cuidado é ainda maior. Muitos MCP Servers rodam via stdio, dentro da máquina do usuário. Um pacote malicioso nesse contexto pode acessar arquivos locais, repositórios, chaves SSH, .env, tokens de CLI e configurações cloud.
O que fazer se o pacote já foi instalado
A resposta deve ser rápida e objetiva:
Remover imediatamente o pacote e bloquear novas instalações.
Isolar máquinas e runners que executaram o pacote.
Rotacionar tokens, certificados, senhas PFX, client IDs e chaves expostas.
Auditar logs de registry, Git, CI/CD, cloud, APIs e bancos.
Procurar conexões externas suspeitas durante instalação ou build.
Regerar artefatos produzidos no período de exposição.
Atualizar SBOM e registrar o incidente.
Revisar permissões do pipeline e do agente envolvido.
Criar regra de detecção para nomes similares, endpoints e indicadores conhecidos.
Publicar uma política interna para evitar reincidência.
No caso específico do Sicoob.Sdk, a orientação pública foi tratar certificados PFX e credenciais como comprometidos, substituir material exposto e revisar logs de autenticação e APIs.
Um modelo seguro para agentes e MCPs em empresas
Empresas que querem colocar agentes de IA no centro da operação precisam de uma arquitetura de confiança. Isso inclui um Agent Registry, um catálogo de MCP Servers aprovados, contratos de ferramentas, políticas de risco, trilhas de auditoria, observabilidade, evals contínuos, rollout controlado e kill switch.
Na prática, o caminho recomendado é:
criar um inventário de agentes, tools, MCP Servers e dependências;
classificar tools por risco: leitura, escrita, execução, financeiro, dados sensíveis e produção;
exigir revisão de dependências para qualquer MCP Server;
bloquear instalação dinâmica de pacotes por agentes em ambientes privilegiados;
usar credenciais curtas e escopadas por tool;
registrar cada chamada: usuário, agente, tool, parâmetros, resposta, decisão e efeito;
aplicar aprovação humana para ações irreversíveis ou financeiras;
monitorar anomalias de uso, custo, latência, falhas e chamadas fora do padrão;
manter um kill switch por agente, tool e MCP Server.
Esse modelo transforma segurança em parte da arquitetura, não em etapa posterior. Para agentes corporativos, governança não é burocracia. É o que permite escalar autonomia sem entregar a operação para dependências desconhecidas.
Conclusão
O incidente com pacotes maliciosos no NuGet e npm mostra que a cadeia de software se tornou um dos principais pontos de entrada para ataques. O risco cresce quando esses pacotes entram em ambientes com CI/CD, credenciais de nuvem, certificados, tokens de publicação e agentes de IA conectados a ferramentas corporativas.
A resposta não é abandonar open source, agentes ou MCPs. A resposta é mudar o modelo de confiança. Dependências precisam de curadoria. Pipelines precisam de isolamento. Segredos precisam ser curtos e escopados. MCP Servers precisam de catálogo, contratos, permissões mínimas e auditoria. Agentes precisam operar dentro de limites claros.
Em arquiteturas agênticas, a pergunta não é apenas “o agente consegue executar?”. A pergunta correta é: ele consegue executar com segurança, rastreabilidade, escopo limitado e capacidade de interrupção imediata?
Comentários