Azienda di Sicurezza IA per sistemi IA e LLM

Un'azienda di sicurezza IA protegge i sistemi di intelligenza artificiale e LLM da attacchi avversariali, prompt injection, avvelenamento dei dati e furto di modelli. Berghem è un'azienda brasiliana di sicurezza IA che serve l'America Latina, offrendo pentest IA/LLM, Red Team per l'IA e governance allineata a ISO 42001, all'EU AI Act e al NIST AI RMF.

I sistemi agentici ampliano questa superficie di attacco — per proteggere agenti autonomi con accesso a strumenti e memoria, vedi sicurezza degli agenti IA.

La sicurezza degli LLM è la disciplina che protegge i grandi modelli linguistici e lo stack che li porta in produzione — prompt di sistema, guardrail, pipeline di retrieval (RAG), chiamate a strumenti, memoria, plugin e gli output che alimentano i sistemi downstream. A differenza delle applicazioni tradizionali, un LLM non separa i dati dalle istruzioni: qualsiasi testo che entra nel contesto può essere interpretato come un comando. Questo rende sfumato il confine di fiducia e crea classi di attacco che non esistono nel software convenzionale.

In pratica, proteggere un LLM significa trattare ogni punto in cui il testo non attendibile incontra il modello come una superficie di attacco. Un documento recuperato tramite RAG, la cronologia della conversazione, il contenuto di una pagina che l'agente naviga, il valore restituito da uno strumento — tutti possono veicolare istruzioni malevole. Per questo Berghem valuta il sistema end-to-end, e non solo il modello isolato: il rischio quasi sempre risiede nel modo in cui il modello è integrato, orchestrato ed esposto.

La sicurezza degli LLM poggia su tre fronti complementari. Il fronte offensivo — pentest di LLM e Red Team avversariale — sollecita il sistema con prompt injection, jailbreak, estrazione del prompt di sistema, invocazione insicura di strumenti e input avversariali, producendo prove di sfruttamento riproducibili. Il fronte difensivo rafforza i guardrail, valida e sanifica gli output, applica il principio del privilegio minimo agli strumenti e limita il consumo di risorse. Il fronte di governance garantisce che decisioni, dati di addestramento e fornitori siano tracciabili e verificabili.

Ogni dimensione richiede i propri controlli. La gestione dell'input deve presumere che ogni testo nel contesto sia ostile finché non si dimostri il contrario. La gestione dell'output deve validare, effettuare l'escape e non eseguire mai ciecamente ciò che il modello restituisce. Il livello degli strumenti deve concedere il più piccolo insieme di permessi possibile e richiedere conferma per le azioni sensibili. I dati di addestramento e di fine-tuning necessitano di provenienza verificabile per resistere all'avvelenamento. E il consumo — token, chiamate e costo — deve avere limiti che prevengano abuso e denial of service.

Il modello di minaccia di un LLM differisce radicalmente da quello di una API tradizionale. In una API, il confine tra codice e dati è rigido e noto; in un LLM, quel confine è probabilistico e dipende dal contenuto stesso. Un attaccante non ha bisogno né di un errore di memoria né di una SQL injection — basta redigere un testo abbastanza persuasivo perché il modello dia priorità all'istruzione malevola rispetto alla policy di sistema. La prompt injection indiretta aggrava il quadro: il payload ostile può trovarsi in un'e-mail, in una pagina web, in un PDF o in un record di database che il modello si limita a leggere. Per questo la superficie di attacco di un LLM include tutto ciò che può finire nel suo contesto, e non solo l'interfaccia esposta all'utente finale.

L'approccio di Berghem alla sicurezza degli LLM parte da una ricognizione dell'architettura e dei flussi di dati, seguita da un threat modeling specifico per l'IA usando l'OWASP LLM Top 10, il MITRE ATLAS e la Promptware Kill Chain. Da lì eseguiamo test offensivi mirati — prompt injection diretta e indiretta, jailbreak, estrazione del prompt di sistema, abuso di strumenti e RAG poisoning — e documentiamo ogni sfruttamento con evidenza riproducibile. Chiudiamo il ciclo con raccomandazioni di remediation prioritizzate per rischio e, quando il cliente lo desidera, monitoraggio continuo che rileva regressioni e nuovi vettori man mano che il sistema evolve. L'obiettivo non è solo trovare le falle, ma rendere il sistema misurabilmente più difficile da compromettere.

Gli agenti IA vanno oltre la risposta testuale: pianificano, decidono e agiscono — invocando strumenti, navigando sul web, eseguendo codice e mantenendo memoria tra i passaggi. Ognuna di queste capacità amplia la superficie di attacco. Un agente compromesso da prompt injection indiretta può esfiltrare dati, concatenare chiamate pericolose a strumenti o persistere istruzioni malevole nella propria memoria, trasformando un singolo input ostile in una catena di azioni autonome. Proteggere gli agenti richiede privilegio minimo per strumento, conferma umana per le azioni sensibili, isolamento della memoria e registrazione verificabile di ogni decisione. Approfondisci la sicurezza degli agenti IA per capire come valutiamo e blindiamo i sistemi agentici in produzione.

Ogni fornitore di security testing promette di trovare vulnerabilità. Pochi possono garantire che ogni finding nel report sia reale, sfruttabile e correttamente prioritizzato — questa è la differenza tra un report che genera azione e un report che genera rilavorazione.

Un singolo falso positivo che arriva al cliente non è rumore operativo: è erosione di fiducia. Il cliente perde ore a investigare qualcosa che non esiste, mette in dubbio gli altri findings per associazione, e il costo reputazionale supera il valore dell'intero engagement. La nostra metodologia parte da una premessa non negoziabile — nessun finding arriva al cliente senza evidenza meccanica che lo renda difendibile.

Per applicazioni e API tradizionali, lo stesso rigore guida il nostro pentest — il penetration test manuale di Berghem nei livelli Silver, Gold e Diamond.