LangChain, LangGraph, LlamaIndex, CrewAI e AutoGen: sicurezza delle applicazioni agentiche custom

Con LangChain, LangGraph, LlamaIndex, CrewAI e AutoGen il team non usa solo un coding assistant: costruisce applicazioni in cui un LLM ragiona, recupera contesto, usa strumenti, chiama API e coordina passaggi. La superficie di sicurezza non è più solo quella di una web app o di un modello isolato, ma comprende il runtime agentico, i tool, la memoria, il retrieval e le autorizzazioni che li governano.

Il punto non è decidere se l’AI sia una buona o cattiva scelta per lo sviluppo. Il punto è molto più pratico: capire quali controlli servono quando un risultato generato o accelerato dall’AI entra in un prodotto, in un workflow aziendale o in un ambiente con dati reali. Questo articolo si rivolge a founder, CTO, developer e team IT/security che costruiscono applicazioni agentiche custom e vogliono capire dove concentrare i controlli: tool abuse, RAG poisoning, memory poisoning, permessi e output non validati.

Perché un’app che funziona non è necessariamente sicura

Gli strumenti AI riducono il tempo necessario per creare codice, interfacce, workflow, test e configurazioni. Questa velocità può però comprimere i passaggi che normalmente rendono il software affidabile: threat modeling, review, gestione dei segreti, controlli sui ruoli, validazione degli input, verifica delle dipendenze e test manuale dei percorsi critici.

Una demo funziona con un solo utente, dati fittizi e permessi impliciti. La stessa logica può fallire quando arrivano clienti reali, tenant multipli, ruoli diversi, API pubbliche, integrazioni, dati personali, pagamenti o automazioni con effetti esterni. Per questo la sicurezza va valutata sul comportamento reale dell’app, non sulla promessa del tool che l’ha generata.

Tool calling e permessi eccessivi

Ogni tool concesso all’agente è un permesso applicativo a tutti gli effetti. Lettura, scrittura, email, ticket, database, shell o CRM devono avere scope minimo, policy esterna al modello, audit log e conferma esplicita per le azioni sensibili. Delegare al prompt la gestione dei permessi è uno degli errori più comuni e più pericolosi nelle applicazioni agentiche: le regole critiche devono stare in codice, policy e controlli server-side, non nel system prompt.

RAG, memoria e contesto non fidato

Documenti, ticket, pagine web, email e knowledge base possono contenere istruzioni ostili. Il retrieval deve filtrare per autorizzazione e il contenuto recuperato non deve poter sovrascrivere le policy di sistema o i permessi dell’utente. Il rischio di RAG poisoning e memory poisoning tra sessioni o tenant è concreto e spesso sottovalutato: un documento malevolo inserito nella knowledge base può alterare il comportamento dell’agente in modo non rilevabile senza test specifici.

Output handling e decisioni automatizzate

L’output del modello non va usato direttamente per generare HTML, costruire query, eseguire comandi, chiamare API, gestire autorizzazioni o prendere decisioni irreversibili. Servono validazione strutturata, schema, allowlist, sandbox e test con input malevoli prima che qualsiasi output raggiunga un sistema reale.

Rischi principali da controllare

I rischi che seguono non sono teorici: riguardano il comportamento concreto dell’applicazione su dati reali, e vanno verificati su evidenze, configurazione, comportamento runtime e impatto effettivo.

Prompt injection diretta e indiretta: istruzioni ostili iniettate nel prompt o nei documenti recuperati dal sistema.
Tool abuse con permessi eccessivi: agenti che possono eseguire azioni non autorizzate perché i tool non hanno scope limitato.
RAG poisoning e documenti ostili: contenuti malevoli nella knowledge base che alterano il comportamento dell’agente.
Memory poisoning tra sessioni o tenant: contaminazione della memoria persistente che influenza sessioni successive o utenti diversi.
Sensitive information disclosure: dati sensibili esposti attraverso output, log o risposte del modello.
Output non validato verso API o shell: risultati del modello usati direttamente come input per sistemi esterni senza sanitizzazione.
Autorizzazioni delegate al prompt: logica di controllo accessi affidata al system prompt invece che a policy server-side.

Questi rischi vanno collegati al perimetro concreto dell’applicazione. Un’app esposta richiede test applicativi manuali; una modifica critica al codice richiede review; un workflow interno richiede controllo di permessi e credenziali; un’app agentica richiede test su prompt, tool e output. La combinazione corretta dipende dall’impatto reale, non dal nome del tool usato per costruirla.

Controlli minimi prima del go-live

Mappare utenti, ruoli, dati reali, integrazioni, ambienti e owner del servizio.
Identificare quali parti sono state generate o modificate con AI e chi le ha revisionate.
Verificare autorizzazioni server-side, tenant isolation e funzioni amministrative.
Cercare segreti in codice, prompt, log, variabili d’ambiente, build e cronologia del repository.
Controllare dipendenze, licenze, pacchetti, template, plugin e componenti generati.
Testare input ostili, error handling, logging, rate limit e percorsi non previsti.
Separare fix bloccanti, remediation pianificata e rischio residuo accettato.
Ripetere il test o il retest dopo correzioni che toccano flussi critici.

Quando serve una verifica indipendente

Serve una verifica indipendente quando l’app o il workflow gestisce dati reali, utenti esterni, ruoli, API, integrazioni aziendali, pagamenti, storage, workflow automatici o codice critico generato con AI. Serve anche quando il team non riesce a dimostrare quali parti siano state revisionate e quali controlli blocchino regressioni o abusi.

Per applicazioni agentiche il perimetro consigliato comprende: AI Application Testing, Code Review e Secure Architecture Review. La review più utile non è generica: deve produrre finding riproducibili, priorità di remediation, indicazione del rischio residuo e, quando necessario, retest dopo le correzioni.

Domande operative per founder, CTO e security team

Quali dati reali entrano nel sistema e dove vengono salvati, loggati o inviati?
Quali ruoli esistono e quali azioni sono bloccate lato server, non solo nell’interfaccia?
Quali segreti, token, webhook o credenziali permetterebbero accesso a sistemi critici?
Quali parti sono state generate o modificate dall’AI e quali sono state revisionate da una persona competente?
Quali test coprono abuso, errori, ruoli diversi e tenant diversi, non solo il percorso felice?
Quale evidenza può essere mostrata a clienti, audit, procurement o direzione?

Approfondimenti utili

AI Application Testing: approfondisce metodologie e perimetro dei test su applicazioni che integrano LLM, senza duplicare il focus di questo articolo.
OWASP Top 10 Agentic AI: panoramica sui rischi classificati da OWASP per le applicazioni agentiche, utile come riferimento normativo e di prioritizzazione.
Rischi MCP server e coding agent: analisi specifica dei rischi legati ai Model Context Protocol server e agli agenti di coding.
Sicurezza API key e workflow AI: guida alla gestione sicura delle credenziali nei workflow che integrano modelli AI.

FAQ

Qual è la differenza tra app LLM e app agentica?
Un’app agentica non si limita a rispondere a un prompt: recupera contesto, pianifica, usa strumenti, chiama API o coordina passaggi con effetti esterni su sistemi reali.
Il prompt può essere una barriera di sicurezza?
No. Le regole critiche devono stare in codice, policy, permessi e controlli server-side. Il system prompt può guidare il comportamento del modello, ma non è un meccanismo di sicurezza affidabile.
Come si testa la prompt injection indiretta?
Inserendo istruzioni ostili in documenti, pagine, ticket o record recuperati dal sistema e verificando tool call, output e accesso ai dati nelle risposte dell’agente.
Quando serve AI Application Testing?
Quando l’app integra LLM, RAG, memoria, tool calling, agenti o workflow con azioni su sistemi reali, specialmente se gestisce dati sensibili o utenti esterni.
Serve anche una Code Review?
Sì. Bisogna leggere autorizzazioni, tool wrapper, validazione dell’output, retrieval, logging, gestione dei segreti e limiti operativi: aspetti che un test applicativo da solo non copre.

Vuoi un codice sicuro e conforme?

Affidati a ISGroup per:

Code review professionale di terza parte
Metodologie e tecnologie avanzate di analisi
Integrazione di sicurezza e qualità nello sviluppo

Parla con un esperto

Non perderti il meglio della cybersecurity.

Ogni settimana, analisi esperte, attacchi reali e soluzioni concrete: tutto in un’unica newsletter.

Iscriviti alla newsletter Cyber Weekly

Sicurezza delle applicazioni agentiche: LangChain, LlamaIndex, AutoGen e i rischi da controllare