Anmeldedaten-Proxy
Ihre KI-Agenten rufen APIs auf.
Sie sollten niemals die Schlüssel halten.
Der Clavitor Proxy sitzt zwischen Ihren KI-Agenten und den APIs, die diese aufrufen. Anmeldedaten werden auf Netzwerkebene injiziert – der Agent sieht, speichert oder protokolliert niemals das eigentliche Geheimnis. Eine Binärdatei. Eine Umgebungsvariable. Null Code-Änderungen.
Das Problem, das Sie bereits haben
Geheimnisse in Umgebungsvariablen
Ihre KI-Agenten lesen OPENAI_API_KEY aus der Umgebung. Dieser Schlüssel ist in /proc, in Absturzabbildern, in CI-Protokollen, in jedem Werkzeug, das der Agent aufruft, sichtbar. Eine einzige geleakte Protokollzeile und der Schlüssel ist öffentlich.
Geheimnisse im Agentenspeicher
Selbst wenn der Agent den Schlüssel zur Laufzeit abruft, hält er ihn für die Dauer des Prozesses im Speicher. Eine kompromittierte Fähigkeit, eine Prompt-Injection, ein Debug-Dump – der Schlüssel ist zum Mitnehmen da.
Kein Audit der genutzten Anmeldedaten
Wenn ein API-Schlüssel als Zeichenkette geteilt wird, gibt es keine Aufzeichnung darüber, welcher Agent ihn wann oder wofür verwendet hat. Wenn der Schlüssel leckt, rotieren Sie ihn und hoffen. Es gibt keine forensische Spur.
Die Probleme, die Sie hoffentlich nicht haben
API-Schlüssel im Quellcode
Fest kodiert in einer Konfigurationsdatei, in Git eingecheckt, von jedem Entwickler und CI-Runner im Team geklont. Ein öffentlicher Fork und er ist auf dem geheimen Scan-Dashboard von GitHub – oder schlimmer noch, er ist es nicht.
Anmeldedaten in Slack
"Kannst du mir den Stripe-Schlüssel schicken?" In einer Direktnachricht eingefügt, für immer durchsuchbar, in jedem Compliance-Archiv exportiert. Slack ist kein Tresor. Ebenso wenig E-Mail, Google Docs oder ein Haftnotiz auf einem Monitor.
.env-Dateien auf jedem Laptop
Zwölf Entwickler, zwölf Kopien von Produktionsanmeldedaten in Klartextdateien, die niemals rotiert werden. Ein gestohlener Laptop, ein ~/.bash_history-Leak, ein übermäßig hilfreiches Backup-Tool – und Sie rotieren jeden Schlüssel im Unternehmen um 2 Uhr morgens.
Nehmen Sie Anmeldedaten vollständig vom Agenten weg.
Der Proxy sitzt zwischen dem Agenten und der API. Der Agent schreibt eine Referenz – clavitor://OpenAI/key – dorthin, wo das Geheimnis hingehört. Der Proxy löst sie lokal auf, injiziert die tatsächlichen Anmeldedaten in die HTTPS-Anfrage und leitet sie weiter. Die Protokolle des Agenten zeigen den Sitzhalter. Die API empfängt den Schlüssel. Nichts dazwischen speichert ihn.
Keine Umgebungsvariablen. Keine Geheimnisse im Speicher des Agenten. Keine Anmeldedaten auf der Befehlszeile. Der eigentliche Schlüssel gelangt nie in die Umgebung, den Speicher oder die Protokolle des Agenten, sodass der Agent nichts einfügen, ausgeben oder sich zum Offenlegen überreden lassen kann. Das gilt für Schlüssel, die über den Proxy geleitet werden. Wer die Maschine kontrolliert, kann den Proxy weiterhin nutzen oder den Schlüssel mit Root aus dem Speicher des Proxys lesen, und ein kompromittierter Agent kann den ihm gewährten Zugriff weiterhin missbrauchen. Geltungsbereich, Ratenlimits und Audit begrenzen das.
# proxy-auth is the proxy's access token, the file beside the binary
$ export HTTPS_PROXY="http://clavitor:$(cat proxy-auth)@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-EXAMPLE_not_a_real_key.
# Neither did the logs, the crash dump, or the conversation history.Funktioniert mit jedem Agenten, der HTTPS-Aufrufe tätigt: Claude Code, Codex, OpenClaw, CrewAI, LangChain, benutzerdefinierte Skripte. Setzen Sie eine Umgebungsvariable und die API-Aufrufe des Agenten fließen durch den Proxy. Kein SDK, kein Plugin, keine Code-Änderungen.
Was unter der Haube passiert
Lokal entschlüsselt, pro Anfrage
Der Proxy ruft die verschlüsselten Anmeldedaten aus dem Tresor ab und entschlüsselt sie auf dem Gerät. Der Klartext existiert im Prozessspeicher für eine HTTP-Anfrage, dann ist er weg. Nichts wird zwischengespeichert. Nichts wird auf die Festplatte geschrieben. Jede Anfrage wird frisch entschlüsselt.
Ordnet Felder Headern zu
Bearer-Token, API-Schlüssel, Basic Auth – der Proxy ordnet Tresorfeld-Labels automatisch den richtigen HTTP-Headern zu. Oder der Agent wählt das exakte Feld mit einer clavitor://-Referenz aus. In jedem Fall landen die Anmeldedaten an der richtigen Stelle, ohne dass der Agent sie jemals sieht.
Bereiche, Ratenbegrenzungen, Audit
Der Tresor erzwingt Bereichsgrenzen und Ratenbegrenzungen. Ein Agent, der auf zu viele unterschiedliche Anmeldedaten zugreift, wird automatisch gesperrt. Jeder Zugriff wird protokolliert. Fügen Sie eine Agenten-ID in den Sitzhalter ein – clavitor://agentid@Entry/field – für agentenbezogene Audit-Logs und Ratenbegrenzungen über einen gemeinsamen Proxy.
Bereitstellung
Eine Binärdatei. Sidecar zum Agenten. Keine Änderungen an der Netzwerkinfrastruktur.
Host mit einem Agenten
Laden Sie die Binärdatei herunter, führen Sie clavitor-proxy init mit dem Registrierungsblob und dem Schlüssel aus, setzen Sie HTTPS_PROXY am Agenten. Fertig. Der Proxy bindet an 127.0.0.1:1983 (Sidecar für einen Agenten). Von sich aus bindet er an keine andere Adresse: Der Port überträgt ein Zugriffstoken im Klartext, daher verweigert er außerhalb von Loopback den Start, es sei denn, Sie setzen CLAVITOR_PROXY_LISTEN auf die Adresse und legen zusätzlich neben der Binärdatei eine nur dem Eigentümer zugängliche Datei namens proxy-allow-private an, was Sie nur tun, wenn diese Adresse ein vertrauenswürdiges privates Netz ist (VPN oder Tailscale).
Host mit mehreren Agenten
Jeder Agent erhält seine eigene Kopie der Binärdatei mit seiner eigenen Sidecar-Konfigurationsdatei. Jede Kopie hat ihren eigenen Bereich, ihre eigenen Ratenbegrenzungen, ihren eigenen Audit-Trail. Agent A kann die Anmeldedaten von Agent B nicht sehen. Isolation per Design.
Jeder Anmeldedaten-Proxy, der in der Cloud läuft – Ihr eigener oder der eines anderen – ist ein Ziel. Brechen Sie den Proxy, erhalten Sie die Anmeldedaten jedes Kunden. Das ist kein theoretisches Risiko. Es ist das Geschäftsmodell jedes Anmeldedaten-Proxy-as-a-Service.
Der Proxy von Clavitor läuft auf Ihrer Infrastruktur. Entschlüsselt lokal. Die Anmeldedaten liegen für die Dauer einer Anfrage im Prozessspeicher. Es gibt keinen Cloud-Dienst, der Ihre Klartextschlüssel hält. Es gibt keinen API-Endpunkt, der Ihre Geheimnisse ausliefert. Es gibt keine Cloud-Kopie Ihrer Schlüssel, die sich kompromittieren ließe.
Ihre Agenten rufen bereits APIs auf.
Halten Sie sie in ihrer Spur.
Ihr Tresor, Ihre Bereiche, Ihr Audit-Trail. Der Proxy fügt einen Durchsetzungspunkt auf Netzwerkebene hinzu, ohne dass am Agenten Code-Änderungen erforderlich sind.