Il tuo client API è un vault di credenziali: controllalo

Uno sviluppatore apre un client HTTP sul suo Mac. Niente altro. Nessun clic, nessuna finestra di consenso, nessuna casella «abilita funzionalità AI». Il giorno dopo, il suo coding agent non riesce ad autenticarsi su un server MCP remoto che non ha mai configurato, instrada le chiamate API attraverso skill mai installate e porta con sé un hook di avvio crittograficamente attendibile che non ha mai approvato. Non è un'ipotesi: è quello che mostrano le prove in un bug report recente e documentatissimo sull'app desktop di Postman, che installava in automatico plugin in Codex e Claude Code, scriveva nelle configurazioni globali degli agent e tentava di marcare come attendibile il proprio hook di sessione. Se ti interessa la sicurezza dei client API, questo è l'incidente che dovrebbe cambiare il modo in cui consideri ogni tool desktop per sviluppatori sulla tua macchina.

Cosa ha fatto davvero l'app desktop di Postman

Lasciamo da parte l'indignazione e guardiamo le prove, perché il reporter ha fatto il lavoro che la maggior parte di noi non fa mai. Il file di log di Postman ha registrato un evento auto-existing-upgrade: su un'installazione desktop già esistente e con l'accesso effettuato, uno script è stato eseguito e ha segnalato claude-code:installed,codex:installed. Nessuna richiesta all'utente. La configurazione globale di Codex dell'utente ha guadagnato un nuovo marketplace che punta a un repository git di Postman, un plugin abilitato e un record di fiducia per l'hook. Le impostazioni di Claude Code hanno guadagnato un plugin abilitato e record di installazione con timestamp nella stessa finestra temporale. Un binario della CLI di Postman è comparso in ~/.local/bin. E una connessione MCP remota era puntata ai server di Postman, che poi ha fallito l'autenticazione e ha inondato di errori: è l'unico motivo per cui l'utente se n'è accorto.

Due dettagli meritano di essere letti due volte. Primo, l'hook di avvio di sessione installato dice all'agent che, prima di rispondere a qualsiasi attività non banale di ingegneria delle API (progettare, testare, mockare, documentare, rilasciare), dovrebbe caricare la skill di Postman. Non è un'integrazione su richiesta: è un'applicazione che riscrive il comportamento predefinito di un'altra applicazione di un altro vendor. Secondo, il codice sorgente dell'installer include una parte che recupera esplicitamente l'hash dell'hook e lo inserisce nello stato degli hook attendibili dell'agent. Il meccanismo di fiducia esiste perché l'utente approvi gli hook. Far approvare all'installer il proprio hook equivale, nel software, a firmare da soli il proprio permesso.

Il reporter è stato prudente: nota esplicitamente che il solo record di fiducia non prova chi l'abbia creato e non avanza accuse di esfiltrazione. Questa moderazione rende il report più credibile, non meno. Quello che dimostra basta: modifiche silenziose a strumenti non correlati, un'istruzione comportamentale ampia iniettata nell'avvio della sessione di un agent e un tentativo di aggirare un controllo di consenso dell'utente. In qualsiasi revisione di sicurezza che ho condotto, una combinazione del genere porta a rimuovere il prodotto dalla flotta in attesa di indagini.

Perché il tuo client API è un vault di credenziali

Ecco la parte che i team sottovalutano sistematicamente. Un client API non è un editor di testo con un pulsante di invio. È il posto dove vivono i tuoi bearer token, i cookie di sessione, i certificati client mTLS, i client secret OAuth e gli header di richiesta firmati. Vi vengono incollate variabili d'ambiente con URL di database e chiavi di terze parti. Se usi una sintassi di template come {{api_secret}}, il valore risolto passa attraverso l'app a ogni richiesta e, a seconda di come il vendor ha progettato la telemetria, potenzialmente anche attraverso la sua pipeline di logging. Un professionista che indagava sulla conformità HIPAA ha riportato di aver trovato esattamente questo: valori segreti risolti nel traffico di log in uscita, con l'app che si degradava quando quell'endpoint veniva bloccato. Non posso verificare indipendentemente ogni dettaglio, ma corrisponde al pattern architetturale che ho visto in altri tool desktop «utili»: logging completo delle richieste spedito come funzionalità.

Ora aggiungi il punto di vista degli agent. Quando un tool installa un plugin nel tuo coding agent e registra un hook di sessione, inserisce le proprie istruzioni nel contesto di un processo che può leggere la tua codebase, eseguire comandi shell e possedere un proprio insieme di credenziali. Il raggio d'impatto non è più «le mie collection API possono trapelare», ma «ogni segreto raggiungibile dall'ambiente del mio agent dista un prompt sbagliato o una skill compromessa dall'endpoint sbagliato». Ne abbiamo già scritto: come i tool CLI che installano daemon in background ampliano silenziosamente la propria superficie d'attacco; questo è lo stesso schema con un payload più furbo. Un daemon che vedi in ps è quasi educato, rispetto a un hook di istruzioni che vive nel trust store di un altro vendor.

Se affronti onestamente il modello di minaccia, la conclusione è scomoda: un client API desktop si trova all'intersezione tra segreti, accesso di rete e, sempre più, piani di controllo degli agent. Merita lo stesso scrutinio che daresti a un password manager o a un runner CI. Quasi nessuno glielo riserva. È il varco che questo incidente sfrutta, ed è il motivo per cui la risposta deve essere procedurale, non solo emotiva.

Perché le opt-out dei vendor e gli interruttori nelle impostazioni non bastano

Il primo istinto dopo un incidente del genere è cercare nelle preferenze dell'app un interruttore per la telemetria, disattivarlo e voltare pagina. Ho visto interi team farlo e chiamarlo remediation. È teatro, per tre motivi.

• Il consenso può dipendere dalla versione. L'installazione di Postman è stata attivata da un feature flag su un account esistente con accesso effettuato. L'interruttore che esiste oggi non ti dice quali flag verranno rilasciati domani, e con gli aggiornamenti automatici il domani arriva senza chiedere.
• Gli interruttori regolano ciò che è documentato, non ciò che è possibile. Un'impostazione di privacy controlla i percorsi di codice che il vendor ha scelto di esporre. L'installer dei plugin non era una preferenza documentata: era un percorso di aggiornamento scriptato. Non puoi disattivare un interruttore che non vedi.
• Le decisioni di fiducia vengono prese fuori dall'app. Il tentativo di approvare l'hook è avvenuto nella configurazione di Codex, non di Postman. Anche un pannello impostazioni perfettamente corretto nell'app di origine non lo avrebbe fatto emergere.

Il fallimento più profondo è strutturale: le opt-out scaricano l'onere della vigilanza sulla parte con meno informazioni. Il vendor sa cosa può fare l'updater; tu no. Il vendor sa a quali endpoint l'app telefona a casa; tu stai indovinando. Qualsiasi controllo che richiede alla parte meno informata di superare continuamente nella ricerca la parte più informata finirà prima o poi per fallire. È lo stesso motivo per cui i problemi di fiducia nei marketplace dei plugin per IDE continuano a colpire le persone: il confine di sicurezza che pensi di gestire non è quello che viene attraversato.

La fiducia nel vendor non è priva di valore, ma non può essere il controllo. È un fattore nella decisione su cosa installare, non un meccanismo per mantenere onesto il software installato. Una volta interiorizzato questo, la strategia di audit si scrive da sola: verificare il comportamento dall'esterno, in modo continuo, con strumenti che il vendor non controlla.

Perché anche gli audit di sicurezza una tantum non bastano

Il secondo tentativo fallito è più rispettabile: l'audit puntuale. Il team di sicurezza esamina il tool, controlla le chiamate di rete, legge la privacy policy, emette un'approvazione, archivia il report. Fatto, finché non parte l'auto-updater. I tool desktop per sviluppatori oggi vengono rilasciati con cadenza settimanale o persino giornaliera, e i feature flag fanno sì che due utenti con lo stesso numero di versione possano eseguire codice sostanzialmente diverso. Il comportamento di questo incidente era vincolato a un flag lato server e a una condizione «utente esistente», il che significa che un'installazione pulita revisionata dal tuo team di sicurezza potrebbe apparire impeccabile mentre i tuoi utenti di lunga data ricevono il plugin.

Sono caduto proprio in questo buco. Anni fa ho approvato un client di sincronizzazione dopo una revisione accurata: traffico pulito, permessi sensati, nessun meccanismo di persistenza. Sei mesi dopo un aggiornamento ha aggiunto un LaunchAgent e un socket listener. Lo abbiamo scoperto solo perché un laptop con una VPN instabile continuava a mostrare strani tentativi di riconnessione in un log del firewall. Nessuno aveva rivisto nulla, perché il processo di nessuno lo richiedeva. L'approvazione era un'istantanea; il software era un film.

Quindi entrambi i rimedi economici falliscono: fidarsi delle impostazioni del vendor non funziona perché il comportamento interessante non sta nelle impostazioni, e gli audit una tantum non funzionano perché il comportamento interessante viene rilasciato dopo l'audit. Ciò che funziona è trattare lo stato della tua macchina come fonte di verità e osservarne i cambiamenti. È meno affascinante di una revisione d'acquisto, ma cattura la realtà invece delle intenzioni.

Come auditare davvero i tool desktop per sviluppatori

L'approccio pratico ha tre gambe: fotografare lo stato che conta, osservare il traffico di rete e contenere ciò che non puoi verificare fino in fondo. Nessuna di queste richiede strumenti enterprise. Serve disciplina e circa un'ora di configurazione.

Rilevare installazioni silenziose di plugin con snapshot delle configurazioni

Ogni coding agent e ogni tool per sviluppatori sulla tua macchina ha un piccolo insieme di file che ne definiscono il comportamento: ~/.codex/config.toml, ~/.claude/settings.json e la directory dei plugin, le configurazioni MCP, i file rc della shell, ~/Library/LaunchAgents, ~/.local/bin. Questi file sono il confine del consenso. Qualsiasi cosa li modifichi senza chiedere è esattamente ciò che vuoi intercettare. Quindi calcolane l'hash ogni giorno e confrontali:

#!/usr/bin/env bash
# snapshot-agent-configs.sh — hash every file your agents and shells read,
# then diff against yesterday. Run from cron or launchd.
set -euo pipefail
SNAP_DIR="$HOME/.config-audit"
mkdir -p "$SNAP_DIR"
TODAY="$SNAP_DIR/$(date +%F).txt"
find \
"$HOME/.codex" \
"$HOME/.claude" \
"$HOME/.config" \
"$HOME/.local/bin" \
"$HOME/Library/LaunchAgents" \
-type f 2>/dev/null \
| sort \
| xargs shasum -a 256 > "$TODAY"
PREV=$(ls -t "$SNAP_DIR"/*.txt 2>/dev/null | sed -n '2p' || true)
if [ -n "${PREV:-}" ]; then
if ! diff -u "$PREV" "$TODAY" > "$SNAP_DIR/latest.diff"; then
echo "config drift detected — see $SNAP_DIR/latest.diff" \
| mail -s "agent config drift" you@example.com || \
cat "$SNAP_DIR/latest.diff"
fi
fi

È rudimentale, e va bene così. Se questo fosse stato in esecuzione sulla macchina del reporter, la modifica di config.toml di Codex, i nuovi record dei plugin di Claude e il binario della CLI in ~/.local/bin sarebbero apparsi tutti in un unico diff la mattina seguente. Il rapporto segnale/rumore è eccellente perché queste directory sono altrimenti silenziose: le tue modifiche sono le uniche legittime, e sai quando le hai fatte. Abbinalo all'output di launchctl list | grep -v com.apple nello stesso snapshot e intercetterai anche i meccanismi di persistenza il giorno in cui compaiono.

Controlla il traffico in uscita, non solo i file

L'integrità dei file ti dice cosa è cambiato su disco; non ti dice cosa è uscito dalla rete. Per il traffico in uscita serve visibilità per applicazione. Su macOS, Little Snitch o il firewall open source LuLu ti avviseranno delle nuove connessioni in uscita per processo: la prima volta che l'updater di Postman o un nuovo binario della CLI cercherà un host sconosciuto, riceverai una richiesta invece di un fatto compiuto. Su Linux, opensnitch fa lo stesso lavoro. Se vuoi solo un controllo manuale di cosa sta facendo un'app loquace in questo momento:

# Every established outbound connection, grouped by process
sudo lsof -iTCP -sTCP:ESTABLISHED -P -n | awk '{print $1, $9}' | sort | uniq -c | sort -rn
# Watch one vendor's traffic live (find the process name first)
sudo tcpdump -i any -n host mcp.postman.com

Due cose da cercare: destinazioni che non hanno nulla a che fare con la funzione dichiarata del tool, e connessioni che persistono quando l'app è inattiva. Un client HTTP dovrebbe restare silenzioso quando non stai cliccando su invia. Gli endpoint di telemetria di per sé non sono automaticamente condannabili, ma, come mostra la storia dell'indagine HIPAA, conta il payload. Se il tuo client risolve {{secrets}} lato client e registra il dettaglio completo delle richieste lato server, i «dati di utilizzo anonimi» non sono anonimi. L'unico modo per saperlo è catturare e leggere, idealmente durante una sessione in cui hai caricato deliberatamente un canary token (una credenziale finta e unica) in una variabile d'ambiente, e hai osservato se transita dove non dovrebbe. I canary token trasformano «pensiamo che potrebbero» in «sappiamo che l'hanno fatto».

Contieni ciò di cui non puoi fidarti fino in fondo

L'ultima gamba accetta che non catturerai tutto. Quindi limita il raggio d'azione. Esegui i tool che maneggiano molte credenziali in un account utente dedicato del sistema operativo o in una VM leggera, così la loro portata sul filesystem si ferma al bordo della sandbox: macOS e Linux rendono economico un secondo utente, e strumenti come firejail su Linux possono negare interi alberi di directory per applicazione. Tieni i segreti di produzione reali fuori dai tool desktop: usa token a breve durata, service account con ambito limitato e firme delle richieste che scadono. Se un tool richiede una credenziale di produzione a lunga durata per funzionare, quella richiesta è già di per sé un risultato dell'audit. Abbiamo già sostenuto che il contenimento batte il monitoraggio quando il costo di un errore è alto: per gli agent e per i tool che li configurano, il contenimento è il livello che continua a funzionare il giorno in cui il monitoraggio ha un punto cieco.

Un playbook di rollback per gli incidenti sugli strumenti

Quando individui qualcosa, eliminare l'app colpevole è il primo di circa sei passaggi. La checklist di rimozione del reporter di Postman ha la forma giusta, e vale la pena interiorizzarla prima di averne bisogno:

1. Conserva prima le prove. Copia log, configurazioni e numeri di versione in un posto sicuro prima di disinstallare. Il main.log di Postman è stata la pistola fumante qui: gli script di disinstallazione amano cancellarlo.
2. Rimuovi l'app e i suoi helper. Il bundle dell'app, più tutto ciò che ha depositato in ~/.local/bin, Application Support e cache.
3. Ripulisci le configurazioni degli agent. Rimuovi le voci dei marketplace, i blocchi dei plugin abilitati, le definizioni dei server MCP e le directory dei plugin in cache da ogni host degli agent, non solo da quello ovvio.
4. Revoca i record di fiducia. Elimina le voci trusted_hash per gli hook che non hai approvato. Poi controlla gli altri hook nello stesso file: se uno è stato introdotto di nascosto, verifica il resto.
5. Verifica la persistenza. LaunchAgent, LaunchDaemon, elementi di login, voci cron, aggiunte ai file rc della shell.
6. Ruota ciò che ci è passato attraverso. Qualsiasi credenziale che ha vissuto negli ambienti o nelle collection del tool va considerata esposta. La rotazione è fastidiosa; la risposta a un incidente è peggio.
7. Verifica che la rimozione tenga. Lascia in esecuzione lo script di snapshot per alcune settimane. La reinstallazione con un flag diverso è uno schema noto.

Ciò che non compare in questa lista: aprire un ticket e aspettare. Fallo pure (segnalazioni pubbliche e ben documentate sono il modo in cui gli altri scoprono i problemi), ma la tua igiene non può dipendere dalla roadmap del vendor.

La lezione più ampia sulla sicurezza degli strumenti per sviluppatori

C'è la tentazione di fare di questa storia solo la traiettoria di un'azienda: un tool leggero e amato che ha raccolto centinaia di milioni di finanziamenti, ha assunto un piccolo esercito e ora deve giustificare una valutazione da miliardi con login, abbonamenti e l'AI in ogni cosa. È una narrazione soddisfacente e in gran parte vera, ma ci assolve troppo facilmente. La stessa struttura di incentivi ora sta sotto metà dei tool sulla tua macchina. Ogni vendor con una storia AI da raccontare vuole il suo plugin nel tuo agent, il suo server MCP nella tua configurazione, il suo hook nell'avvio della tua sessione. Alcuni chiederanno il permesso. Le prove dicono che almeno uno ha deciso che chiedere fosse facoltativo.

La risposta del mercato è già visibile, ed è istruttiva: i client API offline-first e nativi per git come Bruno, Kreya e Yaak stanno vivendo un momento favorevole proprio perché il loro modello di fiducia è leggibile. File nel tuo repo, richieste dalla tua macchina, nessun account richiesto. Quando il formato di archiviazione di un tool è una cartella di file di testo, l'audit si riduce a git diff. Non è nostalgia: è un'architettura di sicurezza. L'incidente della supply chain di LiteLLM ha insegnato la stessa lezione dal lato dei registri di pacchetti: gli artefatti che puoi ispezionare e fissare sono quelli che puoi difendere.

Un consenso che vive in un feature flag non è consenso. Se un tool può cambiare cosa fa senza cambiare il numero di versione, la tua approvazione del tool non significa nulla.

Quindi ecco la posizione che difenderò: smetti di valutare i tool desktop per le funzionalità e inizia a valutarli per la reversibilità. Posso vedere tutto ciò che scrive? Posso fare il diff della sua configurazione? Posso eseguirlo senza account, offline, dietro un firewall che registra? Posso rimuoverlo completamente, incluso ciò che ha toccato fuori dalla propria directory? I tool che superano queste domande tendono a essere noiosi, e il noioso è esattamente ciò che vuoi tra le tue credenziali e la rete. Quelli che non le superano, per quanto buono sia l'autocompletamento, appartengono a una sandbox o fuori dalla macchina. Il tuo client API è un vault di credenziali. Trattalo come tale, perché i vendor evidentemente già lo fanno, solo non nel modo che spereresti.