jitpass – Just-in-Time-Passwörter

Just-in-Time-Zugangsdaten für deine Entwicklungsmaschine.

Dokumentation · Schnellstart · Unterstützte Tools · Befehlsreferenz · Sicherheit

Status: Nur macOS (Apple Silicon) und noch in der Entwicklung.

Was jit ist (30 Sekunden)

Deine Geheimnisse liegen im Klartext überall auf deiner Maschine: .env-Dateien, ~/.aws/credentials, ~/.zshrc-Exports, .npmrc-Tokens, MCP-Konfigurationen. Alles, was als du läuft, kann sie lesen. Ein böses curl | sh, ein zwielichtiges npm install oder einer der KI-Agenten, die jetzt mit deinen vollen Berechtigungen in deinem Editor laufen.

jit verschiebt jedes Geheimnis in einen lokalen, verschlüsselten Tresor, der durch Touch ID geschützt ist, und schreibt die Dateien so um, dass deine Tools weiter funktionieren. Auf der Festplatte liegt jetzt ein Köder. Der echte Wert erscheint nur im Speicher, für den spezifischen Prozess, der danach gefragt hat, nach einer biometrischen Abfrage. Das Ergebnis: Du entsperrst einmal, jit fragt, bevor es eine Zugangsdaten an ein Tool (oder einen Agenten) übergibt, und der Rest der Zeit liegt ein Köder auf der Festplatte.

gestartet von Code	gestartet von claude

Was es nicht tut: Es macht ein bereits kompromittiertes Konto nicht sicher, und es schützt ein Geheimnis nicht, sobald es sich im Speicher des Prozesses befindet, der danach gefragt hat. Die Grenzen sind auf einer Seite vorne klar dargelegt: die bewussten Grenzen.

Wie es mechanisch funktioniert

Keine Kernel-Erweiterung, kein Dateisystem-Treiber, kein FUSE. Drei Mechanismen, ausgewählt danach, was das Tool tun kann:

1. Umgebungsvariablen in einen Prozess, dann execve. jits eigenes Image wird durch deinen Befehl ersetzt, sodass der Wert in diesem einen Prozess lebt und jit aus dem Speicher verschwunden ist.
2. Das native Zugangsdaten-Protokoll des Tools, wo eines existiert: AWS credential_process, Docker- und Git-Credential-Helper, kubectl-exec- Plugins, Terraforms Credentials-Helper. Das Tool fragt, jit antwortet, keine Datei ist beteiligt.
3. Ein Named-Pipe-Mount für Tools, die nur eine Datei lesen können.

Der Mount ist eine POSIX-FIFO, erstellt mit mkfifo(2) im Modus 0600. Ein Programm, das open(".env") aufruft, blockiert im Kernel, bis sich ein Schreiber verbindet. Der Hintergrunddienst ist dieser Schreiber: Er öffnet den Pfad mit O_WRONLY, was den Leser freigibt, schreibt die entschlüsselten Bytes aus dem Speicher in den Kernel- Pipe-Puffer, schließt und kehrt zu open(2) für den nächsten Leser zurück. Nichts berührt die Festplatte. Was geschrieben wird, wird pro Lesevorgang entschieden: Köder für einen umgebenden Leser, echte Werte nur innerhalb eines Laufs, den du autorisiert hast.

Die Identität des Aufrufers erklärt und prüft, sie entscheidet nie. Prozessnamen sind fälschbar, und ein schnell schließender FIFO-Leser kann die Identifizierung vollständig umgehen. Der Mensch, der die Abfrage beantwortet, ist das Tor; der Prozessname sagt dir nur, was du beantworten sollst. Vollständige Details in wie es funktioniert und Live-Mounts.

Installation

brew install jitpass/tap/jitpass

Das ist der empfohlene Weg, und bei einem Sicherheitstool ist der Grund wichtig. Releases sind mit einer Apple-Developer-ID signiert und von Apple notarisiert. Homebrew quarantänt, was es herunterlädt, sodass Gatekeeper die Binärdatei gegen ihr Notarisierungszertifikat prüft, bevor sie jemals ausgeführt werden darf. Um das selbst zu überprüfen, statt uns beim Wort zu nehmen, führe jit doctor aus: Seine jit- Zeile meldet signed CZC6BH93GJ, dieselbe Prüfung, die jit upgrade ausführt, bevor es etwas installiert.

curl -sL https://dl.jitpass.com/jitpass/jit/releases/latest/download/jitpass_darwin_arm64.tar.gz | tar -xz jit
shasum -a 256 jit   # vergleiche mit checksums.txt auf der Release-Seite
codesign -dv --verify --verbose=2 ./jit   # erwarte: Developer ID, TeamIdentifier=CZC6BH93GJ
sudo mv jit /usr/local/bin/

Nur Apple Silicon. Auf einem Intel-Mac baue aus dem Quellcode mit go install github.com/jitpass/jit/cmd/jit@latest.

Wähle einen Weg. Wenn du zuvor aus dem Tarball installiert hast und zu Homebrew wechselst, entferne die alte Kopie nach dem brew install (sudo rm /usr/local/bin/jit); sonst sitzen zwei jits auf dem PATH, die separat aktualisiert werden, und jit doctor wird das kennzeichnen.

Aktualisieren: brew upgrade jitpass oder jit upgrade: ein verifiziertes Selbst-Update (Developer-ID-Signatur und Prüfsumme werden beide vor dem Austausch geprüft, der Dienst wird neu gestartet). In beiden Fällen bleibt dein Tresor unberührt.

Homebrew installiert Shell-Vervollständigung mit der Binärdatei, sodass jit <TAB> Unterbefehle, Flags, Tresorpfade und umhüllbare Tool-Namen sofort vervollständigt. Wenn du aus dem Tarball oder aus dem Quellcode installiert hast, füge es selbst hinzu:

echo 'source <(jit completion zsh)' >> ~/.zshrc && exec zsh

In jedem Fall sagt dir jit doctor, ob die Vervollständigung deine Shell erreicht.

Wie du es tatsächlich verwendest

jit scan                            # schreibgeschützt. ändert keine Datei, die es scannt, gibt keinen echten Wert aus.
jit vault init                      # Tresor erstellen (Master-Schlüssel in deinem Login-Keychain)
jit migrate --dry-run               # Vorschau des gesamten maschinenweiten Korrekturplans
jit migrate                         # anwenden: zeigt Plan, fragt [y/N], eine Touch ID
jit migrate ~/code/myapp            # oder nur ein Projekt korrigieren
jit run -- npm run dev              # dein Tool ausführen; echte Werte werden nur in diesen Prozess injiziert

jit scan ohne Pfad durchsucht dein gesamtes Home-Verzeichnis, gib ihm also bei einem großen einen Moment Zeit. Um direkt an eine Stelle zu gehen, zeige auf einen Pfad: jit scan ~/.aws.

Im Alltag ist es meistens jit run -- <cmd>. Für CLIs, die ihr eigenes Login- Token mit sich führen (gh, glab, stripe und mehr), führst du jit wrap gh einmal aus und tippst dann für immer normal gh weiter.

Nicht sicher, ob etwas jit wrap, jit migrate oder nichts braucht? Das musst du nicht wissen. jit scan teilt alles, was es findet, auf in das, was jit schützen wird (ein Befehl – die Wraps eingeschlossen) und das, was nur du beheben kannst, und ein bloßes jit migrate führt diesen gesamten Plan aus:

$ jit scan
  DEINE GEHEIMNISSE: 7 — 0 durch jit geschützt (0%)
  ▱▱▱▱▱▱▱▱▱▱  auf 100%: ein Befehl +71% · 2 Geheimnisse, die nur du beheben kannst +29%

  jit wird diese schützen — 5 Geheimnisse in 4 Dateien, 0% → 71%
      → jit migrate
        ~/.zshrc            STRIPE_API_KEY, DB_PASSWORD
        ~/.config/gh/hosts.yml  GitHub-CLI-Token · umhüllt gh
        ...

  nur du kannst diese schützen — 2 Geheimnisse, 71% → 100%

    [rotieren, dann jede Kopie löschen]
    ! Ein Produktionsdatenbank-Passwort in 2 Dateien
      → rotiere es jetzt, dann lösche jede Kopie

(jit scan --full gibt weiterhin das klassische Inventar nach Kategorien mit Schweregraden aus, einschließlich des Abschnitts Umhüllbare CLI-Tokens.)

Deine Alltagswerkzeuge

Migriere die Zugangsdaten einmal und verwende das Tool dann weiterhin so, wie du es immer getan hast.

# AWS (und Terraform und jedes AWS SDK)
jit migrate ~/.aws/credentials       # Schlüssel wandern in den Tresor; keine Klartextdatei bleibt
aws s3 ls                            # wird bei Bedarf aus dem Tresor aufgelöst. kein Präfix, kein Flag.
terraform apply                      # gleiche Zugangsdaten, gleicher Befehl

# GCP-Anwendungsstandard-Zugangsdaten (maschinenweite Zugangsdaten)
jit migrate ~/.config/gcloud/application_default_credentials.json
terraform apply                      # google-Provider liest ADC; funktioniert nach einer Touch-ID-Abfrage

# Docker / docker-compose
jit migrate ~/.docker/config.json    # Registry-Anmeldungen wandern in den Tresor
jit run -- docker compose up         # jit injiziert sie für diesen Lauf
docker login ghcr.io                 # funktioniert weiterhin; der Helper speichert im Tresor

# Shell-Exports, die früher in ~/.zshrc standen
jit migrate ~/.zshrc                 # hinterlässt einen Einzeiler-Hook; neue Shells haben einfach die Variablen
./deploy.sh                          # Skripte, die diese Variablen lesen, funktionieren unverändert

# Tokens, die du einst an der Eingabeaufforderung getippt hast und die jetzt in deinem Shell-Verlauf liegen
jit migrate ~/.zsh_history           # jedes wandert in den Tresor; deine Befehle bleiben, die Geheimnisse nicht
jit guard history                    # und verhindere, dass das nächste überhaupt aufgezeichnet wird (zsh)
                                     # (ein bloßes `jit migrate` bietet das auch an, in dem Plan, den es zu bestätigen bittet)

# Eine CLI, die ihr eigenes Token mit sich führt (gh, stripe, glab)
jit wrap gh                          # einmalig
gh pr list                           # Token wird pro Aufruf injiziert, für immer

Wenn jedes Tool zum ersten Mal nach einer echten Zugangsdaten greift, fragt jit einmal und merkt sich deine Antwort, bis sich der Tresor sperrt. Siehe Zwei Touch-ID-Momente dafür, wie das auf der Tresor-Entsperrung aufbaut, was --trust tut und wie du die Abfragen pro Tool deaktivierst.

Warum brauchen manche Tools keine Einrichtung, während andere ein jit run benötigen? Eine Regel: kann das Tool jit selbst nach dem Geheimnis fragen? AWS (über credential_process), deine Shell beim Login und Dockers Registry-Anmeldungen (über einen Credential-Helper) können das alle, du musst also nichts extra tippen. Tools, die zur Laufzeit nur eine Datei lesen (docker compose, einfache SDKs), können nicht fragen, also reicht jit run ihnen den Wert.

Die maschinenweiten Zugangsdaten-Dateien (GCP ADC, sops, npm, netrc) funktionieren im Alltag genauso: Führe dein Tool aus und genehmige die Abfrage pro Prozess. Füge jit run --with <name> nur hinzu, wenn du es explizit willst: für Skripte und CI, wo es keine Abfrage zu beantworten gibt, oder wenn du ein hartes Tor willst, das die eigene Konfiguration eines Projekts nie erreichen kann. Unterstützte Tools listet genau auf, was du für jedes Tool tippen musst und wie jedes zugestellt wird.

Zwei Touch-ID-Momente, nicht einer

jit fragt an zwei verschiedenen Momenten nach deinem Fingerabdruck und übernimmt dabei zwei verschiedene Aufgaben:

1. Deinen Tresor entsperren. Beim ersten Mal, dass du jit verwendest, nachdem es sich gesperrt hat, öffnet eine Touch ID den Tresor für die gesamte Sitzung (5 Minuten Aktivität, dann sperrt er sich wieder; und nie länger als 8 Stunden, egal wie beschäftigt du bist). Du entsperrst einmal, nicht einmal pro Befehl.
2. Eine Zugangsdaten an ein Tool übergeben. Zusätzlich fragt jit beim ersten Mal, dass ein bestimmtes Tool nach einer echten Zugangsdaten greift, bevor es sie übergibt, und benennt, was fragt. Das verhindert, dass ein Programm, das du nicht ausgeführt hast, still deine Schlüssel verwendet, während der Tresor geöffnet ist.

$ aws s3 ls
  Touch ID  ->  entsperre deinen Tresor              # Tor 1: öffnet den Tresor für 5 Min
  Touch ID  ->  aws will deine aws-Zugangsdaten       # Tor 2: dieses Tool, diese Zugangsdaten
  ...deine Buckets...

$ aws s3 cp ./file s3://bucket/   # gleiches Tool, gleiche Sitzung: keine Abfrage

$ terraform apply
  Touch ID  ->  terraform will deine aws-Zugangsdaten   # ein anderes Tool: es fragt selbst

Tor 2 verhindert, dass ein entsperrter Tresor ein Freifahrtschein ist: Selbst nachdem du aws selbst verwendet hast, löst ein zwielichtiges npm install, das nach denselben Schlüsseln greift, weiterhin eine Abfrage aus, die es benennt, sodass du Nein sagen kannst.

Willst du das zweite Tor nicht? Schalte es ab; die Tresorsperre bleibt (das Abschalten selbst erfordert eine Touch ID, da es das Fenster wieder öffnet, das es schließt):

jit service consent off   # Tools lösen still auf, während der Tresor entsperrt ist
jit service consent on    # wieder pro Tool fragen (Standard)

Startest du etwas, das mehrere Zugangsdaten gleichzeitig benötigt? jit run --trust -- terraform apply genehmigt die Tools dieses gesamten Laufs mit einer Geste. Vollständige Details: Zustimmung pro Prozess.

Verlässt du die Tastatur? jit grant

Beide Tore setzen voraus, dass ein Mensch da ist, um zu antworten. Ein KI-Agent, der über Nacht arbeitet, ein langer Build, ein geplanter Job: Der Bildschirm sperrt sich, die Sitzung bricht ab und der Lauf bleibt an einer Abfrage hängen, die niemand sehen wird. Ein Prozess-Grant verlagert deine Entscheidung nach vorne, statt sie zu entfernen – eine Touch ID, gegeben, während du noch da bist, die genau benennt, was du freigibst:

$ jit grant --process claude --profile jamf --for 8h
  Touch ID  ->  claude unter iTerm2 darf 2 Geheimnisse (jamf) unbeaufsichtigt für 8h verwenden
✓ gewährt g-7f3a2c81   claude -> jamf   bis 17:42
  └ deckt claude unter iTerm2 ab: 1 läuft jetzt, alle vor 17:42 gestarteten

Für die nächsten 8 Stunden erhält jedes claude unter dem Terminal, in dem du das getippt hast (und was es startet), diese Geheimnisse ohne Abfragen – durch Bildschirmsperre und alles hindurch, einschließlich Sitzungen, die du später startest: ein neuer Tab, das nächste claude, ein Skript, das um 3 Uhr morgens feuert. Es ist dein Terminal, das benannt wird, kein Name, dem vertraut wird: Ein Programm, das sich irgendwo anders auf der Maschine claude nennt, stammt nicht von diesem Baum ab und erbt nichts. Der Grant endet an seiner Frist, wenn du dieses Terminal beendest, oder in dem Moment, in dem du jit grant revoke tippst (das keine Fingerabdruck-Abfrage benötigt – Zugriff zu entziehen ist immer kostenlos). Willst du einen exakten Prozess stattdessen, der verschwindet, wenn er endet? --pid. Jede Gewährung landet im Prüfpfad als eigenes Ereignis, sodass du am nächsten Morgen genau lesen kannst, was dein Agent berührt hat, während du geschlafen hast. Vollständige Details: Prozess-Grants.

KI-Agenten und MCP-Server

Der Agent in deinem Editor läuft als du, mit deinen Berechtigungen, und liest den ganzen Tag Dateien für dich. Das ist der ganze Sinn davon, und es ist auch der Grund, warum eine Klartext-.env in deinem Repository jetzt ein sehr anderes Risiko ist als vor zwei Jahren. jit behandelt Agenten als erstklassig, auf vier Ebenen:

jit migrate ~/.claude.json           # MCP-Server-Konfigurationen: Schlüssel wandern in den Tresor,
                                     # jeder Server startet jetzt über `jit run`
jit wrap claude                      # die KI-CLIs selbst: claude, codex, gemini,
                                     # cursor-agent, copilot, cline, opencode, kiro-cli
jit grant --process claude --profile myapp --for 8h
                                     # lass es über Nacht arbeiten, ohne eine Abfrage, die niemand beantwortet
jit audit --parent claude            # lies genau zurück, was es berührt hat, während du geschlafen hast

• Die Abfrage benennt den Agenten. Mit aktivierter Zustimmung pro Prozess (Standard) erhältst du beim ersten Mal, dass ein Tool nach einer echten Zugangsdaten greift, eine Touch ID, die sagt, welches Programm fragt. Das zeigen die beiden Screenshots oben auf dieser Seite: dasselbe Geheimnis, angefordert von VS Code und von claude, jeweils benannt. Ein Agent, der still ~/.aws/credentials liest, ist eine Abfrage, kein stiller Erfolg.
• MCP-Server starten über jit run. Eine migrierte MCP-Konfiguration enthält Tresorpfade, keine Schlüssel, sodass die Konfigurationsdatei selbst sicher auf der Festplatte liegen und sicher an den Agenten übergeben werden kann, der sie liest.
• Ein Köder ist, was ein unbefugter Lesezugriff erhält. Ein Agent, der dein Repository nach .env durchsucht und es kalt liest, erhält Platzhalterwerte, und der Lesezugriff wird protokolliert.
• jit audit --parent claude zeigt jedes Geheimnis, das ein Agent verwendet hat, jede Abfrage, die es ausgelöst hat, und jede, die du abgelehnt hast.

Mehr in MCP / KI-Tools und Zustimmung pro Prozess.

Der Prüfpfad: Was passiert ist und wer es getan hat

Jeder jit-Befehl und jede Entsperrung landet in einem dauerhaften Protokoll, das du mit jit audit zurückliest, neueste zuerst, eine key=value-Zeile pro Ereignis, sodass es sich wie ein echtes Dienstprotokoll durchsuchen lässt. Befehlsargumente werden maskiert, sodass das Protokoll beweist, dass ein Befehl lief, ohne jemals das Geheimnis zu speichern, das er trug.

$ 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

Die mittlere Zeile ist die Geschichte, für die jit existiert: aws/default wurde von aws s3 ls gelesen, gestartet von claude. Die letzte ist eine Abfrage, die du abgelehnt hast: ein node postinstall.js unter npm, das nach denselben Schlüsseln greift, abgelehnt. jit protokolliert auch, was der Dienst an seinem Socket abgewiesen hat (einen Prozess, von dem der Kernel sagt, dass er nicht dir gehört, der den Agenten abtastet) als kind=error.

Eingrenzen mit Flags statt grep: --kind, --status ok|failed|denied, --since/--until (ein Alter wie 2h/3d oder ein Datum), --parent claude, --secret aws, --user, --grep <regexp>. Füge --follow (-f) hinzu, um neue Ereignisse live zu streamen wie tail -f, oder --format json für einen maschinenlesbaren Dump. Beide Hälften sind dauerhafte Dateien neben dem Tresor, sodass es für letzte Woche ebenso leicht Rechenschaft ablegt wie für die letzte Stunde.

Was es unterstützt

.env-Dateien, Shell-Exports, AWS und Terraform, kubeconfig, Docker-Registry- Anmeldungen, GCP ADC, .npmrc-/.netrc-Tokens, MCP-Server-Konfigurationen, reine Token- Dateien, Zugangsdaten, die in deinem Shell-Verlauf aufgezeichnet sind, umhüllbare CLIs (gh, stripe, vercel, …) und SSO-CLIs, die beim Login Zugangsdaten prägen (clisso). In jedem Fall funktioniert die Datei weiter und der echte Wert kommt bei Bedarf aus dem Tresor.

Der vollständige Katalog, gruppiert nach genau dem, was du für jedes Tool tippen musst, ist Unterstützte Tools: Er folgt dem Code, wenn Tools hinzugefügt oder entfernt werden. Alles, was nicht aufgeführt ist, kann trotzdem mit jit wrap add umhüllt werden.

Verwahrst du deine Geheimnisse bereits in 1Password? Mit installierter CLI verknüpft jit migrate statt zu kopieren: Ein Wert, der bereits in 1Password lebt, wird als seine op://-Referenz im Tresor verwahrt, sodass 1Password das System of Record bleibt und jit den Wert Just-in-Time über jeden oben genannten Mechanismus zustellt (jit vault link tut dasselbe für ein Geheimnis von Hand).

Kann ich es rückgängig machen? Immer.

jit zerstört niemals eine Zugangsdaten. Migrieren verschiebt den Wert in den Tresor und hinterlässt einen funktionierenden Hook dort, wo er war (eine Köder-.env, eine eval "$(jit export)"-Zeile in deiner Shell-Konfiguration, credential_process = jit … in ~/.aws/config oder ein PATH-Shim), sodass deine Tools ihn weiterhin bei Bedarf auflösen. Die Zugangsdaten existieren weiterhin, nur verschlüsselt statt im Klartext.

Und jede Änderung ist umkehrbar. Bevor jit eine Datei berührt, sichert es sie verschlüsselt in den Tresor, sodass jit migrate undo sie byte-für-byte wiederherstellt:

jit migrate ~/code/myapp        # Korrektur angewendet, eine Touch ID
# deine Meinung geändert, oder etwas ist kaputt?
jit migrate undo ~/code/myapp   # jede berührte Datei wiederhergestellt, byte-für-byte

Mehr erfahren

Die Dokumentation liegt unter docs/, nach Aufgabe organisiert:

• Schnellstart: Einrichtung, Migrieren, Leben mit der Korrektur, Schritt für Schritt
• Wie es funktioniert: der Tresor, der Dienst, Mounts und Shims auf einer Seite
• FAQ: Entwickler- und Sicherheitsfragen, unverblümt beantwortet
• Zustimmung pro Prozess: was die Abfragen pro Tool tun und wie du sie anpasst oder deaktivierst
• Prozess-Grants: genehmige ein laufendes Tool vorab, um unbeaufsichtigt für ein begrenztes, widerrufbares, geprüftes Fenster zu arbeiten
• Prüfpfad: lies jeden Befehl, jede Entsperrung und jede Ablehnung zurück, filterbar und verfolgbar
• Befehlsreferenz: jeder Befehl und jedes Flag, aus der CLI generiert
• Sicherheitsarchitektur: das Bedrohungsmodell und die ehrlichen Grenzen
• CONTRIBUTING.md: Build-/Test-Einrichtung; Sign-off über DCO (git commit -s), keine CLA

Lizenz

PolyForm Perimeter License 1.0.0 – nur kostenlos für persönliche und interne Unternehmensnutzung.