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. Keine Anmeldedaten in der Befehlszeile. Der Agent kennt den Schlüssel nicht, kann den Schlüssel nicht leaken, kann nicht dazu gebracht werden, den Schlüssel preiszugeben.
$ export HTTPS_PROXY=http://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-proj-abc123.
# 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 Registrierungs-Token aus, setzen Sie HTTPS_PROXY für den Agenten. Fertig. Standardmäßig bindet der Proxy an 127.0.0.1:1983 (Sidecar für einen Agenten); setzen Sie CLAVITOR_PROXY_LISTEN, um woanders zu binden, wenn ein Proxy mehrere Agenten in einem privaten Netzwerk bedient.
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 Clavitor-Proxy läuft auf Ihrer Infrastruktur. Entschlüsselt lokal. Die Anmeldedaten existieren im Prozessspeicher für die Dauer einer Anfrage. Es gibt keinen Cloud-Dienst, der Ihre Klartextschlüssel speichert. Es gibt keinen API-Endpunkt, der Ihre Geheimnisse bereitstellt. Es gibt nichts zu brechen.
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.