Segurança de configurações de agentes de IA é segurança da cadeia de suprimentos

Em 29 de abril de 2026, equipes de segurança relataram pacotes comprometidos no ecossistema SAP que não paravam no roubo de credenciais. A campanha Mini Shai-Hulud também registrava persistência em configurações de desenvolvedor: acionadores do Claude Code, tarefas do VS Code e arquivos de fluxo de trabalho do repositório.¹²³

Esse detalhe muda o limite da revisão. Um pacote envenenado não precisa continuar instalado se conseguir deixar para trás um comando de inicialização em um arquivo no qual o desenvolvedor confia. Remover a dependência pode eliminar o primeiro gatilho. A configuração do agente ou do editor pode manter o próximo gatilho ativo.

Configuração de agente de IA é software executável. Trate cada acionador, tarefa, definição de servidor MCP, skill, plugin, script de pacote e arquivo de fluxo de trabalho como parte da cadeia de suprimentos de software, porque esses arquivos podem decidir qual código roda antes de um humano ler o diff.

Resumo

O Mini Shai-Hulud mostrou um caminho prático da instalação de uma dependência até a persistência em ferramentas de desenvolvedor. Pesquisadores de segurança relataram pacotes npm maliciosos que usavam scripts de ciclo de vida durante a instalação, coletavam credenciais de desenvolvedores e de CI, e gravavam arquivos .claude/settings.json e .vscode/tasks.json para executar código novamente a partir de superfícies confiáveis de desenvolvimento.¹²⁴ A documentação oficial confirma que essas superfícies têm autoridade real de execução: acionadores do Claude Code rodam comandos de ciclo de vida, acionadores de comando executam com as permissões do usuário, e tarefas folderOpen do VS Code podem rodar quando uma pasta é aberta depois que o usuário permite tarefas automáticas para aquela pasta.⁵⁶

A lição não é “desligue os agentes”. A lição é mais precisa: configuração de agentes pertence à revisão de dependências, revisão de código, resposta a incidentes e controles de release. Diretórios ocultos que antes pareciam preferência local agora ficam no caminho de execução. Uma prática séria de engenharia com IA precisa revisar diffs de configuração, acionadores, tarefas, tokens com privilégio mínimo e superfícies de inicialização.

Principais pontos

Para desenvolvedores: - Revise .claude/settings.json, .vscode/tasks.json, .github/workflows/*, scripts em package.json, configurações MCP e manifestos de plugins ou skills de agentes antes de confiar em um repositório. - Trate novos acionadores de inicialização e tarefas de abertura de pasta como novos arquivos executáveis. - Depois de uma instalação suspeita, remova arquivos de persistência e rotacione credenciais. Só remover o pacote não prova que a limpeza foi concluída.

Para equipes de segurança: - Inclua arquivos de configuração de agentes na detecção de cadeia de suprimentos, em CODEOWNERS, na resposta a segredos e no escopo de incidentes. - Sinalize qualquer PR que adicione execução na inicialização, comandos shell amplos, binários baixados de origem opaca ou cargas escondidas em diretórios ocultos. - Prefira credenciais de publicação de curta duração e credenciais somente leitura para instalação. Tokens de escrita de longa duração continuam sendo combustível para worms.

Para criadores de plataformas de agentes: - Torne superfícies de execução visíveis, revisáveis e explicáveis. - Separe acionadores que carregam contexto de acionadores que executam comandos. - Ofereça aos usuários uma visão de auditoria de primeira classe para ações de inicialização, chamadas externas de rede e configurações modificadas.

O que o Mini Shai-Hulud mudou

Ataques à cadeia de suprimentos contra gerenciadores de pacotes já seguem um padrão conhecido. Um pacote confiável recebe uma versão maliciosa. Um script de instalação executa. A carga rouba tokens. A remoção do registro ou o rollback da versão chega depois que alguns desenvolvedores e jobs de CI já instalaram a versão comprometida.

O Mini Shai-Hulud acrescentou uma etapa mais específica da era dos agentes. Relatórios da Endor Labs, Wiz, Socket, StepSecurity e Cloud Security Alliance descrevem a mesma estrutura geral: pacotes comprometidos no ecossistema de desenvolvimento SAP usaram execução durante a instalação via npm, coletaram credenciais de GitHub, npm, cloud e CI, e criaram persistência por meio de configuração de ferramentas de desenvolvedor.¹²³⁴⁷

A Wiz documentou um caminho de fallback que colocava arquivos em repositórios para que futuras aberturas no Claude Code ou no VS Code pudessem disparar a execução de novo.² A Endor Labs descreveu um acionador SessionStart do Claude Code e uma tarefa do VS Code com runOn: "folderOpen".¹ O rastreador de campanha da Socket lista persistência por .claude/settings.json e .vscode/tasks.json ao lado de comprometimentos de pacotes npm e PyPI.³

A carga exata pertence a relatórios de incidente, não a um artigo geral de engenharia. A lição duradoura pertence aqui:

O alvo saiu de uma versão de pacote e passou para o ambiente de desenvolvimento em volta do pacote.

Arquivos de configuração viraram programas de inicialização

A referência de acionadores do Claude Code diz que eles são comandos shell definidos pelo usuário, endpoints HTTP ou prompts LLM que executam automaticamente em eventos de ciclo de vida.⁵ A mesma documentação diz que SessionStart roda quando o Claude Code inicia ou retoma uma sessão, e a seção de segurança avisa que acionadores de comando rodam com todas as permissões do usuário.⁵

A documentação de tarefas do VS Code oferece outra superfície de execução. Uma tarefa pode definir runOn como folderOpen, e o VS Code executará essa tarefa quando a pasta correspondente for aberta depois que o usuário permitir tarefas automáticas para aquela pasta.⁶ Esse prompt de consentimento importa. Ele reduz o risco em comparação com execução silenciosa em toda máquina. Mas não torna o arquivo inofensivo. Um repositório confiável, um desenvolvedor cansado, um workspace já autorizado ou uma política da organização ainda podem transformar uma mudança de configuração em execução de código.

O npm adiciona a ponte no momento da instalação. A documentação de scripts do npm lista preinstall, install e postinstall entre os scripts de ciclo de vida de npm ci e npm install, e a seção de boas práticas do npm diz que autores quase nunca devem definir explicitamente scripts preinstall ou install, exceto para compilação para arquitetura-alvo.⁸

Esses 3 fatos criam a cadeia de ataque:

1. Um script de instalação roda durante a instalação de dependências.
2. O script grava ou altera a configuração de ferramentas de desenvolvedor.
3. O editor ou agente depois executa a ação de inicialização configurada.
4. O desenvolvedor confia na superfície da ferramenta porque o prompt ou a UI parece trabalho normal.

O perigo não está em um recurso isolado. Scripts de instalação, acionadores, tarefas e fluxos de trabalho sustentam automações legítimas. O perigo está na transitividade da confiança. Uma instalação de pacote não deveria poder definir silenciosamente o que toda futura sessão de agente ou abertura de pasta executará.

O limite da revisão está errado

A maior parte dos hábitos de revisão de código trata arquivos-fonte como o artefato principal e arquivos de configuração como material de apoio. Esse hábito falha quando arquivos de configuração executam comandos.

Um novo acionador deve receber a mesma revisão que um novo script shell. Uma nova tarefa deve receber a mesma revisão que um novo binário. Um novo servidor MCP deve receber a mesma revisão que uma nova integração de rede. Um novo script de ciclo de vida de pacote deve receber a mesma revisão que um código novo que roda antes dos testes.

Use uma tabela de revisão:

Defesa em tempo de execução para agentes com ferramentas argumentou que a aplicação de regras pertence ao limite das chamadas de ferramentas. O Mini Shai-Hulud empurra o mesmo padrão uma camada antes. O limite de inicialização também precisa de aplicação de regras.

Autoridade de inicialização precisa de privilégio mínimo

Equipes já aplicam privilégio mínimo a chaves API. Configuração de agentes precisa da mesma regra.

O Claude Code separa eventos de acionadores como PreToolUse, PostToolUse e SessionStart.⁵ Essa separação deve moldar a política. Um acionador que carrega contexto estático não deveria precisar de acesso shell. Um acionador que valida um comando não deveria precisar de acesso à rede. Um acionador que registra metadados locais não deveria precisar de credenciais.

A mesma regra vale para tarefas do VS Code e fluxos de trabalho de CI:

A documentação de trusted publishing do npm explica por que credenciais de curta duração importam. Trusted publishing usa OIDC para que a publicação de pacotes possa acontecer sem tokens npm de longa duração, e o npm recomenda impedir publicação tradicional baseada em token depois que trusted publishers são configurados.⁹ O npm também recomenda tokens de acesso granulares somente leitura para instalar dependências privadas quando a publicação usa OIDC.⁹

Esse conselho não elimina o risco de fluxos de trabalho. Um fluxo comprometido ainda pode causar dano se tiver autoridade demais. A lição é reduzir os dois lados: credenciais de curta duração e fluxos de trabalho estreitos.

Trate configuração de agentes como dependência

A revisão de dependências costuma perguntar quais versões de pacote mudaram. A revisão da era dos agentes deve perguntar quais superfícies de execução mudaram.

Antes de aceitar uma atualização de dependência, instalação de plugin, configuração gerada ou mudança de template, verifique:

O ponto não é paranoia. É precisão de categoria. Um arquivo de acionador pode parecer configuração, mas se comporta como código. Um arquivo de tarefa pode parecer ajuste de editor, mas pode abrir um shell. Um fluxo de trabalho pode parecer encanamento de release, mas pode alcançar credenciais.

A segurança de agentes de IA começa com software pequeno apresentou um argumento relacionado pelo lado do design: ferramentas mais estreitas têm menos lugares para esconder erros. A versão de segurança diz que configurações mais estreitas têm menos lugares para esconder persistência.

Uma varredura segura de configuração

Uma revisão defensiva não precisa executar código suspeito. Comece com inspeção somente leitura:

git diff -- .claude/settings.json .vscode/tasks.json package.json .github/workflows
rg -n '"SessionStart"|"runOn"\\s*:\\s*"folderOpen"|preinstall|postinstall|curl|wget|bun|node .*setup' \
  .claude .vscode package.json .github/workflows
find . -path '*/.claude/*' -o -path '*/.vscode/tasks.json' -o -path '*/.github/workflows/*'

Esses comandos não provam que uma máquina está limpa. Eles dão ao revisor uma primeira passada pelas superfícies com maior probabilidade de transformar configuração em execução. Se uma instalação suspeita já aconteceu, siga para resposta a incidente em vez de tratar um resultado limpo de busca como garantia.

Recuperação exige uma varredura de configuração

A resposta a incidente para uma dependência comprometida não deve parar na desinstalação do pacote.

Use uma sequência de recuperação:

1. Identifique se a versão afetada do pacote foi instalada em uma máquina de desenvolvedor ou runner de CI.
2. Congele esse ambiente antes que ele faça mais trabalho.
3. Audite arquivos de configuração de inicialização no repositório e configurações de agentes ou editores no diretório home.
4. Remova acionadores, tarefas, fluxos de trabalho, arquivos de carga gerados e branches inesperados que sejam suspeitos.
5. Rotacione toda credencial acessível ao processo afetado, incluindo tokens de pacote, tokens GitHub, chaves cloud, chaves SSH e segredos de CI.
6. Inspecione acesso de publicadores de pacote e acesso de escrita ao repositório.
7. Revise logs de fluxos de trabalho em busca de exposição de segredos e chamadas externas inesperadas.
8. Reconstrua o ambiente a partir de um checkout limpo e de um conjunto de dependências sabidamente confiável.

A orientação de segurança do Actions do GitHub sustenta o lado das credenciais nessa resposta: use privilégio mínimo para tokens de fluxo de trabalho, rotacione segredos expostos, audite como os segredos são tratados e considere exigir revisão antes que jobs acessem segredos de ambiente.¹⁰ O GitHub também recomenda CODEOWNERS para arquivos de fluxo de trabalho, de modo que mudanças em .github/workflows exijam aprovação de revisores designados.¹⁰

Inclua configuração de agentes nesse mesmo caminho de governança. Se .github/workflows/* merece revisão de code owner porque pode tocar segredos, .claude/settings.json e .vscode/tasks.json merecem revisão porque podem executar comandos perto de segredos.

O que plataformas de agentes deveriam criar

Plataformas de agentes e editores podem reduzir a carga de revisão tornando a autoridade de inicialização explícita.

Superfícies úteis de produto:

Essas superfícies não devem depender de o modelo ler um arquivo JSON e fazer um julgamento. O ambiente de execução deve expor a autoridade diretamente. O usuário deve ver uma diferença clara entre “carrega contexto do README” e “executa um comando shell ao iniciar a sessão.”

Ferramentas MCP precisam de autorização por ação argumentou que a validação de bearer token precisa levar a checagens por ferramenta, por papel e por ação. Configuração de agentes precisa do mesmo formato: cada ação de inicialização deve declarar a autoridade de que precisa, e o ambiente de execução deve aplicar o menor conjunto viável.

Uma política local prática

Equipes podem começar com um pequeno arquivo de política mesmo antes de as plataformas melhorarem a interface:

Uma boa política nomeia o arquivo e a autoridade. Regras vagas como “tenha cuidado com ferramentas de agentes” não sobrevivem ao trabalho real. Regras claras como “nenhum acionador de comando SessionStart sem revisão de responsável” dão aos revisores algo que eles conseguem aplicar.

FAQ

Configuração de agentes de IA realmente faz parte da cadeia de suprimentos?

Sim. O risco de cadeia de suprimentos segue execução e confiança, não extensão de arquivo. Se uma instalação de pacote, plugin, template ou mudança de repositório pode modificar a configuração de agentes que depois executa comandos, essa configuração fica dentro da cadeia de suprimentos.

Equipes devem banir acionadores do Claude Code ou tarefas do VS Code?

Não. Acionadores e tarefas sustentam automações legítimas. Equipes devem revisá-los, limitar seu escopo e registrá-los. Um acionador que carrega contexto e um acionador de inicialização que executa shell não devem receber a mesma confiança.

O VS Code pergunta antes de executar tarefas ao abrir uma pasta?

A documentação do VS Code diz que, na primeira vez que um usuário abre uma pasta contendo uma tarefa folderOpen, o VS Code pergunta se deve permitir tarefas automáticas para aquela pasta.⁶ Esse prompt ajuda, mas a tarefa ainda merece revisão de código, porque a aprovação transforma o arquivo em um caminho de execução.

Trusted publishing do npm resolve comprometimento de pacotes?

Não. Trusted publishing reduz o risco de tokens npm de escrita de longa duração usando credenciais de curta duração baseadas em OIDC.⁹ Equipes ainda precisam de revisão de fluxos de trabalho, privilégio mínimo, monitoramento de pacotes e resposta a incidentes para repositórios comprometidos ou scripts de instalação maliciosos.

O que devo auditar primeiro depois de uma instalação suspeita?

Audite scripts executados na instalação, configurações de inicialização de agentes e editores, arquivos de fluxo de trabalho, arquivos inesperados em diretórios ocultos, novos branches e credenciais expostas ao processo afetado. Depois, rotacione as credenciais do ambiente afetado.

Fechamento

Agentes de codificação com IA tornam a configuração mais poderosa. Também tornam a configuração mais perigosa.

A resposta certa não é medo da automação. A resposta certa é honestidade sobre onde a execução acontece. Se um arquivo pode executar um comando, buscar dados, ler segredos, publicar pacotes ou mudar o comportamento de um agente, esse arquivo pertence ao caminho de revisão.

A configuração de agentes cruzou essa linha. Trate-a como código.

Referências