Phantom Secrets: Ein lokaler Proxy und ein MCP-Server, der KI-Coding-Agenten echte Secrets verbirgt

Für wen das gedacht ist

Wenn Sie einen KI-Coding-Agenten in Ihren Arbeitsalltag integriert haben und in der .env Ihres Projekts echte Secrets liegen, können Logs, Fehlerausgaben und Kontextausschnitte allesamt zu Wegen für ein Secret-Leak werden. Phantom richtet sich an Menschen, die eine harte Grenze brauchen zwischen „die Anwendung bekommt weiterhin die echten Werte“ und „der Agent sieht den Secret-Wert nie“, sowie an Teams, die Secrets zentral verteilen und rotieren wollen, ohne sie in die Toolchain jedes Einzelnen auszurollen.

Die Form ist „lokaler Proxy + MCP-Server“: Projekt-Secrets werden durch phm_ Platzhalter mit Gültigkeitsbereich ersetzt, die Anwendung holt sich die echten Werte über einen authentifizierten lokalen Proxy, und auf der Agentenseite kommen nur MCP-Werkzeuge zum Einsatz, die keine Werte sehen – für Inventur, Diagnose und kontrollierte Anfragen. Voraussetzung ist, dass Sie einen Proxy-Prozess dauerhaft auf Ihrem Rechner laufen lassen und die Umschreibung der .env in Ihren eigenen Versionsverwaltungsprozess aufnehmen – dieser Schritt ist nichts, was man mal eben überspringen kann.

In drei Minuten zum ersten Versuch

Der empfohlene offizielle Weg ist Homebrew. Die von dem Repository angegebene macOS-Installation ist eine Kette aus drei Schritten: erst tap, dann trust, dann install; heraus kommen zwei ausführbare Dateien, phantom und phantom-mcp, passend zur im Repository genannten Version v0.7.9.

brew tap ashlrai/phantom
brew trust --formula ashlrai/phantom/phantom
brew install ashlrai/phantom/phantom

Voraussetzung: Homebrew muss auf macOS bereits installiert sein; wenn Sie stattdessen selbst aus dem Quellcode bauen, fixiert das Repository die Version der Compiler-Toolchain, die Build-Umgebung braucht also die passende Rust-Toolchain.

Es folgen zwei Konfigurationsschritte in dieser Reihenfolge. Zuerst wechseln Sie in das Projektverzeichnis und führen phantom init aus; beachten Sie, dass dies ein Schreibvorgang ist – es überschreibt die .env des Projekts und ersetzt die echten Schlüsselwerte durch phm_ Platzhalter. Der Kontrollpunkt ist, vor der Ausführung zu bestätigen, dass die .env gesichert oder eingecheckt ist, und in der Befehlsausgabe nachzuprüfen, ob die Anzahl der Ersetzungen zum Erwarteten passt. Der zweite Schritt schreibt die Konfiguration für den jeweiligen Client:

phantom init
phantom setup --client claude

Danach nutzen Sie den schreibgeschützten Schritt für eine risikoarme Prüfung: phantom list listet Ihr Secret-Verzeichnis auf, zeigt aber keinen einzigen Wert. Das beobachtbare Erfolgszeichen: Das Terminal listet die Eintragsnamen auf, und hinter keinem Eintrag steht ein echtes Secret-Zeichen; lassen Sie den Agenten anschließend noch einmal das Repository lesen, dann bekommt er Dinge, die mit phm_ beginnen, statt der echten Werte.

Die vollständige Befehls- und Parameterübersicht finden Sie im offiziellen Repository https://github.com/ashlrai/phantom-secrets

Anwendungsfälle

Fall eins: dem Agenten einen Kanal geben, der das Verzeichnis sieht, aber nicht die Werte. Die MCP-Werkzeuge auf der Agentenseite sind wertblind und decken drei Verwendungszwecke ab: Inventur, Diagnose und kontrollierte Anfragen; das Repository verortet diese Werkzeuge als Fähigkeits-, Status- und Repository-Zustandsprüfungen, die keinerlei Aktion auf Provider-Seite auslösen. Sie können dem Agenten also unbesorgt die Frage stellen, „welche Secrets hat dieses Projekt konfiguriert, ist die aktuelle Strecke funktionsfähig, und welche Dateien im Repository referenzieren Platzhalter“ – der Agent gibt keine Secret-Werte zurück und ändert beim Prüfen auch keine Cloud-Ressourcen nebenbei.

Fall zwei: den Anwendungscode weiterhin mit echten Werten laufen lassen und dabei die echten Werte aus dem Blickfeld des Agenten halten. Der Austausch passiert in der Initialisierungsphase: Die echten Schlüsselwerte in der .env werden zu phm_ Platzhaltern mit Gültigkeitsbereich, die Anwendung liest wie gewohnt Umgebungsvariablen, und ihre Anfragen übernimmt der lokale Proxy, der die echten Werte nach der Authentifizierung abholt. Der kontrollierte Anfrage-Einstieg auf der Proxy-Seite teilt sich dieselbe „keine Werte“-Bedingung mit den Einstiegen für Inventur und Diagnose – die Anwendung läuft also, und der Agent bekommt die Secrets selbst weiterhin nicht zu fassen. Beachten Sie, dass das Repository-Material nur beschreibt, der Proxy sei ein „authentifizierter“ lokaler Proxy, die konkrete Form der Authentifizierung aber nicht ausführt; orientieren Sie sich für diese Ebene an der Beschreibung im Repository.

Grenzen des Einsatzes

Erstens: phantom init überschreibt die .env, das ist ein echter Schreibvorgang. Sichern oder committen Sie vorher, und kleben Sie den Diff vor und nach der Ersetzung nicht direkt in öffentliche Kanäle.

Zweitens: Die Wertblindheit der Werkzeuge auf der Agentenseite garantiert nur „keine Werte sichtbar“, nicht „kann alles“. Das Repository verortet sie als Fähigkeits-, Status- und Repository-Zustandsprüfungen und löst keine Provider-Aktionen für Sie aus; die tatsächlichen Cloud-Aufrufe passieren auf dem Anfragepfad, den die Anwendung über den lokalen Proxy schickt – bei der Fehlersuche müssen Sie diese beiden Abschnitte unterscheiden.

Drittens: Das ist kein risikofreies Werkzeug: Es liest die lokale .env und die Client-Konfigurationsdateien, und der lokale Proxy sendet Anfragen an Drittanbieter-Provider, sodass Secrets weiterhin zwischen Ihrer Maschine und diesem Provider fließen. Ob Sie diesen Weg akzeptieren, hängt davon ab, ob Ihre Organisation ihn auf der Agentenseite zulässt.

Viertens: Installationswege und Befehlsbeschreibungen im Repository ändern sich mit den Versionen; prüfen Sie vor einem Upgrade noch einmal das offizielle Repository.