Proxy di credenziali
I Suoi agenti effettuano chiamate API.
Non dovrebbero mai detenere le chiavi.
Clavitor Proxy si posiziona tra i Suoi agenti IA e le API che questi chiamano. Le credenziali vengono iniettate a livello di rete: l'agente non vede, memorizza o registra mai il segreto effettivo. Un singolo binario. Una variabile d'ambiente. Zero modifiche al codice.
Il problema che ha già
Segreti nelle variabili d'ambiente
I Suoi agenti leggono OPENAI_API_KEY dall'ambiente. Tale chiave è visibile in /proc, nei dump di crash, nei log CI, in ogni strumento invocato dall'agente. Una singola riga di log compromessa e la chiave è pubblica.
Segreti nella memoria dell'agente
Anche se l'agente recupera la chiave in fase di esecuzione, la detiene in memoria per la durata del processo. Una skill compromessa, un prompt injection, un debug dump: la chiave è lì per essere prelevata.
Nessun audit di ciò che è stato utilizzato
Quando una chiave API viene condivisa come stringa, non vi è alcuna registrazione di quale agente l'abbia utilizzata, quando o per quale scopo. Se la chiave viene compromessa, la si ruota e si spera. Non esiste una traccia forense.
I problemi che speriamo non abbia
Chiavi API nel codice sorgente
Codificate in un file di configurazione, committate su git, clonate da ogni sviluppatore e runner CI del team. Un fork pubblico e sarà sul dashboard di scansione segreti di GitHub, o peggio, non lo sarà.
Credenziali in Slack
"Puoi inviarmi la chiave Stripe?" Incollata in un DM, ricercabile per sempre, esportata in ogni archivio di conformità. Slack non è una cassaforte. Né lo sono email, Google Docs o un post-it su un monitor.
File .env su ogni laptop
Dodici sviluppatori, dodici copie delle credenziali di produzione in file in chiaro che non vengono mai ruotate. Un laptop rubato, una fuga di ~/.bash_history, uno strumento di backup eccessivamente disponibile: e si ruotano tutte le chiavi dell'azienda alle 2 del mattino.
Rimuovere le credenziali dall'agente.
Il proxy si posiziona tra l'agente e l'API. L'agente scrive un riferimento — clavitor://OpenAI/key — dove dovrebbe andare il segreto. Il proxy lo risolve localmente, inietta la credenziale effettiva nella richiesta HTTPS e la inoltra. I log dell'agente mostrano il segnaposto. L'API riceve la chiave. Nulla nel mezzo la memorizza.
Nessuna variabile d'ambiente. Nessun segreto in memoria. Nessuna credenziale sulla riga di comando. L'agente non conosce la chiave, non può comprometterla, non può essere indotto a rivelarla.
$ export HTTPS_PROXY=http://127.0.0.1:1983
$ curl -H "Authorization: Bearer clavitor://OpenAI/key" \
https://api.openai.com/v1/chat/completions
# The proxy resolved the placeholder. The agent never saw sk-proj-abc123.
# Neither did the logs, the crash dump, or the conversation history.Funziona con qualsiasi agente che effettua chiamate HTTPS: Claude Code, Codex, OpenClaw, CrewAI, LangChain, script personalizzati. Imposti una variabile d'ambiente e le chiamate API dell'agente fluiscono attraverso il proxy. Nessun SDK, nessun plugin, nessuna modifica al codice.
Cosa succede sotto il cofano
Decritta localmente, per richiesta
Il proxy recupera la credenziale crittografata dalla cassaforte e la decritta sul dispositivo. Il testo in chiaro esiste nella memoria del processo per una richiesta HTTP, poi scompare. Nulla viene memorizzato nella cache. Nulla viene scritto su disco. Ogni richiesta viene decrittata fresca.
Mappa i campi alle intestazioni
Token Bearer, chiavi API, autenticazione Basic: il proxy mappa automaticamente le etichette dei campi della cassaforte alle intestazioni HTTP corrette. Oppure l'agente seleziona il campo esatto con un riferimento clavitor://. In entrambi i casi, la credenziale finisce nel posto giusto senza che l'agente la veda mai.
Ambiti, limiti di frequenza, audit
La cassaforte applica confini di ambito e limiti di frequenza. Un agente che accede a troppe credenziali distinte viene bloccato automaticamente. Ogni accesso viene registrato. Includa un ID agente nel segnaposto — clavitor://agentid@Entry/field — per audit trail per agente e limiti di frequenza tramite un proxy condiviso.
Distribuzione
Un singolo binario. Sidecar all'agente. Nessuna modifica all'infrastruttura di rete.
Host con singolo agente
Scarichi il binario, esegua clavitor-proxy init con il token di registrazione, imposti HTTPS_PROXY sull'agente. Fatto. Per impostazione predefinita, il proxy si lega a 127.0.0.1:1983 (sidecar per un agente); imposti CLAVITOR_PROXY_LISTEN per legarsi altrove quando un proxy serve più agenti su una rete privata.
Host con più agenti
Ogni agente ottiene la propria copia del binario con il proprio file di configurazione sidecar. Ogni copia ha il proprio ambito, i propri limiti di frequenza, il proprio audit trail. L'agente A non può vedere le credenziali dell'agente B. Isolamento per progettazione.
Ogni proxy di credenziali che viene eseguito nel cloud — il Suo o quello di qualcun altro — è un bersaglio. Comprometta il proxy, ottenga le credenziali di ogni cliente. Questo non è un rischio teorico. È il modello di business di ogni servizio "credential-proxy-as-a-service".
Il proxy di Clavitor viene eseguito sulla Sua infrastruttura. Decritta localmente. La credenziale esiste nella memoria del processo per la durata di una richiesta. Non esiste un servizio cloud che detiene le Sue chiavi in chiaro. Non esiste un endpoint API che serve i Suoi segreti. Non c'è nulla da compromettere.
I Suoi agenti stanno già effettuando chiamate API.
Mantenga ciascuno nella propria corsia.
La Sua cassaforte, i Suoi ambiti, il Suo audit trail. Il proxy aggiunge un punto di applicazione a livello di rete con zero modifiche al codice dell'agente.