In un thread Reddit che ha raccolto migliaia di upvote in settantadue ore, il framework era insolitamente chiaro. Una frase del post originale mi è rimasta in mente attraverso ogni chiamata con i clienti da allora: 'Most AI agent ecosystems today heavily depend on open-source packages, GitHub Actions, CI/CD pipelines, cloud credentials, shared deployment tooling, agent orchestration frameworks. One compromised dependency can impact the entire chain.'
La compromissione di LiteLLM emersa nell'aprile 2026 non era, nella sostanza, una storia su una libreria vulnerabile. Era la storia di un control plane che nessuno aveva tracciato su un diagramma. La supply chain di un AI agent è più ampia di quella di un servizio HTTP, perché l'agent dipende non solo dalla libreria che avvolge il modello ma anche dal provider del modello, dal repository di prompt, dal registry degli strumenti, dal servizio di credenziali, dall'orchestration runner e — sempre più — dal MCP server che espone un pezzo di dati interni. Quando uno di questi si rompe, si scopre quali altri erano silenziosamente collegati.
Perché le liste statiche non intercettano questo
La prima reazione che vedo nelle conversazioni con i clienti dopo una violazione come LiteLLM è chiedere: lo usiamo? Poi: quali team lo usano? Poi: quali agent lo usano? La prima domanda è facile. La seconda è più difficile. La terza è, nella maggior parte delle organizzazioni con cui ho lavorato, senza risposta a partire da una lista statica di asset.
Il motivo è strutturale. Gli AI agent si muovono più velocemente degli strumenti di inventario progettati per le flotte SaaS o container. Vengono creati da singoli ingegneri, incorporati in flussi di lavoro interni e connessi a MCP server o skill pack che cambiano ogni settimana. Il CMDB non li vede. Lo strumento CSPM vede il compute su cui girano ma non il grafo delle dipendenze al di sopra. Il sistema di procurement non li ha mai acquistati. L'unica lista autorevole di ciò che è in esecuzione è quella che costruisci ispezionando il confine che attraversano.
Cosa significa davvero "tipo di agent"
Nel modello dati di Hikma, ogni agent è uno di quattro tipi, e il tipo determina il resto della domanda.
- API agent — chiamano i provider di modelli hosted e orchestrano le tool call a livello programmatico. Superficie di dipendenza: l'SDK, il framework di orchestrazione (LiteLLM, LangChain, LangGraph, custom), lo secrets store.
- Agenti di web-automation — guidano un browser o una superficie UI. Superficie di dipendenza: il runtime headless, la logica dei selettori, le credenziali che usa per accedere.
- MCP agent — si connettono a uno o più MCP server che espongono strumenti o dati. Superficie di dipendenza: ogni MCP server, il trasporto (STDIO, HTTP, SSE) e il permesso accordato dall'altro lato.
- Skill agent — installano ed eseguono una skill packaged da una directory o repository. Superficie di dipendenza: la sorgente della skill, la versione, il manifest, il runtime che la esegue.
Quando LiteLLM era la questione, gli agent che contavano erano gli API agent che lo importavano e gli orchestration runner che lo avvolgevano. Quando la prossima libreria sarà la questione — e ci sarà una prossima libreria — la risposta sarà una sezione diversa dello stesso inventario. Non puoi eseguire la query se non hai costruito l'indice.
Audit delle dipendenze, non attestazioni basate sulla fiducia
Un'attestazione che un sistema è sicuro non equivale a un registro di ciò da cui dipende. La domanda post-violazione è sempre retrospettiva: era nel nostro percorso? L'unico modo per rispondere in minuti invece che in settimane è aver già catturato il grafo delle dipendenze per ogni agent prima che la violazione si verificasse.
Questo è il lavoro che la maggior parte delle organizzazioni rimanda fino all'arrivo di un CVE. Poi diventa il lavoro che tutti fanno allo stesso tempo, male, di domenica. Il costo di farlo in anticipo è basso. Il costo di farlo retroattivamente è la chiamata al management quella notte.
Dove il log di audit guadagna il suo posto
L'inventario è metà della risposta. L'altra metà è ciò che l'agent ha effettivamente fatto mentre era in esecuzione. Il log di audit strutturato — quello che inviamo al SIEM, che firmiamo, che rendiamo esportabile — è il luogo in cui un team di sicurezza riproduce i momenti che contano. L'agent ha chiamato l'endpoint interessato tra la finestra di compromissione e la patch? Quali record ha toccato? Quale utente ha impersonato per farlo?
Se il log può rispondere a quelle domande con una ricerca, hai dedicato la tua ora alla remediation invece che alla forensica. Se non può, la prossima violazione sarà più costosa dell'ultima esattamente nel modo in cui il thread su LiteLLM aveva previsto.
Cosa farei questa settimana se gestissi un team di sicurezza
Step 01
Produrre una lista unica di ogni AI agent in produzione, taggato per tipo. Se la lista richiede più di un giorno, la lista è già il finding.
Step 02
Per ogni agent, annotare le tre cose da cui dipende che, se compromesse, lo comprometterebbero. La maggior parte degli agent ne ha più di tre; inizia con tre.
Step 03
Per ogni dipendenza, identificare chi ti notificherebbe se fosse violata, e se quel percorso di notifica arriva nella tua casella di posta prima del thread pubblico su Reddit.
Step 04
Decidere quale log di audit è la fonte di verità per ciò che ogni agent ha fatto la settimana scorsa. Se è più di uno, quello è il prossimo progetto.
Nessuno di quei quattro passaggi richiede Hikma. Richiedono qualche ora e la volontà di scrivere ciò che è vero oggi. Il motivo per farlo non è la prossima libreria. È la conversazione di audit che segue la prossima libreria, e la domanda che vi sarà posta: lo sapevate?
La violazione di LiteLLM ha reso operativa una cosa. La supply chain di un AI agent è più ampia di quanto la maggior parte dei team di sicurezza abbia tracciato su un diagramma. L'inventario è il primo controllo. Tutto ciò che vi si trova sopra dipende dall'onestà di quest'ultimo.
Scritto da
Mauro Medda
Co-Founder & CTO, HikmaAI
