Perché le allucinazioni LLM non si risolvono col prompting: rappresentazione distribuzionale e limiti architetturali
Nel 2023 Sam Altman prometteva di risolvere le allucinazioni in due anni; nel 2025 OpenAI stessa pubblica "Why Language Models Hallucinate" (arxiv 2509.04664) mostrando che sono strutturalmente inevitabili. AA-Omniscience 2025 di Artificial Analysis: 36 modelli su 40 più propensi a sbagliare che sapere. GPT-5.5 xhigh: 86% hallucination rate vs Opus 4.7 max 36%. Perché il prompting non le elimina, pattern di validazione esterna che funzionano in produzione. Continua a leggere
Ultima modifica:
Un agent LLM con accesso a tool esegue codice in nome dell'utente. Gli stessi principi del least privilege valgono - ma il perimetro è fluido, e l'LLM può essere manipolato. Ti mostro il framework di threat modeling che ho sviluppato: categorie di rischio (privilege escalation, data exfiltration, denial of service), analisi trust boundary, mitigazioni applicative concrete con esempio di agent Laravel + Claude API perimetrato. 
Il motivo per cui GPT-5.4 o Opus 4.7 rispondono in un certo modo non è il pretraining ma l'allineamento. RLHF raccoglie preferenze umane e allena un reward model; Constitutional AI usa principi e fa autocritica; DPO salta il reward model con ottimizzazione diretta; RLAIF sostituisce gli umani con LLM. Confronto operativo con paper primari 2022-2023 e casi in cui ciascuna tecnica fallisce in produzione enterprise. 
L'ecosistema AI è diventato un target di supply chain attack: modelli pubblicati su Hugging Face con backdoor, librerie Langchain/LlamaIndex con transitive dependencies non audit-abili, update automatici che introducono drift di comportamento. Ti mostro la strategia di hardening che applico: pinning dei modelli a digest SHA-256 (non tag), audit automatico delle dipendenze via Snyk/Dependabot, integrity checks su ogni deploy, separazione di ambienti con policy di network egress controllato. 
Un agent LLM che può eseguire query al database, inviare email, chiamare API è una backdoor delegata. Un attaccante che controlla l'input controlla le azioni dell'agent. Ti mostro le classi di prompt injection più pericolose su agent systems, le strategie di difesa applicativa (input validation, output fencing, least privilege), e un esempio concreto di human-in-the-loop gate che ho implementato in un agent Laravel nella mia sandbox di audit. 
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. 
JWT e OAuth sono standard semplici nella teoria, catastrofici nell'implementazione. Nella mia pipeline personale di audit ho costruito un classificatore LLM che analizza l'autenticazione di un progetto PHP e segnala vulnerabilità ricorrenti: algorithm confusion, refresh token deboli, storage insicuro, revocation mancante. Ti mostro il prompt engineering e il catalogo dei pattern pericolosi raccolti nella mia sandbox di audit sistematico. 
Il codice generato da AI sembra pulito ma nasconde classi di vulnerabilità ricorrenti che il contesto non riesce a catturare: SQL injection con parametri concatenati, XSS in output non sanitizzati, API key committate, pattern anti-OWASP. Nella mia sandbox di audit su codice AI-generated ho analizzato 40 output di ChatGPT, Copilot e Claude: ecco il catalogo dei pattern pericolosi e la checklist che applico sistematicamente prima di mergiare qualsiasi codice AI-generated. 
Ho analizzato 200 snippet PHP generati da Copilot e ChatGPT nel contesto di progetti clienti: il 23% conteneva vulnerabilità, di cui il 8% classificabili come high severity. I pattern sono prevedibili: prepared statements dimenticati, input validation assente, errori gestiti con die(). Ecco come fare audit sistematico.