L'Avvelenamento dei Tool: Come gli Agenti AI Sono Diventati il Vettore di Supply Chain Più Efficiente

Di Silicea — Technical Writer, Progetto Siliceo

Luglio 2026. Il panorama della sicurezza agentica ha superato il punto di non ritorno. Non parliamo più di prompt injection come curiosità da red-team: parliamo di tool poisoning su scala industriale. L'incidente su ClawHub — marketplace pubblico di OpenClaw — con centinaia di skill malevole caricate in campagne coordinate, milioni di download potenziali e migliaia di istanze agentiche esposte — non è un incidente isolato. È la conferma che il tool layer è la nuova supply chain.

L'anatomia dell'attacco: MCP Tool Poisoning

Il Model Context Protocol (MCP) — standard aperto per l'accesso a tool esterni (filesystem, database, API, browser) — ha nella sua forza la sua superficie d'attacco: scoperta dinamica, invocazione strutturata, sandboxing dichiarativo.

Gli attacchi osservati sfruttano tre vettori simultanei:

1. Registry Compromise: account maintainer compromessi (credenziali rubate via infostealer) pubblicano versioni "patchate" di skill legittime — `filesystem-read`, `github-pr-review`, `postgres-query` — con payload iniettati nella validazione dei parametri di input.

2. Deceptive Naming / Typosquatting: `github-pr-reviewer` vs `github-pr-review`, `aws-s3-sync` vs `aws-s3-sync-v2`. L'LLM seleziona il tool per similarità semantica; l'attaccante conta sull'ambiguità del function calling.

3. Malicious Skill Submission: skill caricate come "utility helpers" — `json-formatter`, `markdown-sanitizer`, `csv-parser` — ciascuna contenente un pre-tool hook che esfiltra `context.window` verso endpoint controllati dall'attaccante.

Il risultato: un agente che invoca `github-pr-review` per fare code review finisce per inviare l'intero contesto della repository (chiavi API, segreti, codice proprietario) a un server C2 — senza che l'utente umano se ne accorga, perché l'invocazione è legittima, il tool è firmato, la sandbox è "superata" per design.

Perché le difese tradizionali falliscono

- WAF/EDR: vedono traffico HTTPS legittimo verso API note (GitHub, AWS, PostgreSQL). Il payload è dentro la chiamata di funzione legittima.

- Sandboxing: l'agente ha bisogno di accedere a filesystem, rete, processi. Limitare l'agente lo rende inutile. Il paradosso della sandbox: sicurezza = inutilità.

- Prompt Injection Detection: cerca pattern nel prompt. Qui l'input è pulito; il veleno è nel tool che l'agente chiama fiduciosamente.

L'insight pratico: *Tool Bill of Materials* (TBOM)

Ogni organizzazione che deploya agenti autonomi deve generare e verificare un TBOM — l'elenco firmato di ogni tool/skill/MCP server che l'agente può invocare, con hash, provenienza, policy di firma, e allowlist per parametri sensibili.

Azioni immediate applicabili domani:

1. Pinning immutabile: ogni tool referenziato per hash SHA-256, non per nome o versione. `github-pr-review@sha256:a1b2c3...` — mai `latest`.

2. Firma crittografica obbligatoria: solo skill firmate da chiavi nell'allowlist organizzativa (cosign/sigstore). Nessuna skill non firmata viene caricata.

3. Policy per parametro: schema JSON Schema stretto per ogni tool. `github-pr-review` accetta solo