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, config MCP. Qualunque
cosa giri con i tuoi permessi può leggerli. Un curl | sh sospetto, 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 tutto il resto
del tempo.
| avviato da Code | avviato da claude |
|---|---|
 |  |
brew install jitpass/tap/jitpass
Oppure senza Homebrew:
curl -sL https://dl.jitpass.com/jitpass/jit/releases/latest/download/jitpass_darwin_arm64.tar.gz | tar -xz jit
sudo mv jit /usr/local/bin/
Solo Apple Silicon — su un Mac Intel, compila dal sorgente con
go install github.com/jitpass/jit/cmd/jit@latest.
Scegli una sola strada. Se hai installato dal tarball prima e stai passando a
Homebrew, rimuovi la vecchia copia dopo la brew install (sudo rm /usr/local/bin/jit); altrimenti due jit finiscono entrambi su PATH e si aggiornano
separatamente, e jit doctor lo segnalerà.
Le release sono firmate con un Developer ID e notarizzate da Apple, quindi entrambe le
strade funzionano senza prompt di Gatekeeper: Homebrew mette in quarantena i suoi download e
Gatekeeper li verifica contro il ticket di notarizzazione, mentre curl (e go install) non impostano alcun flag di quarantena. Per verificare cosa hai ricevuto invece di
credere sulla parola, esegui jit doctor — la sua riga jit riporta
signed CZC6BH93GJ, usando lo stesso controllo che jit upgrade esegue prima di
installare qualsiasi cosa.
Aggiornamento: brew upgrade jitpass, oppure jit upgrade — un
self-update verificato (firma Developer-ID e checksum entrambi controllati prima della
sostituzione, riavvia il servizio). In entrambi i casi il tuo vault non viene toccato.
Homebrew installa il completamento shell insieme al binario, quindi jit <TAB> completa
sottocomandi, flag, percorsi del vault e nomi di strumenti avvolgibili subito.
Se installato da tarball o da sorgente, aggiungilo da solo:
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 nessun 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 su tutta la 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; i valori reali vengono iniettati solo in quel processo
jit scan senza percorso scansiona l'intera home directory, quindi concedigli un attimo su una
grande. Per andare dritti in un punto, puntalo su un percorso: jit scan ~/.aws.
Nel quotidiano è perlopiù jit run -- <cmd>. Per le 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 al solito per sempre.
Non sei sicuro se qualcosa richiede jit wrap, jit migrate o niente? Non
devi saperlo. jit scan divide tutto ciò che trova in ciò che jit
proteggerà (un solo comando — i wrap inclusi) e ciò che solo tu puoi correggere, e
il 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 offre ancora il classico inventario 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 finiscono nel vault; nessun file in chiaro rimasto
aws s3 ls # si risolve dal vault on demand. nessun prefisso, nessun flag.
terraform apply # stesse credenziali, stesso comando
# Credenziali default dell'applicazione GCP (una credenziale a livello di 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 finiscono nel vault
jit run -- docker compose up # jit li inietta solo per questa esecuzione
docker login ghcr.io # funziona ancora; l'helper salva nel vault
# Export di shell che vivevano 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 finisce nel vault; i tuoi comandi restano, i segreti no
jit guard history # e impedisci che il prossimo venga registrato del tutto (zsh)
# (anche il semplice `jit migrate` lo propone, nel piano che ti chiede di confermare)
# Una CLI che porta il proprio token (gh, stripe, glab)
jit wrap gh # una volta sola
gh pr list # token iniettato a ogni 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, non uno
per come si inserisce sopra lo sblocco del vault, cosa fa --trust e come
disattivare i prompt per singolo strumento.
Perché alcuni strumenti non richiedono configurazione mentre altri vogliono un jit run? Una regola: può
lo strumento chiedere a jit il segreto da solo? AWS (tramite credential_process), la tua
shell al login e i login dei registry docker (tramite un credential helper) possono,
quindi non digiti nulla in più. Gli strumenti che leggono solo un file a runtime (docker
compose, SDK semplici) non possono chiederlo, 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'è
nessun prompt a cui rispondere, o quando vuoi un blocco rigido che la config di un progetto
non può mai aggirare. Strumenti supportati elenca esattamente cosa digitare
per ogni strumento e come viene consegnato ciascuno.
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 impegnato). Sblocchi
una volta, non una volta per comando.jit chiede prima di consegnarla e
indica chi la sta chiedendo. Questo è ciò che impedisce a un programma che non hai avviato tu 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 liberi tutti: anche dopo
che hai usato aws tu stesso, un losco npm install che cerca quelle stesse chiavi
fa comunque scattare un prompt che lo nomina, così puoi dire di no.
Non vuoi il secondo gate? Spegnilo; il blocco del vault resta (spegnere il gate richiede a sua volta un Touch ID, poiché riapre la finestra che chiude):
jit service consent off # gli strumenti risolvono silenziosamente mentre il vault è sbloccato
jit service consent on # chiedi di nuovo per strumento (impostazione predefinita)
Avvii qualcosa che richiede più credenziali in una volta? jit run --trust -- terraform apply approva l'intera esecuzione degli strumenti con un solo gesto. Dettagli completi:
consenso per-processo.
Entrambi i gate presuppongono che ci sia un umano a rispondere. Un agente AI che lavora di notte, un build lungo, 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 -> consenti a claude sotto iTerm2 di usare 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 il comando
(e ciò che lancia) ottiene quei segreti senza prompt — attraverso il blocco schermo
e tutto il resto, incluse le sessioni che avvii dopo: una nuova scheda, il successivo claude, uno
script che parte alle 3 di notte. È il tuo terminale a essere nominato, non un nome di cui ci si fida: un
programma che si chiama claude altrove 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
invece un singolo processo preciso, sparito quando esce? --pid. Ogni concessione finisce
nell'audit trail come evento a sé, così la mattina dopo puoi leggere esattamente
cosa il tuo agente ha toccato mentre dormivi. Dettagli completi:
grant di processo.
Ogni comando jit e ogni sblocco finiscono in un log durevole che rileggi con
jit audit, dal più recente, una riga key=value per evento, quindi si gira con grep come un
vero log di servizio. Gli argomenti dei comandi sono mascherati, quindi il log dimostra che un comando è stato eseguito
senza mai memorizzare il segreto che trasportava.
$ 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 di mezzo è la storia per cui jit esiste: 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 del 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 lo streaming
di nuovi eventi in tempo reale come tail -f, oppure --format json per un dump parsbile dalla macchina. Entrambe
le parti sono file durevoli accanto al vault, quindi risponde per la settimana scorsa con la stessa
facilità dell'ultima ora.
File .env, export di shell, AWS e Terraform, kubeconfig, login dei registry
Docker, GCP ADC, token .npmrc / .netrc, config dei 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 on demand.
Il catalogo completo, raggruppato per esattamente cosa digitare per ogni strumento, è
Strumenti supportati: segue il codice man mano che gli strumenti vengono aggiunti o
rimossi. Qualunque cosa non elencata può comunque essere avvolta con
jit wrap add.
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 config di shell, credential_process = jit … in ~/.aws/config, o uno
shim PATH), così i tuoi strumenti continuano a risolverla on demand. 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, quindi jit migrate undo lo rimette a posto byte per byte:
jit migrate ~/code/myapp # correzione applicata, 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), niente CLAPolyForm Perimeter License 1.0.0 - gratuita solo per uso personale e interno aziendale.