Reward hacking e specification gaming: perché gli agenti LLM sfruttano ogni scorciatoia e come contenerli
Dai circa sessanta esempi documentati da Krakovna/DeepMind (2020) al paper Apollo Research del dicembre 2024 sull'in-context scheming (o1, Opus 3, Sonnet 3.5, Gemini 1.5 Pro, Llama 3.1 405B), il pattern è invariato: se misuri un obiettivo algoritmicamente, l'agente trova una scorciatoia senza risolvere il problema reale. Analizzo specification gaming, sandbagging, self-preservation, e propongo un'architettura di containment a cinque layer applicabile oggi su agenti aziendali. Continua a leggere
Ultima modifica:
Un agent LLM che può eseguire codice Python, Bash o SQL in autonomia è una backdoor delegata. Permetterlo in produzione senza sandboxing è irresponsabile. La mia architettura usa container effimeri, seccomp filter che bloccano syscall pericolose, capability dropping, network namespace che taglia l'egress. Ti mostro il design, i trade-off performance vs sicurezza, e i test di escape eseguiti per validare l'isolamento. 
Un RAG aziendale indicizza documenti interni e risponde alle domande. Se un attaccante inietta un documento nel corpus, può manipolare le risposte per tutti gli utenti. Ti racconto la metodologia di red team che applico: exfiltration di chunk sensibili, pivoting tra tenant multi-azienda, poisoning persistenti. Con tre proof-of-concept e il pattern di difesa applicativa. 
Dal punto di vista di un attaccante, il codice LLM-generated è una miniera d'oro. I pattern ricorrenti - concatenazione di input in query, gestione uniforme degli errori che leak info sensibili, assunzioni di sanitizzazione fatte dall'LLM senza dirlo - sono sfruttabili con PoC mirati. Ti racconto 5 classi di attacco osservate su codice reale, con exploit dimostrato e la strategia di difesa applicativa che uso in audit. 
Security testing manuale è costoso e non scala. Ho costruito un layer di security testing automatico nella pipeline GitHub Actions di un cliente: PHPStan per l'analisi statica, OWASP ZAP in modalità baseline per il DAST, Trivy per i container. Zero colli di bottiglia, il tempo di CI è aumentato solo di 4 minuti. 
JWT è facile da implementare male. Ho trovato algorithm confusion attack (alg: none) in tre API Laravel auditate nell'ultimo anno - una vulnerabilità che permette di forgiare token validi senza conoscere il segreto. Vi spiego le vulnerabilità tipiche e il pattern di implementazione sicura con firebase/php-jwt. 
Ho trovato una vulnerabilità critica in un gestionale PHP usato da 300 PMI italiane. Non era un mio cliente. La gestione della disclosure è stata complicata: il vendor non aveva un canale dedicato, i tempi di fix erano incerti, e le PMI erano a rischio. Vi racconto come ho gestito ogni fase. 
Dopo la compromissione di un'applicazione Laravel, il cliente voleva sapere come erano entrati e cosa avevano preso. Ho ricostruito la kill chain completa dai log di Nginx, PHP, MySQL e dal filesystem: webshell caricata tramite IDOR + unrestricted upload, backdoor persistente in un file di configurazione. Vi mostro il metodo. 
Su cinque API Laravel con OAuth 2.0 auditate nell'ultimo anno, quattro avevano almeno una vulnerabilità critica nell'implementazione. La più comune era l'assenza di validazione del parametro state, che apre a attacchi CSRF sull'autorizzazione. Vi mostro le vulnerabilità, i payload di test e le fix. 
Ho trovato un SSRF in un sistema di webhook di un SaaS Laravel durante un assessment. Il client HTTP di Laravel, senza validazione dell'URL di destinazione, permetteva di raggiungere i metadata AWS e l'intranet del cliente. Vi spiego il percorso di exploitation completo e le tre righe di codice che lo avrebbero impedito.