Credential Proxy
Ihre Agenten führen API-Aufrufe aus.
Sie sollten niemals die Schlüssel halten.
Der Clavitor Proxy sitzt zwischen Ihren KI-Agenten und den aufgerufenen APIs. Anmeldedaten werden auf der Netzwerkschicht injiziert — der Agent sieht, speichert oder protokolliert das echte Geheimnis niemals. Eine Binärdatei. Eine Umgebungsvariable. Null Codeänderungen.
Das Problem, das Sie bereits haben
Geheimnisse in Umgebungsvariablen
Ihre Agenten lesen OPENAI_API_KEY aus der Umgebung. Dieser Schlüssel ist in /proc, in Crash-Dumps, in CI-Logs und in jedem Tool sichtbar, das der Agent aufruft. Eine einzige durchgesickerte Log-Zeile und der Schlüssel ist öffentlich.
Geheimnisse im Agenten-Speicher
Selbst wenn der Agent den Schlüssel zur Laufzeit abruft, hält er ihn für die Dauer des Prozesses im Arbeitsspeicher. Eine kompromittierte Skill, ein Prompt-Injection, ein Debug-Dump — der Schlüssel ist leicht zugänglich.
Keine Prüfung der Nutzung
Wenn ein API-Schlüssel als String geteilt wird, gibt es keine Aufzeichnung darüber, welcher Agent ihn wann oder wofür verwendet hat. Wenn der Schlüssel durchsickert, müssen Sie ihn rotieren und hoffen. Es gibt keinen forensischen Pfad.
Die Probleme, von denen wir hoffen, dass Sie sie nicht haben
API-Schlüssel im Quellcode
Hardcodiert in einer Konfigurationsdatei, in git committet, von jedem Entwickler und CI-Runner im Team geklont. Ein einziger öffentlicher Fork und er erscheint auf dem Secret-Scanning-Dashboard von GitHub — oder schlimmer noch, er erscheint dort 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. Das gilt auch für E-Mail, Google Docs oder einen Klebezettel am Monitor.
.env-Dateien auf jedem Laptop
Zwölf Entwickler, zwölf Kopien von Produktions-Anmeldedaten in Klartextdateien, die nie rotiert werden. Ein gestohlener Laptop, ein ~/.bash_history-Leak, ein zu hilfreiches Backup-Tool — und Sie müssen um 2 Uhr morgens jeden Schlüssel im Unternehmen rotieren.
Entfernen Sie Anmeldedaten vollständig vom Agenten.
Der Proxy sitzt zwischen dem Agenten und der API. Der Agent schreibt eine Referenz — clavitor://OpenAI/key — dorthin, wo das Geheimnis hin soll. Der Proxy löst diese lokal auf, injiziert die echten Anmeldedaten in den HTTPS-Request und leitet ihn weiter. Die Logs des Agenten zeigen nur den Platzhalter. Die API erhält den Schlüssel. Dazwischen speichert nichts das Geheimnis.
Keine Umgebungsvariablen. Keine Geheimnisse im Speicher. Keine Anmeldedaten auf der Befehlszeile. Der Agent kennt den Schlüssel nicht, kann den Schlüssel nicht durchsickern lassen und kann nicht dazu verleitet 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
# Der Proxy hat den Platzhalter aufgelöst. Der Agent hat sk-proj-abc123 nie gesehen.
# Weder die Logs, noch der Crash-Dump oder der Gesprächsverlauf.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
Lokale Entschlüsselung pro Anfrage
Der Proxy ruft die verschlüsselten Anmeldedaten aus dem Tresor ab und entschlüsselt sie auf dem Gerät. Der Klartext existiert nur für einen einzigen HTTP-Request im Prozessspeicher, danach ist er verschwunden. Nichts wird zwischengespeichert. Nichts wird auf die Festplatte geschrieben. Jede Anfrage wird frisch entschlüsselt.
Zuordnung von Feldern zu Headern
Bearer-Token, API-Schlüssel, Basic-Auth — der Proxy ordnet Tresor-Feldbezeichnungen automatisch den richtigen HTTP-Headern zu. Oder der Agent wählt das exakte Feld mit einer clavitor://-Referenz aus. In beiden Fällen landen die Anmeldedaten an der richtigen Stelle, ohne dass der Agent sie jemals sieht.
Scopes, Ratenbegrenzung, Audit
Der Tresor erzwingt Scope-Grenzen und Ratenbegrenzungen. Ein Agent, der auf zu viele verschiedene Anmeldedaten zugreift, wird automatisch gesperrt. Jeder Zugriff wird protokolliert. Integrieren Sie eine Agenten-ID in den Platzhalter — clavitor://agentid@Entry/field — für agentenspezifische Audit-Pfade und Ratenbegrenzungen über einen gemeinsam genutzten Proxy hinweg.
Bereitstellung
Eine Binärdatei. Als Sidecar zum Agenten. Keine Änderungen an der Netzwerkinfrastruktur.
Single-Agent Host
Laden Sie die Binärdatei herunter, führen Sie clavitor-proxy init mit dem Enrollment-Token aus und setzen Sie HTTPS_PROXY beim Agenten. Fertig. Standardmäßig bindet der Proxy an 127.0.0.1:1983 (Sidecar für einen Agenten); setzen Sie CLAVITOR_PROXY_LISTEN, um ihn anderweitig zu binden, wenn ein Proxy mehrere Agenten in einem privaten Netzwerk bedient.
Multi-Agent Host
Jeder Agent erhält seine eigene Kopie der Binärdatei mit einer eigenen Sidecar-Konfigurationsdatei. Jede Kopie hat ihren eigenen Scope, ihre eigenen Ratenbegrenzungen und ihren eigenen Audit-Pfad. Agent A kann die Anmeldedaten von Agent B nicht sehen. Isolation durch Design.
Jeder Credential Proxy, der in der Cloud läuft — ob Ihrer oder der eines anderen — ist ein Ziel. Brechen Sie den Proxy auf, erhalten Sie die Anmeldedaten jedes Kunden. Das ist kein theoretisches Risiko. Das ist das Geschäftsmodell jedes "Credential-Proxy-as-a-Service".
Der Clavitor Proxy läuft auf Ihrer Infrastruktur. Er entschlüsselt lokal. Die Anmeldedaten existieren nur für die Dauer einer Anfrage im Prozessspeicher. Es gibt keinen Cloud-Dienst, der Ihre Schlüssel im Klartext hält. Es gibt keinen API-Endpunkt, der Ihre Geheimnisse bereitstellt. Es gibt nichts, was man angreifen könnte.
Ihre Agenten führen bereits API-Aufrufe aus.
Halten Sie sie in ihrer eigenen Spur.
Ihr Tresor, Ihre Scopes, Ihr Audit-Pfad. Der Proxy fügt einen Durchsetzungspunkt auf der Netzwerkschicht hinzu, ohne dass Code am Agenten geändert werden muss.