Riepilogo Tecnico: Lezioni dai Test di Penetrazione su Sistemi di Agenti su Larga Scala

Enunciato del Problema

Mentre i sistemi di IA evolvono da semplici chatbot ad agenti capaci di esecuzione che interagiscono con filesystem, reti e API esterne, il panorama della sicurezza è cambiato. Questi agenti funzionano come programmi illimitati e auto-modificanti con una vasta superficie di interazione, creando comportamenti complessi a più livelli che sono difficili da proteggere. Sebbene la ricerca precedente abbia documentato estesamente le vulnerabilità nei framework di agenti open-source, non è chiaro se i sistemi di agenti proprietari — sviluppati secondo standard di codifica più rigorosi, revisioni formali e modelli di sviluppo chiusi — presentino debolezze simili. Il problema centrale affrontato è se i processi di sviluppo rigorosi dei sistemi proprietari mitigano efficacemente i rischi di sicurezza unici posti dagli agenti di IA, in particolare riguardo all'injection di prompt, all'uso improprio degli strumenti e all'esecuzione remota di codice (RCE).

Metodologia

Gli autori hanno condotto due distinti test di penetrazione nel 2025 contro prodotti proprietari di agenti di IA, seguiti da un'analisi completa di un sistema open-source (OpenClaw) per contestualizzare i risultati.

1. Caso di Studio 1: GitHub Assistant

   • Obiettivo: Un assistente AI proprietario progettato per localizzare bug e risolvere le Issue di GitHub all'interno di repository gestiti.
   • Modello di Minaccia: Sono stati modellati due attori: un Contributore GitHub (accesso in sola lettura) e un Proprietario GitHub (accesso in scrittura). Entrambi potevano tentare di compromettere il repository o la piattaforma di hosting dell'agente.
   • Approccio: Il team ha utilizzato un modello di minaccia black-box in cui gli attaccanti non potevano osservare i prompt interni ma potevano manipolare le descrizioni e i commenti delle issue. Hanno analizzato il flusso di lavoro in due fasi dell'agente (Localizzazione e Modifica) e la sua dipendenza dagli strumenti di navigazione dei file e del terminale.
   • Esplorazione delle Vulnerabilità: Il team ha testato l'injection di prompt, cercando specificamente tecniche di "nascondimento Markdown" per eludere la revisione umana, e ha valutato la robustezza delle liste di autorizzazione e negazione dei comandi per gli strumenti del terminale.

2. Caso di Studio 2: Piattaforma di Design degli Agenti

   • Obiettivo: Una piattaforma che consente agli utenti di progettare, testare e distribuire agenti chatbot con strumenti personalizzati.
   • Modello di Minaccia: Un utente legittimo della piattaforma che distribuisce un agente malevolo.
   • Approccio: Il team si è concentrato sul fatto che l'ambiente di esecuzione e l'integrazione degli strumenti permettessero l'escalation dei privilegi o la fuga dal sandbox. Hanno testato l'interprete Python e un costruttore di strumenti personalizzato per la capacità di eseguire comandi di sistema arbitrari.

3. Caso di Studio 3: Analisi di OpenClaw

   • Obiettivo: Un assistente personale open-source alimentato da LLM (OpenClaw) integrato con piattaforme di messaggistica.
   • Approccio: Un'analisi del codice (a febbraio 2026) per valutare le difese integrate (lista di autorizzazione, sandboxing, verifica formale) contro le capacità intrinseche del sistema di auto-modificarsi ed eseguire operazioni a livello di host.

Risultati e Scoperte Chiave

1. I Sistemi Proprietari Condividono le Vulnerabilità Open-Source

Contrariamente all'assunzione che processi di sviluppo più rigorosi eliminerebbero le falle di sicurezza, i sistemi proprietari testati hanno mostrato vulnerabilità sorprendentemente simili a quelle dei framework open-source. I problemi principali erano difese insufficienti contro l'injection di prompt e un'eccessiva dipendenza da strategie di mitigazione deboli.

2. Injection di Prompt e "Nascondimento Markdown"

Nel caso di GitHub Assistant, gli attaccanti hanno compromesso con successo l'integrità del repository e la piattaforma di hosting utilizzando l'injection di prompt.

• Nascondimento Markdown: Gli attaccanti hanno incorporato istruzioni malevole all'interno della sintassi Markdown (ad esempio, testo di link vuoto) che appariva innocua ai revisori umani ma rimaneva visibile ed eseguibile all'agente che elaborava il testo grezzo.
• Conseguenza: Ciò ha permesso agli attaccanti di falsificare le tracce di errore, manipolare il ragionamento dell'agente e istruirlo a modificare copie locali del repository o eseguire comandi del terminale, eludendo efficacemente i flussi di lavoro di approvazione umana.

3. Inadeguatezza delle Liste di Autorizzazione dei Comandi

Lo strumento del terminale in GitHub Assistant si basava su una lista di autorizzazione e una di negazione statiche dei comandi.

• Meccanismi di Bypass: Gli attaccanti hanno sfruttato funzionalità meno conosciute dei comandi consentiti. Ad esempio, mentre find -exec era vietato, il flag -ok rimaneva consentito, permettendo l'esecuzione di comandi arbitrari con prompt di conferma. Allo stesso modo, sed supportava l'esecuzione tramite il comando e.
• Risultato: Questi primitivi di esecuzione indiretta hanno permesso l'Esecuzione Remota di Codice (RCE) sulla piattaforma di hosting, portando a shell reverse e all'accesso a risorse interne sensibili come l'archiviazione di oggetti cloud.

4. Fallimenti nell'Infrastruttura e nell'Isolamento

Entrambi i sistemi proprietari hanno sofferto di un isolamento insufficiente:

• Debolezze dei Container: I container di hosting mancavano di restrizioni di rete in uscita rigorose, filtraggio delle chiamate di sistema e un'adeguata sanificazione. Artefatti sensibili (certificati SSL, variabili d'ambiente) erano presenti nell'ambiente del container.
• Persistenza dei Dati: L'archiviazione del container non era completamente effimera, permettendo la fuoriuscita di dati tra sessioni in cui un utente poteva accedere ad artefatti da esecuzioni precedenti.
• Lacune nel Monitoraggio: Il monitoraggio di sicurezza tradizionale non è riuscito a rilevare l'attività malevola dell'agente perché le azioni originavano da servizi interni fidati e non da IP esterni, creando efficacemente una "minaccia interna controllabile".

5. OpenClaw: Il Rischio Intrinseco del Potere

L'analisi di OpenClaw ha rivelato che anche con difese a più livelli (verifica formale, sandboxing, lista di autorizzazione), l'architettura del sistema crea rischi intrinseci.

• Auto-modifica: Poiché l'agente esegue con privilegi di utente host e ha accesso al proprio codice sorgente, una sessione compromessa potrebbe teoricamente alterare la propria configurazione o il proprio codice per disabilitare le funzionalità di sicurezza.
• Usabilità vs Sicurezza: Le politiche di lista di autorizzazione granulare sono state trovate complesse e soggette a errori di configurazione, potenzialmente indebolendo le protezioni.

Contributi Chiave

• Evidenza Empirica sugli Agenti Proprietari: Il documento fornisce la prima evidenza empirica dettagliata che gli agenti di IA proprietari, nonostante cicli di sviluppo rigorosi, rimangono vulnerabili alle stesse classi di attacchi (injection di prompt, uso improprio degli strumenti) dei corrispettivi open-source.
• Identificazione del Fallimento "Human-in-the-Loop": Lo studio dimostra che l'approvazione dell'utente è un controllo di sicurezza insufficiente quando combinato con tecniche di offuscamento come il nascondimento Markdown, poiché gli umani non possono rilevare in modo affidabile istruzioni malevole nascoste alla vista.
• Critica al Filtraggio Statico: I risultati evidenziano i limiti del matching di pattern statico nelle liste di autorizzazione/negazione in sistemi dinamici che generano codice, mostrando come comandi legittimi possano essere armati.
• Analisi del Divario Infrastrutturale: Il documento identifica un divario critico tra le ipotesi tradizionali di sicurezza dell'infrastruttura (progettate per applicazioni statiche) e le realtà dell'esecuzione guidata da agenti (generazione dinamica di codice da fonti fidate).

Significato e Raccomandazioni

Il documento sostiene che il carico di sicurezza sui sviluppatori è aumentato significativamente a causa della natura complessa e a più livelli degli agenti di IA. Gli autori concludono che i mandati di "sviluppo sicuro" sono insufficienti; invece, l'industria deve fornire strumenti di sicurezza "plug-and-play".

Raccomandazioni Principali:

1. Sandboxing: Il codice eseguito dagli agenti deve essere trattato come non attendibile. Ciò richiede l'applicazione del privilegio minimo, l'uso dell'isolamento dei container (namespace, enforcement a livello di kernel) e la restrizione dell'egresso di rete.
2. Controllo degli Accessi Granulare: Superare il controllo degli accessi basato sui ruoli per passare a un controllo degli accessi basato sugli attributi e obbligatorio che vincoli le capacità dell'agente in base al contesto (identità dell'utente, sensibilità dei dati).
3. Sanificazione Input/Output: Trattare tutti gli input (prompt, dati del repository) e gli output come non attendibili, validandoli rispetto a schemi strutturati e politiche semantiche prima dell'invocazione degli strumenti.
4. Osservabilità Specializzata: Implementare registrazioni specifiche per i flussi di lavoro agenziali (triplette pensiero, azione, osservazione) per abilitare l'analisi forense e il rilevamento di comportamenti errati che la registrazione tradizionale non coglie.

Il documento afferma che senza queste misure di difesa in profondità, gli agenti di IA continueranno a fungere da interni controllabili capaci di eseguire logica arbitraria all'interno di ambienti fidati, rappresentando un rischio significativo per l'integrità e la riservatezza del sistema.