Avete diviso il lavoro tra tredici agenti. Paperclip non ha diviso la chiave.

Ha fatto la cosa moderna. Invece di un unico agente grande, ha messo in piedi una flotta — uno per classificare i ticket, uno per scrivere i testi, uno per gestire la pipeline di design, una dozzina in tutto, ciascuno con il proprio compito e la propria config. Così sembra più sicuro. Superficie di danno più ridotta. Più least-privilege.

Poi una scansione di sicurezza ha attraversato le config di un framework di agenti da 71.000 stelle chiamato Paperclip e ha trovato che dodici dei suoi tredici agenti portavano le stesse credenziali — un token identico, incollato in chiaro nella config di ciascun agente [1]. Una chiave API Anthropic era hardcoded nella config di un agente di design, in chiaro. Un token di bot destinato a un solo agente era leggibile da agenti che non avevano alcun titolo per utilizzarlo.

Tredici porte. Una chiave, copiata in dodici di esse. La si ruba dall'agente più debole e si hanno gli altri undici.

Cosa è successo davvero

Paperclip assegna a ciascun agente una config del server MCP — il file che indica all'agente quali strumenti e servizi può raggiungere e come autenticarsi presso di essi. Da qualche parte lungo il percorso i segreti sono finiti direttamente in quei file come testo letterale: un JWT n8n, un bearer token, una chiave API Anthropic. Non referenziati. Non iniettati a runtime. Digitati — e poi, visto che creare l'agente successivo è un copia-incolla, duplicati su tutta la flotta.

La scansione ha segnalato tre cose. I token in chiaro condivisi tra dodici agenti (classificati HIGH). La chiave Anthropic presente in chiaro nella config di un agente di design (classificata CRITICAL). E un token di bot con ambito esteso ad agenti per cui non era mai stato pensato — una semplice violazione del least-privilege [1]. A loro merito, il team di Paperclip si è mosso in fretta: ha migrato ai riferimenti alle credenziali, ha oscurato le config nelle letture tra agenti e ha iniziato a imporre la sincronizzazione dei binding [2]. La direzione giusta.

Non è negligenza di Paperclip

Ecco la parte su cui vale la pena fermarsi. Paperclip ha fatto quello che fa quasi ogni framework. Mettere un segreto in un file di config è il modo in cui il software si autentica da trent'anni. Funzionava perché c'era un'applicazione, una config, un operatore che sapeva dove si trovava la chiave.

L'era è cambiata sotto quell'abitudine. Un sistema multi-agente non è un'applicazione con una config — è una dozzina di processi, ciascuno con un file, ciascuno copia del precedente. Testo in chiaro nella config era uno scorcio tollerabile quando c'era un solo punto da cui poteva fuoriuscire. A tredici, lo stesso scorcio significa che una fuoriuscita sono tredici fuoriuscite — e «quale agente l'ha fatto?» non ha risposta, perché il token nel log apparteneva a tutti loro.

I riferimenti alle credenziali — la correzione rilasciata da Paperclip — sono effettivamente migliori. Ma si noti cosa cambiano e cosa non cambiano. Un riferimento si risolve comunque in un segreto reale nel punto in cui l'agente viene eseguito; l'agente, o qualunque cosa lo comprometta, può ancora leggere il valore risolto. E il tracker di bug dello stesso framework mostra già la modalità di guasto successiva: un riferimento che diverge dal proprio binding, così la config sembra compilata mentre la validazione fallisce silenziosamente [3]. Il segreto si è spostato di un livello indietro. Non è uscito dall'edificio.

Non è solo Paperclip

Stessa settimana, stessa causa radice, repository diversi. Un agente di coding ampiamente utilizzato è stato segnalato per aver stampato valori .env grezzi — password, token, chiavi API — direttamente nel proprio output di chat. Un altro runner di agenti è stato trovato mentre passava il proprio ambiente padre completo ai subprocess, rendendo ogni chiave dei provider visibile a un processo figlio [4]. Un hook vocale scriveva trascrizioni, credenziali comprese, in /tmp leggibile da chiunque [5]. Team indipendenti, threat model indipendenti, un'assunzione condivisa: che vada bene per il segreto vivere dove l'agente può vederlo. Tutto l'argomento che un attaccante deve sostenere è che non è così.

Progettato per questo, di proposito

Clavitor parte dall'assunzione opposta: l'agente non detiene mai la credenziale. L'agente richiede un'azione; la richiesta viene intercettata, autenticata contro un segreto che l'agente non può leggere ed evasa. Non esiste una config in cui incollare un token, perché nella config non c'è alcun token. Nulla da copiare su tredici agenti, perché l'ambiente dell'agente non contiene mai ciò che vale la pena rubare.

Ogni agente raggiunge solo ciò per cui è stato nominato — non l'intero archivio — così un token di bot non può finire per essere leggibile da un agente che non lo ha mai richiesto. E ogni azione viene registrata all'attore specifico che l'ha compiuta, mai a un token condiviso che dodici agenti avevano in comune — così «quale l'ha fatto?» ha una risposta.

Il limite, in onestà: questo non rende un agente inviolabile. Un agente compromesso può ancora fare, nel momento, le cose per cui era autorizzato. Ciò che non può fare è portarsi via la chiave e diventare gli altri dodici — perché non ha in mano alcuna chiave da portarsi via.

La lezione non è «ruotare il token»

Paperclip ruoterà i token, completerà la migrerà e chiuderà i problemi. Bene — è quello che deve fare. Ma la rotazione non è la lezione. La lezione è che nel momento in cui si ha una flotta di agenti invece di un'applicazione, «il segreto vive nella config» smette di essere uno scorcio e diventa un moltiplicatore. Un moltiplicatore non si corregge rendendo il segreto un po' più difficile da leggere. Lo si corregge assicurandosi che il segreto non sia mai finito nelle mani dell'agente.

Abbiamo messo per iscritto le regole che riteniamo uno strumento per le credenziali debba rispettare nell'era degli agenti — tra queste, che il segreto non viva mai dove viene eseguito il codice, e che un agente raggiunga solo ciò per cui è stato nominato. Valuti i propri su questi principi: clavitor.ai/rules.

Clavitor (@clavitorai) è il vault di credenziali costruito per gli agenti AI, e contro di essi. clavitor.ai

Fonti

[1] Framework di agenti Paperclip — riscontri sull'igiene delle credenziali (CFG-H1 token in chiaro condivisi, CFG-C1 chiave Anthropic hardcoded, CFG-H2 token di bot con ambito errato): https://github.com/paperclipai/paperclip

[2] Paperclip — applica la sincronizzazione del secret-binding degli agenti nei flussi del ciclo di vita (unito): https://github.com/paperclipai/paperclip/pull/8307

[3] Paperclip — le voci env secret_ref possono divergere dalle righe secret_bindings, la config risulta compilata ma la validazione fallisce silenziosamente (#8309): https://github.com/paperclipai/paperclip/issues/8309

[4] Chetter — runBatchAgent eredita l'ambiente completo del runner, esponendo le chiave API dei provider al subprocess (#56): https://github.com/flatout-works/chetter/issues/56

[5] Claude Code voice hook — trascrizioni complete (credenziali incluse) scritte in /tmp leggibile da chiunque (#58): https://github.com/rodlaneedu-hash/claude-code-voice-hook/issues/58