jitpass/jitTrova i segreti in chiaro sul tuo Mac e spostali dietro Touch ID, iniettandoli al momento giusto senza rompere gli strumenti che li leggono. Gratuito e local-first.
Credenziali just-in-time per la tua macchina di sviluppo.
Documentazione · Avvio rapido · Strumenti supportati · Riferimento comandi · Sicurezza
Stato: solo macOS (Apple Silicon), e ancora in fase di sviluppo.
I tuoi segreti vivono in chiaro su tutta la macchina: file .env,
~/.aws/credentials, export in ~/.zshrc, token .npmrc, configurazioni MCP.
Qualunque cosa giri come te può leggerli. Un brutto curl | sh, un npm install losco, o uno degli agenti AI che ora girano nel tuo editor con tutti i tuoi permessi.
jit sposta ogni segreto in un vault locale crittografato protetto da Touch ID, e riscrive i file così i tuoi strumenti continuano a funzionare. Su disco ora c'è un'esca. Il valore reale appare solo, in memoria, per il processo specifico che lo ha richiesto, dopo un prompt biometrico. Il risultato: sblocchi una volta, jit chiede prima di consegnare una credenziale a uno strumento (o a un agente), e c'è un'esca su disco per il resto del tempo.
| avviato da Code | avviato da claude |
|---|---|
 |  |
Cosa non fa: non rende sicuro un account già compromesso, e non protegge un segreto una volta che è nella memoria del processo che lo ha richiesto. I confini sono dichiarati su una pagina, subito: i limiti deliberati.
Nessuna estensione del kernel, nessun driver del filesystem, nessun FUSE. Tre meccanismi, scelti in base a cosa lo strumento può fare:
execve. L'immagine stessa di jit viene sostituita dal tuo comando, quindi il valore vive in quel singolo processo e jit sparisce dalla memoria.credential_process di AWS, helper di credenziali per docker e git, plugin exec di kubectl, helper di credenziali di Terraform. Lo strumento chiede, jit risponde, nessun file coinvolto.Il mount è una FIFO POSIX, creata con mkfifo(2) in modalità 0600. Un programma che chiama open(".env") si blocca nel kernel finché uno scrittore non si connette. Il servizio in background è quello scrittore: apre il percorso O_WRONLY, che rilascia il lettore, scrive i byte decrittati dalla memoria nel buffer della pipe del kernel, chiude, e torna a open(2) per il prossimo lettore. Nulla tocca il disco. Ciò che viene scritto è deciso per ogni lettura: esche per un lettore ambientale, valori reali solo dentro un'esecuzione che hai autorizzato.
L'identità del chiamante spiega e registra, non decide mai. I nomi dei processi sono falsificabili, e un lettore FIFO che si chiude rapidamente può eludere del tutto l'identificazione. L'umano che risponde al prompt è il gate; il nome del processo ti dice solo a cosa rispondere. Dettagli completi in come funziona e mount live.
brew install jitpass/tap/jitpass
Questa è la via raccomandata, e per uno strumento di sicurezza il motivo conta. Le release sono firmate con un Apple Developer ID e notarizzate da Apple. Homebrew mette in quarantena ciò che scarica, quindi Gatekeeper verifica il binario contro il suo ticket di notarizzazione prima che gli sia mai permesso di girare. Per verificarlo tu stesso invece di crederci sulla parola, esegui jit doctor: la sua riga jit riporta signed CZC6BH93GJ, lo stesso controllo che jit upgrade esegue prima di installare qualsiasi cosa.
curl -sL https://dl.jitpass.com/jitpass/jit/releases/latest/download/jitpass_darwin_arm64.tar.gz | tar -xz jit
shasum -a 256 jit # confronta con checksums.txt sulla pagina della release
codesign -dv --verify --verbose=2 ./jit # atteso: Developer ID, TeamIdentifier=CZC6BH93GJ
sudo mv jit /usr/local/bin/
Questo è qui per chi non ha Homebrew, ed è genuinamente la via più debole: curl non imposta il bit di quarantena, quindi Gatekeeper non consulta mai il ticket di notarizzazione, e lo stesso vale per go install. Il binario è comunque firmato e comunque notarizzato, quindi le due righe sopra ti permettono di verificare entrambe le cose prima di eseguirlo, ma devi effettivamente eseguirle. Se hai Homebrew, usa Homebrew.
Solo Apple Silicon. Su un Mac Intel, compila dal sorgente con
go install github.com/jitpass/jit/cmd/jit@latest.
Scegli una sola via. Se hai installato dal tarball in precedenza e stai passando a Homebrew, rimuovi la vecchia copia dopo il brew install (sudo rm /usr/local/bin/jit); altrimenti due jit stanno su PATH aggiornandosi separatamente, e jit doctor lo segnalerà.
Aggiornamento: brew upgrade jitpass, oppure jit upgrade: un auto-aggiornamento verificato (firma Developer-ID e checksum entrambi controllati prima dello scambio, riavvia il servizio). In entrambi i casi il tuo vault resta intatto.
Homebrew installa il completamento shell con il binario, quindi jit <TAB> completa sottocomandi, flag, percorsi del vault e nomi di strumenti avvolgibili out of the box. Se installato dal tarball o dal sorgente, aggiungilo tu:
echo 'source <(jit completion zsh)' >> ~/.zshrc && exec zsh
In ogni caso, jit doctor ti dice se il completamento non raggiunge la tua shell.
jit scan # sola lettura. non modifica alcun file che scansiona, non stampa valori reali.
jit vault init # crea il vault (chiave master nel tuo portachiavi di login)
jit migrate --dry-run # anteprima dell'intero piano di correzione a livello macchina
jit migrate # applicalo: mostra il piano, chiede [y/N], un Touch ID
jit migrate ~/code/myapp # oppure correggi solo un progetto
jit run -- npm run dev # esegui il tuo strumento; valori reali iniettati solo in quel processo
jit scan senza percorso spazza tutta la tua home directory, quindi dagli un momento su una grande. Per andare dritto in un punto, puntalo su un percorso: jit scan ~/.aws.
Nel quotidiano è per lo più jit run -- <cmd>. Per CLI che portano il proprio token di login (gh, glab, stripe e altri) fai jit wrap gh una volta e poi continua a digitare gh come sempre per sempre.
Non sei sicuro se qualcosa richiede jit wrap, jit migrate o nulla? Non devi saperlo. jit scan divide tutto ciò che trova in ciò che jit proteggerà (un comando - inclusi i wrap) e ciò che solo tu puoi correggere, e un semplice jit migrate esegue l'intero piano:
$ jit scan
I TUOI SEGRETI: 7 — 0 protetti da jit (0%)
▱▱▱▱▱▱▱▱▱▱ al 100%: un comando +71% · 2 segreti che solo tu puoi correggere +29%
jit proteggerà questi — 5 segreti in 4 file, 0% → 71%
→ jit migrate
~/.zshrc STRIPE_API_KEY, DB_PASSWORD
~/.config/gh/hosts.yml token GitHub CLI · avvolge gh
...
solo tu puoi proteggere questi — 2 segreti, 71% → 100%
[ruota, poi elimina ogni copia]
! Una password di database di produzione in 2 file
→ ruotala ora, poi elimina ogni copia
(jit scan --full dà ancora l'inventario classico per categoria con le severità, inclusa la sezione Token CLI avvolgibili.)
Migra la credenziale una volta, poi continua a usare lo strumento come hai sempre fatto.
# AWS (e Terraform, e ogni SDK AWS)
jit migrate ~/.aws/credentials # le chiavi si spostano nel vault; nessun file in chiaro rimasto
aws s3 ls # si risolve dal vault su richiesta. nessun prefisso, nessun flag.
terraform apply # stesse credenziali, stesso comando
# Credenziali predefinite dell'applicazione GCP (una credenziale a livello macchina)
jit migrate ~/.config/gcloud/application_default_credentials.json
terraform apply # il provider google legge ADC; funziona dopo un prompt Touch ID
# Docker / docker-compose
jit migrate ~/.docker/config.json # i login dei registry si spostano nel vault
jit run -- docker compose up # jit li inietta per questa esecuzione
docker login ghcr.io # funziona ancora; l'helper salva nel vault
# Export di shell che stavano in ~/.zshrc
jit migrate ~/.zshrc # lascia un hook di una riga; le nuove shell hanno solo le variabili
./deploy.sh # gli script che leggono quelle variabili funzionano invariati
# Token che una volta digitavi al prompt, ora nella cronologia della tua shell
jit migrate ~/.zsh_history # ognuno si sposta nel vault; i tuoi comandi restano, i segreti no
jit guard history # e impedisci che il prossimo venga registrato del tutto (zsh)
# (un semplice `jit migrate` offre anche questo, nel piano che ti chiede di confermare)
# Una CLI che porta il proprio token (gh, stripe, glab)
jit wrap gh # una volta
gh pr list # token iniettato per chiamata, per sempre
La prima volta che ogni strumento cerca una credenziale reale, jit chiede una volta e ricorda la tua risposta finché il vault non si blocca. Vedi Due momenti Touch ID per come questo si sovrappone allo sblocco del vault, cosa fa --trust, e come disattivare i prompt per strumento.
Perché alcuni strumenti non richiedono configurazione mentre altri richiedono un jit run? Una regola: lo strumento può chiedere a jit il segreto da solo? AWS (tramite credential_process), la tua shell al login, e i login dei registry docker (tramite un helper di credenziali) possono tutti, quindi non digiti nulla in più. Gli strumenti che leggono solo un file a runtime (docker compose, SDK semplici) non possono chiedere, quindi jit run consegna loro il valore.
I file di credenziali globali della macchina (GCP ADC, sops, npm, netrc) funzionano allo stesso modo quotidiano: esegui il tuo strumento e approva il prompt per processo. Aggiungi jit run --with <name> solo quando lo vuoi esplicito: per script e CI dove non c'è un prompt a cui rispondere, o quando vuoi un gate rigido che la configurazione di un progetto non può mai raggiungere. Strumenti supportati elenca esattamente cosa digitare per ogni strumento, e come ciascuno viene consegnato.
jit chiede la tua impronta in due momenti diversi, facendo due lavori diversi:
jit dopo che si è bloccato, un Touch ID apre il vault per l'intera sessione (5 minuti di attività, poi si riblocca; e mai più di 8 ore, per quanto tu sia occupato). Sblocchi una volta, non una volta per comando.jit chiede prima di consegnarla e nomina chi sta chiedendo. Questo è ciò che impedisce a un programma che non hai eseguito di usare silenziosamente le tue chiavi mentre il vault è aperto.$ aws s3 ls
Touch ID -> sblocca il tuo vault # gate 1: apre il vault per 5 min
Touch ID -> aws vuole la tua credenziale aws # gate 2: questo strumento, questa credenziale
...i tuoi bucket...
$ aws s3 cp ./file s3://bucket/ # stesso strumento, stessa sessione: nessun prompt
$ terraform apply
Touch ID -> terraform vuole la tua credenziale aws # uno strumento diverso: chiede per conto suo
Il gate 2 è ciò che impedisce a un vault sbloccato di essere un tutti-contro-tutti: anche dopo che hai usato aws tu stesso, un losco npm install che cerca quelle stesse chiavi innesca comunque un prompt che lo nomina, così puoi dire di no.
Non vuoi il secondo gate? Spegnilo; il blocco del vault resta (spegnerlo richiede a sua volta un Touch ID, poiché riapre la finestra che chiude):
jit service consent off # gli strumenti si risolvono silenziosamente mentre il vault è sbloccato
jit service consent on # chiedi di nuovo per strumento (il default)
Devi avviare qualcosa che richiede più credenziali in una volta? jit run --trust -- terraform apply approva gli strumenti dell'intera esecuzione con un solo gesto. Dettagli completi:
consenso per processo.
jit grantEntrambi i gate presuppongono che ci sia un umano a rispondere. Un agente AI che lavora di notte, una build lunga, un job programmato: lo schermo si blocca, la sessione cade, e l'esecuzione si ferma su un prompt che nessuno vedrà. Una grant di processo sposta la tua decisione prima invece di rimuoverla - un Touch ID, dato mentre sei ancora lì, che nomina esattamente ciò che stai firmando:
$ jit grant --process claude --profile jamf --for 8h
Touch ID -> lascia che claude sotto iTerm2 usi 2 segreti (jamf) senza supervisione per 8h
✓ concessa g-7f3a2c81 claude -> jamf fino alle 17:42
└ copre claude sotto iTerm2: 1 in esecuzione ora, qualsiasi avviato prima delle 17:42
Per le prossime 8 ore, ogni claude sotto il terminale in cui hai digitato quello (e ciò che lancia) ottiene quei segreti senza prompt - attraverso il blocco schermo e tutto, incluse le sessioni che avvii dopo: una nuova scheda, il prossimo claude, uno script che parte alle 3 di notte. È il tuo terminale a essere nominato, non un nome a essere fidato: un programma che si chiama claude da qualche altra parte sulla macchina non discende da quell'albero e non eredita nulla. La grant termina alla sua scadenza, quando chiudi quel terminale, o nel momento in cui digiti jit grant revoke (che non richiede impronta - togliere l'accesso è sempre gratuito). Vuoi un singolo processo esatto, che sparisce quando esce? --pid. Ogni concessione finisce nel registro di controllo come evento proprio, così la mattina dopo puoi leggere esattamente cosa il tuo agente ha toccato mentre dormivi. Dettagli completi:
grant di processo.
L'agente nel tuo editor gira come te, con i tuoi permessi, e legge file per te tutto il giorno. Questo è il suo scopo, ed è anche il motivo per cui un .env in chiaro nel tuo repo è ora un rischio molto diverso da due anni fa. jit tratta gli agenti come cittadini di prima classe, su quattro fronti:
jit migrate ~/.claude.json # configurazioni server MCP: le chiavi si spostano nel vault,
# ogni server ora si avvia tramite `jit run`
jit wrap claude # le CLI AI stesse: claude, codex, gemini,
# cursor-agent, copilot, cline, opencode, kiro-cli
jit grant --process claude --profile myapp --for 8h
# lascialo lavorare di notte senza un prompt a cui nessuno risponde
jit audit --parent claude # rileggi esattamente cosa ha toccato mentre dormivi
claude, ciascuno nominato. Un agente che legge silenziosamente ~/.aws/credentials è un prompt, non un successo silenzioso.jit run. Una configurazione MCP migrata contiene percorsi del vault, non chiavi, quindi il file di configurazione stesso è sicuro da tenere su disco e sicuro da dare all'agente che lo legge..env nel tuo repo e lo legge a freddo ottiene valori segnaposto, e la lettura viene registrata.jit audit --parent claude mostra ogni segreto che un agente ha usato, ogni prompt che ha innescato, e ogni rifiuto.Altro in strumenti MCP / AI e consenso per processo.
Ogni comando jit e ogni sblocco finisce in un log durevole che rileggi con jit audit, dal più recente, una riga key=value per evento, così si filtra come un vero log di servizio. Gli argomenti dei comandi sono mascherati, quindi il log prova che un comando è stato eseguito senza mai memorizzare il segreto che portava.
$ jit audit --since 1h
time=2026-07-24 10:15:04 level=info kind=cmd status=ok dur=312ms cmd="jit migrate ~/.aws/credentials" user=meni parent=claude
time=2026-07-24 10:16:22 level=info kind=use op="read a secret" cmd="aws s3 ls" parent=claude secrets=aws/default
time=2026-07-24 10:31:09 level=warn kind=unlock status=denied method=touchid-or-passcode cmd="node postinstall.js" parent=npm secrets=aws/default
La riga centrale è la storia che jit esiste per raccontare: aws/default è stato letto da aws s3 ls, avviato da claude. L'ultima è un prompt che hai rifiutato: un node postinstall.js sotto npm che cercava quelle stesse chiavi, respinto. jit registra anche ciò che il servizio ha respinto al suo socket (un processo che il kernel dice non essere tuo, che sonda l'agente) come kind=error.
Restringi con i flag invece di grep: --kind, --status ok|failed|denied, --since/--until (un'età come 2h/3d o una data), --parent claude, --secret aws, --user, --grep <regexp>. Aggiungi --follow (-f) per trasmettere nuovi eventi in diretta come tail -f, o --format json per un dump analizzabile dalla macchina. Entrambe le metà sono file durevoli accanto al vault, quindi risponde per la scorsa settimana con la stessa prontezza dell'ultima ora.
File .env, export di shell, AWS e Terraform, kubeconfig, login dei registry Docker, GCP ADC, token .npmrc / .netrc, configurazioni server MCP, file di token nudi, credenziali registrate nella cronologia della tua shell, CLI avvolgibili (gh, stripe, vercel, …), e CLI SSO che coniano credenziali al login (clisso). In ogni caso il file continua a funzionare e il valore reale arriva dal vault su richiesta.
Il catalogo completo, raggruppato per esattamente cosa digitare per ogni strumento, è
Strumenti supportati: tiene traccia del codice man mano che gli strumenti vengono aggiunti o rimossi. Qualsiasi cosa non elencata può comunque essere avvolta con
jit wrap add.
Tieni già i tuoi segreti in 1Password? Con la sua CLI installata,
jit migrate collega invece di copiare: un valore che vive già in 1Password viene messo nel vault come suo riferimento op://, così 1Password resta il sistema di registrazione e jit consegna il valore just-in-time attraverso ogni meccanismo sopra (jit vault link fa lo stesso per un singolo segreto a mano).
jit non distrugge mai una credenziale. Migrate sposta il valore nel vault e lascia un hook funzionante dove stava (un .env esca, una riga eval "$(jit export)" nella tua configurazione di shell, credential_process = jit … in ~/.aws/config, o uno shim PATH), così i tuoi strumenti continuano a risolverlo su richiesta. La credenziale esiste ancora, solo crittografata invece di stare in chiaro.
E ogni modifica è reversibile. Prima di toccare un file, jit ne fa un backup crittografato nel vault, così jit migrate undo lo rimette a posto byte per byte:
jit migrate ~/code/myapp # applicata la correzione, un Touch ID
# hai cambiato idea, o qualcosa si è rotto?
jit migrate undo ~/code/myapp # ogni file toccato ripristinato, byte per byte
La documentazione vive sotto docs/, organizzata per attività:
git commit -s), nessun CLAPolyForm Perimeter License 1.0.0 - gratuita solo per uso personale e interno aziendale.