TLDR
- Gli skill degli agenti AI non sono semplici plugin decorativi: possono contenere istruzioni, script, dipendenze e accesso a tool locali.
- Il file SKILL.md è testo operativo: può influenzare discovery, scelta dello skill e comportamento dell'agente.
- I paper 2026 su ClawHub mostrano un ecosistema con skill malevoli reali, scanner statici aggirabili e bisogno di controlli runtime.
- La regola pratica è trattare ogni skill come codice non fidato: sandbox, permessi minimi, review, segreti separati e monitoraggio.
Il plugin che non sembra più un plugin
Per anni abbiamo imparato una regola semplice: non installare estensioni a caso.
Poi sono arrivati gli agenti AI e la regola è diventata più strana. Non installare estensioni a caso in un programma che legge i tuoi file, usa le tue API, apre il terminale, interpreta istruzioni in linguaggio naturale e magari ha anche accesso ai segreti del progetto.
Uno skill per agenti AI sembra innocuo perché spesso parte da un file leggibile, quasi editoriale: SKILL.md. Dentro ci sono descrizione, casi d'uso, istruzioni per l'agente, dipendenze e riferimenti. Sembra documentazione.
Ma per un agente quella documentazione non è solo testo da leggere. È testo che orienta decisioni.
Hacker Journal, parlando di OpenClaw e ClawHub, centra bene il punto: le skill rendono l'agente davvero operativo, perché aggiungono API esterne, task ripetitivi, automazioni e workflow. Il rovescio è che uno skill malevolo può accedere a dati sensibili, inviare richieste non autorizzate o compromettere l'ambiente in cui l'agente gira.
Questa è supply chain. Solo che il pacchetto non è sempre un pacchetto. A volte è un pezzo di testo che convince un agente a comportarsi in un certo modo.
SKILL.md non è un README qualunque
Il paper "Under the Hood of SKILL.md" usa una frase importante: SKILL.md non è documentazione passiva.
La ragione è semplice. In un ecosistema di skill, il testo può influenzare tre momenti:
- discovery: quali skill vengono trovati quando chiedi una cosa;
- selezione: quale skill viene preferito tra alternative simili;
- governance: quali controlli automatici considerano lo skill accettabile.
Se un attaccante riesce a scrivere descrizioni, trigger o istruzioni che migliorano la visibilità dello skill, lo rendono più convincente o lo fanno sembrare meno rischioso, non sta solo facendo SEO dentro un registry. Sta manipolando la catena di scelta dell'agente.
È la versione AI di un problema vecchio: il pacchetto con il nome giusto, la descrizione rassicurante, le stelle finte, la dipendenza che sembra normale.
Solo che qui c'è una differenza in più. L'agente può leggere quella descrizione e usarla come parte del proprio comportamento.
Il rischio vero: permessi ambientali
Uno skill diventa pericoloso quando incrocia tre cose:
- accesso a dati utili;
- capacità di eseguire o chiamare tool;
- contatto con input non fidato.
Se l'agente gira nella stessa macchina in cui hai token, cookie, variabili d'ambiente, repository privati e chiavi cloud, lo skill non deve per forza "bucare" il sistema. Gli basta essere eseguito nel posto giusto.
La discussione su Hacker News del caso "I Got Pwned by a Malicious AI Plugin" è utile proprio perché suona poco cinematografica e molto quotidiana: un plugin con accesso all'ambiente, cookie e configurazioni dell'agente diventa un problema enorme perché vive vicino ai segreti e modifica il contesto che l'AI legge all'avvio.
Il dettaglio importante non è il nome del plugin. È il pattern:
- codice di terze parti dentro un processo fidato;
- segreti disponibili come variabili d'ambiente;
- dipendenze non coerenti con lo scopo dichiarato;
- modifiche ai file che orientano il comportamento dell'agente;
- segnali comportamentali strani ignorati troppo a lungo.
Se hai già letto l'articolo su GitLost e le issue pubbliche che influenzano agenti con accesso a repo privati, il collegamento è diretto: l'agente non distingue automaticamente "testo utile" da "testo che vuole farmi fare qualcosa".
Gli scanner servono, ma non sono un esorcismo
Il paper "Cloak and Detonate" è uscito a luglio 2026 e sposta la discussione dal "troviamo gli skill cattivi" al "quanto è facile farli sembrare puliti?".
La risposta breve: abbastanza facile da non poter dormire tranquilli.
La ricerca studia evasione degli scanner sugli agent skill. Alcune tecniche cambiano la forma visibile del payload senza cambiare il comportamento. Altre nascondono componenti fino al momento dell'esecuzione. Il risultato è il solito bagno freddo della sicurezza: l'analisi statica è utile, ma se guardi solo ciò che si vede all'installazione puoi perdere ciò che accade quando lo skill prende vita.
La difesa proposta va nella direzione giusta: guardare il comportamento runtime. File letti, processi avviati, connessioni di rete, flussi di dati sensibili, tentativi di materializzare istruzioni in un secondo momento.
Tradotto in pratica:
- non fidarti solo del manifest;
- non fidarti solo del nome;
- non fidarti solo del voto automatico;
- non installare direttamente nel workspace vero;
- osserva cosa lo skill fa, non solo cosa dice di fare.
La sicurezza degli agenti sta diventando meno "leggi il prompt" e più "instrumenta il sistema".
La checklist prima di installare uno skill
Questa non è una checklist teorica. È quella da usare quando trovi uno skill che sembra comodo.
Controlla autore e provenienza.
Uno skill appena pubblicato da un account sconosciuto, senza altri progetti e senza storia verificabile, non va installato sulla macchina vera. Punto.
Leggi il contenuto, non solo il titolo.
Cerca dipendenze strane, download remoti, istruzioni che chiedono segreti, script opachi, comandi offuscati, riferimenti crypto non coerenti, modifiche a file di configurazione dell'agente.
Installa in sandbox.
Una VM, un container limitato, un utente separato o una macchina di test valgono più di mille "sembra ok". Lo skill deve partire senza accesso ai segreti reali.
Riduci i permessi.
Se lo skill serve a trascrivere audio, non deve leggere il repository aziendale. Se serve a formattare Markdown, non deve chiamare API cloud. Se serve a riassumere issue, non deve deployare.
Separa i segreti.
Evita token lunghi in process.env disponibili a tutto. Usa secret manager, token a scope stretto, scadenze brevi, account dedicati e rotazione facile.
Guarda il traffico.
Uno skill locale che chiama domini non dichiarati, scarica payload o parla con endpoint casuali sta raccontando qualcosa. Ascoltalo prima che sia troppo tardi.
Il problema delle automazioni "troppo riuscite"
Il fascino degli agenti è anche la loro trappola.
Quando tutto funziona, vuoi collegare più cose: email, repo, ticket, terminale, cloud, browser, storage, chat, calendario, MCP server. Ogni integrazione sembra piccola. Insieme formano una superficie enorme.
The Hacker News ha raccontato a luglio 2026 un caso in cui un agente AI ha automatizzato una catena ransomware partendo da un vecchio bug esposto in Langflow. Il punto non è che ogni agente diventerà ransomware. Il punto è che gli agenti riducono il costo operativo di concatenare passaggi già noti: trovare credenziali, provare accessi, muoversi verso servizi deboli, generare script, correggere errori.
Uno skill installato male può diventare un acceleratore dentro questa catena.
Per questo lo skill non va valutato solo come "fa la cosa che promette?". Va valutato come "cosa potrebbe fare con i permessi che gli sto dando?".
Come impostare un laboratorio sano
Se vuoi sperimentare con skill, OpenClaw, MCP o automazioni agentiche, la strada giusta non è chiudersi. È costruire un laboratorio.
Primo livello: macchina separata o utente separato.
Dentro ci metti dati finti, repository demo, token revocabili, cartelle senza documenti personali, browser senza sessioni vere.
Secondo livello: rete controllata.
Blocca outbound dove possibile, logga DNS e connessioni, usa firewall applicativo o almeno strumenti base per vedere cosa esce.
Terzo livello: permessi temporanei.
Uno skill non deve ereditare per sempre tutto. Se serve un token, deve essere dedicato, limitato e revocabile.
Quarto livello: journaling.
Segna cosa installi, da dove, a che versione, con quali hash o commit. Sembra noioso finché non devi capire quando hai introdotto il problema.
Quinto livello: review prima degli effetti.
Un agente può preparare una PR, ma non deve pubblicarla da solo se il contenuto nasce da input esterno. Può suggerire un comando, ma non deve lanciarlo su produzione. Può compilare un report, ma non deve inviare segreti.
Il collegamento con prompt injection e Morris II
Gli skill degli agenti sono il punto in cui si incontrano due fili già pubblicati su Able2Code.
Il primo è prompt injection negli agenti AI: testo non fidato che entra nel contesto e prova a diventare istruzione.
Il secondo è Morris II e i worm AI a prompt: contenuto che non vuole solo alterare una risposta, ma propagarsi attraverso memoria, output e azioni.
Lo skill aggiunge il terzo ingrediente: capacità.
Prompt injection è il volante. Lo skill è il motore. I permessi sono la benzina.
Meglio non lasciare le chiavi attaccate.
La frase da ricordare
Installare uno skill per un agente AI non è come cambiare tema grafico.
È più vicino a dare a un collega sconosciuto una sedia davanti al tuo terminale, un manuale su come convincere l'agente e una manciata di API da provare.
Non significa non usarli. Gli skill sono utilissimi e saranno uno dei motivi per cui gli agenti diventeranno davvero produttivi.
Significa usarli con la stessa paranoia sana con cui tratti estensioni browser, pacchetti npm, azioni CI e script trovati in giro.
Nel 2026 la domanda non è più solo "che codice sto installando?".
È: "che comportamento sto autorizzando?".
FAQ
Uno skill AI è come un'estensione browser?
Sì, come modello mentale funziona. Aggiunge capacità a un sistema già privilegiato. La differenza è che l'agente può leggere istruzioni naturali, scegliere quando usarle e chiamare tool locali o API.
Il file SKILL.md è pericoloso anche se non contiene codice?
Può esserlo. Non perché esegua codice da solo, ma perché descrive all'agente quando e come usare uno skill. Se quel testo altera discovery, selezione o comportamento, diventa parte della superficie d'attacco.
Basta usare uno scanner prima di installare?
No. Gli scanner aiutano, ma la ricerca recente mostra che tecniche di evasione possono nascondere il comportamento malevolo fino al runtime. Serve anche sandboxing e osservazione di file, processi, rete e segreti.
Qual è il primo controllo da fare?
Installare lo skill in un ambiente separato senza segreti reali. Se richiede permessi larghi, modifica configurazioni core, scarica codice esterno o ha autore sconosciuto, va fermato.
Cosa c'entra MCP?
MCP e tool simili aumentano il numero di azioni che un agente può compiere. Più tool colleghi, più devi ragionare su permessi, identità, logging e confine tra input non fidato e azione reale.