L'intero settore ha appena convenuto che il suo agente non dovrebbe vedere le sue chiavi. Ma le stanno nascondendo nel posto sbagliato.
In una settimana, Claude Code, Hermes e Codex hanno tutti rilasciato correzioni per impedire agli agenti di vedere credenziali in chiaro. Patch convergenti non sono un'architettura: le chiavi non dovrebbero proprio trovarsi nel harness.
Questa settimana Anthropic ha inserito una riga discreta nel changelog di Claude Code: "Fixed MCP servers requiring authentication exposing auth-stub tools to the model in headless/SDK mode" [1]. In termini semplici — quando Claude Code veniva eseguito in modalità headless (come accade in CI e nelle pipeline di agenti automatizzati), gli strumenti di autenticazione che avrebbero dovuto restare nascosti venivano esposti al modello: l'IA poteva vedere i nomi degli strumenti di auth, i relativi parametri e potenzialmente interagire con essi. Nell'agente di coding più usato al mondo — 133k stelle — il livello delle credenziali filtrava nell'ultimo posto in cui la vorrebbe: il contesto del modello stesso.
Il problema è stato corretto. Ma la correzione è la notizia piccola. Quella grande è perché ogni harness di agente serio stia combattendo improvvisamente la stessa battaglia.
Tre harness, una settimana, lo stesso istinto
Guardi cosa è stato rilasciato in una singola finestra di 24 ore:
- Claude Code ha corretto la fuga di auth-stub descritta sopra e ha rafforzato il gating dell'autenticazione MCP [1].
- Hermes (v0.17.0) ha introdotto "Managed Scope" — segreti fissati dall'amministratore e immutabili per l'utente, bloccati a livello di filesystem così che un operatore di agenti non possa sovrascriverli — oltre alla redazione dei segreti nei debug dump e al blocco delle configurazioni MCP con forma di esfiltrazione prima del loro avvio [2].
- Codex (v0.141.0) ha avvolto il traffico di esecuzione remota in canali Noise crittografati e ha iniziato a instradare i plugin in base alla relativa modalità di autenticazione [3].
Tre concorrenti, tre approcci, una conclusione condivisa: il harness deve possedere i segreti, e l'agente non deve mai vedere le chiavi in chiaro. Quando i concorrenti convergono in questo modo nella stessa settimana, non è una moda. È una categoria che ammette finalmente a cosa serve.
Il problema successivo è la proliferazione delle credenziali
Ecco il punto critico. Ognuna di quelle correzioni vive all'interno del harness. E il bug di Claude Code lo dimostra: quando l'autenticazione vive nel harness, accanto al modello, "l'agente non deve mai vederla" smette di essere un fatto e diventa una proprietà che bisogna continuare a progettare — e occasionalmente a far fallire, in modalità headless, dove nessun essere umano sta guardando. Non la si può dichiarare una volta per tutte. La si difende, release dopo release.
Ma il problema più profondo non è una singola fuga — è ciò che accade quando ogni harness, ogni fornitore e ogni caso d'uso rilascia la propria risposta. Si finisce con un vault dentro Claude Code, un vault dentro Hermes, un vault dentro Codex, un pool OAuth qui, un file di segreti lì — un archivio di credenziali separato per ogni strumento che si esegue. Questa è la proliferazione delle credenziali, ed è il prossimo problema, non uno già risolto.
La proliferazione è il fallimento anche quando nessun silo perde. I segreti vengono copiati in ciascuno per farlo funzionare — più copie, più posti da cui rubarli. La rotazione deve avvenire N volte, manualmente, e quella che si dimentica è quella che brucia. E nessuno può rispondere all'unica domanda che conta davvero — quale agente ha usato quale chiave, contro cosa, quando — perché la risposta è sparsa tra una dozzina di archivi che non comunicano tra loro. Non si può istituire un vault nuovo per ogni fornitore e ogni flusso di lavoro. Non è scalabile. È proprio la cosa che si rompe.
Le chiavi non appartengono affatto al harness
La correzione che non si deve mai rilasciare è quella in cui l'agente non detiene l'autenticazione fin dall'inizio. Le credenziali vanno poste in un'unica autorità che si trova fuori da ogni harness — non un vault per fornitore, uno sotto a tutti quanti. L'agente — in Claude Code, in Codex, in Hermes, non fa differenza — richiede una singola azione nominata e riceve una credenziale con ambito limitato ed effimera, iniettata esattamente per quella, recuperata in tempo reale e svanita subito dopo. Non c'è alcun auth-stub nel contesto del modello da esporre accidentalmente, perché l'autenticazione non è mai stata nel harness. Non c'è proliferazione, perché c'è un archivio solo invece di uno per strumento — si ruota una volta, non N volte. E ogni accesso converge su un unico audit trail invece di disperdersi tra una dozzina di silos che non sanno rispondere chi-ha-usato-cosa. (Tenere il segreto fuori dall'ambiente in cui gira il codice è quasi in cima a le regole che uno strumento per credenziali dovrebbe rispettare — il settore ha appena passato una settimana a scoprirlo.)
E questa è la parte che è un confine di sicurezza, non una comodità: la credenziale non può vivere nello stesso sistema dell'agente. Se li si colloca insieme, condividono un raggio d'impatto — un prompt injection, un server MCP avvelenato, un debug dump condiviso, il prossimo bug di auth-stub, e tutto ciò che raggiunge l'agente raggiunge con sé anche le chiavi. Ecco perché la sola visibilità è già la violazione: nel momento in cui un segreto finisce in un punto che l'agente può vedere, lo si tratta come già filtrato e lo si ruota — come ogni team attento ha trattato quell'auth-stub di Claude Code il giorno stesso del rilascio. Tenga la credenziale a braccio teso, in un sistema a cui l'agente può solo chiedere — mai leggere, mai detenere — e un agente completamente compromesso non potrà comunque esfiltrare ciò che non è mai stato alla sua portata. Può richiedere un'azione. Non può portarsi via la chiave. La distanza è la difesa; un vault in-process non la possiede a nessun prezzo.
È questa la linea che Clavitor traccia. L'intero settore ha appena dimostrato il principio — l'agente non dovrebbe vedere le chiavi. Noi semplicemente non riteniamo che Lei debba ridimostrarlo dentro ogni harness che esegue, e non riteniamo che la cosa che detiene le sue chiavi debba essere la stessa che un attaccante ha appena compromesso.
Riconosciamo il merito ai team dei harness: segreti fissati dall'amministratore, relay crittografati, impostazioni predefinite fail-closed sono ingegneria vera e buona. Ma una correzione-settimana per una fuga che continua a ripresentarsi non è un'architettura — è un sintomo. L'architettura è che le chiavi non siano lì per poter fuoriuscire.
Quando tre concorrenti rattoppano la stessa ferita nella stessa settimana, la ferita è il design. L'agente non dovrebbe vedere le sue chiavi — quindi smetta di tenerle dove lui può.
Clavitor (@clavitorai) è il vault per credenziali costruito per gli agenti di IA, e contro di essi. clavitor.ai
Fonti
[1] Claude Code v2.1.183 — "Fixed MCP servers requiring authentication exposing auth-stub tools to the model in headless/SDK mode" — https://github.com/anthropics/claude-code/releases/tag/v2.1.183
[2] Hermes Agent v0.17.0 — Managed Scope (admin-pinned secrets), secret redaction, exfil-config blocking — https://github.com/NousResearch/hermes-agent/releases
[3] OpenAI Codex v0.141.0 — encrypted Noise relay channels, auth-mode plugin routing — https://github.com/openai/codex/releases