Immagina di costruire una casa con mattoni che non hai fabbricato tu stesso. Ti fidi del produttore, ti fidi della catena di approvvigionamento, ti fidi che quando li impilati, reggeranno. Ora immagina di scoprire che da qualche parte tra il forno e il tuo cantiere, qualcuno ha svuotato ogni decimo mattone e lo ha riempito di esplosivi. Questo è essenzialmente ciò che è accaduto a Mercor nel marzo 2026, quando la startup di reclutamento AI si è trovata coinvolta in un attacco alla catena di approvvigionamento tramite il progetto open-source LiteLLM.
Come qualcuno che ha trascorso anni ad analizzare architetture di agenti e i loro modi di fallimento, trovo questo incidente particolarmente istruttivo. Non è solo un’altra storia di violazione dei dati: è uno studio di caso su come l’infrastruttura stessa che usiamo per costruire sistemi intelligenti possa diventare un vettore per il compromesso.
L’Architettura della Fiducia
LiteLLM funge da interfaccia unificata per diversi fornitori di modelli linguistici, astrando via la complessità di lavorare con diverse API. Per aziende come Mercor che devono orchestrare agenti AI su varie piattaforme, è una soluzione elegante. Scrivi il codice una volta, e LiteLLM gestisce il livello di traduzione verso OpenAI, Anthropic, Cohere, o chiunque altro tu stia utilizzando.
Ma ciò che rende questo attacco tanto insidioso è che il compromesso è avvenuto a livello di dipendenze. Quando Mercor—insieme a migliaia di altre aziende—ha eseguito aggiornamenti ai propri sistemi, non stava solo ottenendo nuove funzionalità o correzioni di bug. Stava importando codice malevolo che era stato iniettato in un componente fidato della loro infrastruttura.
Questo è il compromesso della catena di approvvigionamento nel suo massimo effetto. Gli attaccanti non avevano bisogno di violare le difese perimetrali di Mercor o di ingegnerizzare socialmente i loro dipendenti. Hanno avvelenato il pozzo da cui tutti bevono.
Sistemi di Agenti e Superficie di Attacco
Ciò che rende questo particolarmente rilevante per l’intelligenza degli agenti è la natura dei moderni sistemi AI. Non stiamo più costruendo applicazioni monolitiche. Stiamo costruendo ecosistemi di agenti specializzati che comunicano attraverso API, condividono contesto tramite database vettoriali e orchestrano azioni attraverso middleware come LiteLLM.
Ogni dipendenza in questa catena rappresenta un potenziale punto di fallimento. Quando gestisci una piattaforma di reclutamento AI, ti occupi di dati sensibili dei candidati, informazioni dei datori di lavoro e della logica algoritmica che li abbina. I tuoi agenti hanno bisogno di accesso ai modelli linguistici per analizzare i curricoli, generare comunicazioni e fare raccomandazioni. Tale accesso fluisce attraverso librerie come LiteLLM.
La superficie di attacco non è solo il codice che scrivi: è ogni riga di codice da cui il tuo codice dipende e ogni riga di codice da cui quel codice dipende, ricorsivamente lungo l’albero delle dipendenze. Per un’applicazione moderna tipica, si tratta di migliaia di pacchetti, molti dei quali mantenuti da volontari nel loro tempo libero.
Il Paradosso dell’Open Source
C’è un’amara ironia qui. Il software open source dovrebbe essere più sicuro perché chiunque può esaminare il codice. “Molti occhi rendono tutti i bug superficiali,” come suggerisce la Legge di Linus. Ma, in pratica, la maggior parte degli occhi non sta osservando. La maggior parte degli sviluppatori si fida che qualcun altro abbia già effettuato la revisione della sicurezza.
LiteLLM è open source, il che significa che il codice malevolo era teoricamente visibile a chiunque avesse avuto la voglia di controllare. Ma chi ha il tempo di esaminare ogni aggiornamento di ogni dipendenza? Chi ha l’expertise per individuare sofisticati backdoor nascosti in commit che sembrano legittimi?
Questa non è una critica all’open source: è un riconoscimento che il nostro attuale modello di fiducia non scala. Abbiamo bisogno di strumenti migliori per la verifica delle dipendenze, di migliori incentivi per le revisioni di sicurezza e di modelli architetturali migliori che limitino il raggio d’azione quando un componente è compromesso.
Implicazioni per l’Architettura degli Agenti
Da una prospettiva architettonica, questo incidente dovrebbe spingerci verso design più difensivi. Il principio del minimo privilegio non è solo per i permessi degli utenti: si applica anche alle dipendenze del codice. La tua libreria di interfaccia LLM ha davvero bisogno di accesso al file system? Ha bisogno di permessi di rete oltre ai punti API specifici che sta chiamando?
Dobbiamo pensare alla sandboxing, a modelli di sicurezza basati sulle capacità, a architetture a zero fiducia che assumono che qualsiasi componente possa essere compromesso. Per i sistemi di agenti in particolare, ciò significa progettare con la contenimento in mente. Se un agente è compromesso, come preveniamo il movimento laterale? Come rileviamo comportamenti anomali in sistemi automatizzati che dovrebbero agire autonomamente?
Proseguire
L’esperienza di Mercor—condivisa da migliaia di altre aziende—è una sveglia. Mentre costruiamo sistemi di agenti sempre più sofisticati, non possiamo permetterci di trattare le dipendenze come scatole nere di cui ci fidiamo ciecamente. Abbiamo bisogno di una migliore sicurezza della catena di approvvigionamento, di un migliore monitoraggio e di modelli architetturali migliori che assumano il compromesso piuttosto che sperare di prevenirlo.
La casa di mattoni è ancora in piedi, ma ora sappiamo che alcuni di essi sono vuoti. La domanda è: cosa costruiremo dopo, e come lo faremo diversamente?
🕒 Published: