O que aconteceu
Em 17 de junho de 2026, uma única conta de desenvolvedor roubada transformou o Mastra, um dos frameworks de agente de IA mais populares do npm, em um sistema de entrega de malware norte-coreano. Não foi uma falha exótica de dia zero, não foi engenharia reversa de um binário blindado. Foi uma credencial comprometida com poder de publicação, apontada pra um pacote que milhares de devs instalam sem pensar.
O detalhe que importa: em cerca de 19 minutos, os atacantes republicaram mais de 140 pacotes no escopo @mastra. Cento e quarenta pacotes. Dezenove minutos. Isso não é um humano fazendo npm publish num terminal, é automação disparando contra um escopo inteiro assim que a sessão foi tomada.
Se você usa framework de agente em produção, esse ataque é sobre você.
Por que framework de agente é alvo de valor
Supply chain do npm sempre foi superfície de risco. O que muda com framework de agente de IA é a densidade do alvo.
- Muitos devs, adoção rápida. Framework de agente é o hype do momento. A base instalada cresce em semanas, não anos. Um pacote comprometido alcança milhares de máquinas antes de alguém abrir uma issue.
- Segredos por perto. Agente de IA não roda sozinho no vácuo. Ele fica ao lado de
OPENAI_API_KEY, token de banco, credencial de cloud, chave de provider de LLM. Malware no framework não precisa escalar privilégio, os segredos já estão no mesmo processo, no mesmo.env, no mesmo ambiente. - Deploy rápido, revisão frouxa. A cultura de agente é
npm install, prototipa, sobe. Pin exato e review de dependência costumam ficar pra depois, e depois não chega. - Escopo grande = raio grande. Um escopo
@mastracom 140+ pacotes é um único ponto de falha com raio de explosão gigante. Comprometeu o publisher, comprometeu tudo de uma vez.
Junta os quatro e você tem o alvo perfeito: muita máquina, muito segredo por perto, pouca fricção de segurança.
Os 19 minutos são o ponto central
Para na palavra: dezenove minutos.
Esse número mata a fantasia da resposta manual. Nenhum time humano detecta, triagem, confirma e responde a 140 pacotes republicados em 19 minutos. Quando o alerta chega no Slack, o postinstall malicioso já rodou na CI, já rodou na máquina de dev, já exfiltrou o que tinha pra exfiltrar. O ataque terminou antes da reunião de resposta começar.
Essa é a tese central da RET: a velocidade da IA sem fronteira de segurança vira superfície de ataque. O mesmo pipeline automatizado que deixa você shippar agente em uma tarde é o que deixa o atacante republicar 140 pacotes num café. Automação não tem lado. Se a sua defesa depende de um humano reagindo mais rápido que um script, você já perdeu.
A conclusão prática: defesa contra supply chain de agente tem que ser preventiva e automática, montada antes do incidente. Reação não escala contra automação.
O que fazer, na prática
Nada aqui é exótico. É higiene de supply chain aplicada com disciplina ao caso específico de framework de agente.
Pin exato de versão
Nada de ^ nem ~ em framework de agente. Pin exato, versão travada. "@mastra/core": "1.4.2", não "^1.4.0". Range aberto é convite pra puxar a versão envenenada no próximo npm install. Com pin exato, a republicação maliciosa de uma nova versão não te alcança sozinha.
Cooldown de adoção de versão nova
Não instale a versão que saiu há 20 minutos. Coloque um delay de adoção, um cooldown de alguns dias entre a publicação e o momento em que você puxa. A maioria dos ataques de supply chain é pega e despublicada em horas. Um cooldown de 48 a 72 horas transforma o incidente dos outros num não-evento pra você. Ferramentas de policy de dependência já suportam isso, use.
Lockfile com integrity, sempre
package-lock.json (ou o lock do seu gerenciador) com hash de integridade sha512 commitado e respeitado. Em CI, npm ci, nunca npm install. O integrity hash é o que garante que o byte que você auditou é o byte que você instalou. Sem lockfile respeitado, o pin exato não vale nada.
Verificação de publisher e provenance
Checar quem publicou e como. npm provenance (attestation via Sigstore) liga o pacote ao commit e ao workflow de CI que o gerou. Prefira pacotes com provenance verificável. Publisher que muda, 2FA que sumiu, publicação fora do CI de sempre, tudo isso é sinal. No caso Mastra, foi exatamente uma conta com poder de publish que caiu, provenance forte teria dado sinal de que a publicação não veio do pipeline legítimo.
Segredos fora do alcance do agente
Se o malware roda no mesmo processo do agente e os segredos estão no .env ao lado, acabou. Tire os segredos do alcance:
- Injeção em runtime via secret manager, não
.envno repo nem no disco do agente. - Credencial de curta duração e escopo mínimo, não chave permanente com acesso total.
- Isolamento de processo entre o que o agente executa e onde vive a credencial sensível.
O objetivo é que comprometer o framework não signifique automaticamente comprometer todos os seus segredos.
Menor privilégio pro que o agente executa
Agente de IA executa código, chama ferramenta, dispara comando. Trate esse ambiente de execução como hostil por padrão. Sandbox pro que o agente roda, sem acesso de rede irrestrito, sem write no filesystem inteiro, sem credencial que ele não precisa naquela tarefa. Se o postinstall malicioso do framework herda o mesmo privilégio do agente, você quer que esse privilégio seja o mínimo possível.
O fecho
O ataque ao Mastra não foi sofisticado. Foi uma credencial roubada, um escopo grande e automação. O que o torna assustador é a matemática: 140 pacotes, 19 minutos, milhares de máquinas com segredos por perto. Framework de agente concentra tudo que um atacante de supply chain quer, e a velocidade da IA que você ama é a mesma que o atacante usa.
A resposta não é parar de usar framework de agente. É parar de tratar dependência de agente como algo que você instala e esquece. Pin exato, cooldown, lockfile com integrity, provenance, segredo fora do alcance, menor privilégio. Barato, chato, preventivo. Do jeito que boa segurança sempre foi.
Contra automação de 19 minutos, sua defesa tem que estar pronta antes do incidente, não reagindo depois dele.
