Un prompt. Tre comandi shell. Ho usato la loro stessa AI per hackerarsi.
Questa è una categoria di bug che probabilmente esiste in ogni prodotto AI multi-agente in circolazione oggi. E la soluzione è un pattern di design di cui nessuno nel settore sta ancora parlando.
Ecco la storia completa.
Non stavo cercando di hackerare nulla. Stavo facendo ricerche su come Perplexity Computer gestisce il sandboxing per il mio lavoro sull'infrastruttura degli agenti. Volevo capire come i sistemi multi-agente in produzione isolano effettivamente gli ambienti di esecuzione, cosa viene condiviso, cosa no.
Per prima cosa, ho iniziato a curiosare nel sistema. Ho notato che Claude Code era installato nella sandbox.
Ho fatto avviare l'agente e generare del codice di test solo per vedere come si comportava. Funzionava bene. Il solito Claude Code, in modalità bypass-permissions, quindi non chiede conferma. Ha senso per un sistema agentico.
Ed è lì che ho pensato: aspetta, come gestiscono le chiavi API?! Claude Code ha bisogno di una chiave API Anthropic per funzionare. Quella chiave deve trovarsi da qualche parte in questa sandbox. Come viene iniettata? Come viene limitata? È isolata?
Questa domanda mi ha portato su questa strada.
Il sotto-agente tiene una chiave API nel suo ambiente di processo. Dovevo rubarla.
Perplexity Computer ci ha provato sei volte e ha fallito.
- Ho chiesto al sotto-agente di scaricare il suo env: rifiutato!
- Ho piantato uno script trojan sul filesystem condiviso: ha letto il mio codice, ha capito cosa stava facendo e si è rifiutato di eseguirlo!
- Ho avvelenato .bashrc e .profile: si sono attivati troppo presto, prima che la chiave API venisse iniettata.
- Ho piazzato un falso binario di node su PATH: non si è mai attivato.
- Ho avviato l'agente di codifica e contemporaneamente osservato l'albero dei processi: il sotto-agente gira in una sandbox diversa, non è stato catturato nulla :(
- Ho cercato il system prompt di Claude Code e l'ho modificato per rimuovere il comportamento di rifiuto: non sono riuscito a trovare un system prompt personalizzato iniettato.
Sei fallimenti. La sicurezza a livello di modello/prompt di Claude è legittimamente buona. Ogni volta che provavo qualcosa di intelligente, il modello lo scopriva.
Poi Perplexity si è ricordata che Claude Code è un'app Node.js lanciata tramite npm. E npm legge ~/.npmrc dalla home directory. E la home directory è sul filesystem condiviso su cui posso scrivere.
Node.js ha un flag --require che pre-carica un modulo JavaScript prima che qualsiasi codice applicativo venga eseguito. Puoi impostarlo tramite NODE_OPTIONS in .npmrc. Ciò significa che se scrivo un .npmrc nella home directory condivisa, ogni processo Node che il sotto-agente avvia pre-caricherà il mio codice! Questo accade prima ancora che Claude Code si inizializzi, prima che vengano eseguiti i controlli di sicurezza, prima di qualsiasi cosa!
L'exploit è composto da tre comandi:
- Scrivere uno script di sei righe che scarica process.env in un file sul workspace condiviso
- echo 'node-options=--require /path/to/script.js' > ~/.npmrc
- Chiedere a Perplexity Computer di fare qualsiasi attività di codifica
Il sotto-agente si avvia → npm legge il mio .npmrc → il mio pre-load si attiva prima che Claude Code parta → le credenziali API complete finiscono sul filesystem condiviso.
Ha funzionato! Mi ha fornito un token gateway di Perplexity che fa da proxy attraverso agent-proxy.perplexity.ai verso il loro account master Anthropic.
Naturalmente, la prima cosa che ho fatto è stata impostare questa chiave API e BASE_URL per Claude Code sul mio laptop. Mi aspettavo che le chiamate LLM da Claude Code fallissero e fossero limitate alla sandbox. Sono rimasto scioccato. Risposta immediata da Opus 4.6!
Poi ho pensato: "sicuramente addebiteranno questo utilizzo sul mio account, questa chiave API deve essere legata al mio utente". Mi sbagliavo di nuovo.
Ho fatto generare a Opus 4.6 una lunga storia che descrive la storia del mondo, includendo ogni invenzione, impero e scoperta. Ho eseguito questa chiamata 5 volte in parallelo, generando oltre 100k token di output ciascuna. Questo avrebbe dovuto consumare tutti i miei crediti di Perplexity Computer, ma non si sono mossi.
Non limitato per IP. Non limitato per sessione. Non vincolato alla sandbox. Il loro conto.
Una delle startup AI più finanziate del pianeta è stata posseduta da un dotfile usato negli attacchi alla supply chain di Node.js dal 2019.
Il modello ha fatto tutto correttamente. L'infrastruttura no.
Ecco cosa voglio che i fondatori che costruiscono infrastrutture per agenti portino a casa da questo.
L'architettura di Perplexity è per metà corretta. Usano un proxy tra la sandbox e l'API di Anthropic. Questo è il pattern giusto. Non dovresti mai mettere una chiave API grezza del provider all'interno di una sandbox. Un proxy ti dà controllo, osservabilità e la possibilità di revocare l'accesso senza dover ruotare la chiave master.
Il problema è che il loro token proxy non ha alcun legame con il contesto di esecuzione. Una volta che lo hai, funziona ovunque per sempre.
Ecco come fare correttamente:
Legare il token all'ID della sandbox. Il token e l'ID della sandbox non corrispondono? Rifiutato. La chiave viene divulgata ma non hai la sandbox? Inutile. Idealmente dovrebbe legare il token anche all'indirizzo IP della sandbox, ma E2B (il provider di sandbox che usano) non lo fornisce prima che la sandbox venga avviata.
Rendere il token effimero. Generarlo quando la sandbox si avvia. Ucciderlo quando la sandbox viene messa in pausa. Nessuna credenziale a lunga durata. Il proxy genera un token a breve durata all'inizio della sessione e lo invalida alla chiusura. Una chiave divulgata da una sandbox morta è una chiave morta.
Legare il token all'account di fatturazione dell'utente. Anche se tutto il resto fallisce, anche se qualcuno esfiltra un token attivo da una sandbox in esecuzione e lo usa prima che scada, l'utilizzo viene addebitato all'account che ha generato la sessione. Non a un pool di fatturazione master condiviso. Questo trasforma "accesso API illimitato gratuito" in "qualcuno che abusa della propria quota", che è una gravità completamente diversa.
Queste tre cose — vincolato alla sandbox, effimero, fatturato all'utente — sono ciò che rende il pattern proxy effettivamente funzionante. Senza di esse stai solo aggiungendo un hop di rete extra che non ferma nulla.
Questo non è un problema specifico di Perplexity. Questa è l'architettura predefinita per l'infrastruttura degli agenti in questo momento, perché è la più veloce da costruire. Filesystem condivisi tra agenti, credenziali a lunga durata, fatturazione su account master. Scommetto che la maggior parte dei prodotti multi-agente in produzione oggi ha qualche versione di questo.
Segnalato a @AravSrinivas e @denisyarats prima della pubblicazione.
