Credential Proxy
Ihre Agents führen API-Aufrufe durch.
Sie sollten niemals die Schlüssel besitzen.
Clavitor Proxy sitzt zwischen Ihren KI-Agents und den APIs, die diese aufrufen. Anmeldeinformationen 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 Agents lesen OPENAI_API_KEY aus der Umgebung. Dieser Schlüssel ist in /proc, in Absturzabbildern, in CI-Protokollen und in jedem Werkzeug sichtbar, das der Agent aufruft. Eine kompromittierte 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-Injektion, ein Debug-Dump – der Schlüssel liegt offen da.
Keine Prüfung, was verwendet wurde
Wenn ein API-Schlüssel als Zeichenkette weitergegeben wird, gibt es keine Aufzeichnung darüber, welcher Agent ihn wann oder wofür verwendet hat. Wenn der Schlüssel durchsickert, rotieren Sie ihn und hoffen das Beste. Es gibt keine forensische Spur.
Die Probleme, die Sie hoffentlich nicht haben
API-Schlüssel im Quellcode
Fest kodiert in einer Konfigurationsdatei, in Git committet, von jedem Entwickler und CI-Runner im Team geklont. Ein öffentlicher Fork – und er ist im Secret-Scanning-Dashboard von GitHub sichtbar. Oder schlimmer noch: er ist es nicht.
Anmeldeinformationen in Slack
„Können Sie mir den Stripe-Schlüssel schicken?" In einer Direktnachricht eingefügt, für immer durchsuchbar, in jedem Compliance-Archiv exportiert. Slack ist kein Tresor. E-Mail, Google Docs oder ein Haftzettel am Monitor auch nicht.
.env-Dateien auf jedem Laptop
Zwölf Entwickler, zwölf Kopien von Produktionsanmeldeinformationen in Klartextdateien, die niemals rotiert werden. Ein gestohlener Laptop, ein Leak in ~/.bash_history, ein übermäßig hilfreiches Backup-Tool – und Sie rotieren um 2 Uhr morgens jeden Schlüssel im Unternehmen.
Entfernen Sie Anmeldeinformationen vollständig vom Agenten.
Der Proxy sitzt zwischen dem Agenten und der API. Der Agent schreibt eine Referenz – clavitor://OpenAI/key – an die Stelle, an die das Geheimnis gehört. Der Proxy löst sie lokal auf, injiziert die tatsächliche Anmeldeinformation in die HTTPS-Anfrage und leitet sie weiter. Die Protokolle des Agenten zeigen den Platzhalter. Die API empfängt den Schlüssel. Nichts dazwischen speichert ihn.
Keine Umgebungsvariablen. Keine Geheimnisse im Speicher. Keine Anmeldeinformationen auf der Kommandozeile. Der Agent kennt den Schlüssel nicht, kann ihn nicht preisgeben und kann nicht dazu gebracht werden, ihn 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 durchführt: Claude Code, Codex, OpenClaw, CrewAI, LangChain, benutzerdefinierte Skripte. Setzen Sie eine Umgebungsvariable, und die API-Aufrufe des Agenten laufen 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üsselte Anmeldeinformation aus dem Tresor ab und entschlüsselt sie auf dem Gerät. Der Klartext existiert für eine HTTP-Anfrage im Prozessspeicher – dann ist er weg. Nichts wird zwischengespeichert. Nichts wird auf die Festplatte geschrieben. Jede Anfrage wird neu entschlüsselt.
Ordnet Felder Headern zu
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 landet die Anmeldeinformation an der richtigen Stelle, ohne dass der Agent sie jemals sieht.
Scopes, Ratenbegrenzungen, Audit
Der Tresor erzwingt Scope-Grenzen und Ratenbegrenzungen. Ein Agent, der auf zu viele verschiedene Anmeldeinformationen zugreift, wird automatisch gesperrt. Jeder Zugriff wird protokolliert. Fügen Sie eine Agenten-ID in den Platzhalter ein – clavitor://agentid@Entry/field – für Audit-Trails pro Agent und Ratenbegrenzungen über einen gemeinsamen Proxy.
Deployment
Eine Binärdatei. Sidecar zum Agenten. Keine Änderungen an der Netzwerkinfrastruktur.
Einzelner Agenten-Host
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 eine andere Adresse zu binden, wenn ein Proxy mehrere Agenten in einem privaten Netzwerk bedient.
Multi-Agenten-Host
Jeder Agent erhält seine eigene Kopie der Binärdatei mit seiner eigenen Sidecar-Konfigurationsdatei. Jede Kopie hat ihren eigenen Scope, ihre eigenen Ratenbegrenzungen und ihren eigenen Audit-Trail. Agent A kann die Anmeldeinformationen von Agent B nicht einsehen. Isolation per Design.
Jeder Credential Proxy, der in der Cloud läuft – der eigene oder der eines Drittanbieters – ist ein Angriffsziel. Wer den Proxy kompromittiert, erhält die Anmeldeinformationen aller Kunden. Das ist kein theoretisches Risiko. Es ist das Geschäftsmodell jedes Credential-Proxy-as-a-Service.
Clavitors Proxy läuft auf Ihrer Infrastruktur. Entschlüsselung erfolgt lokal. Die Anmeldeinformation existiert für die Dauer einer Anfrage im Prozessspeicher. Es gibt keinen Cloud-Dienst, der Ihre Klartextschlüssel vorhält. Es gibt keinen API-Endpunkt, der Ihre Geheimnisse ausliefert. Es gibt nichts zu kompromittieren.
Ihre Agents führen bereits API-Aufrufe durch.
Halten Sie sie in ihrer Zuständigkeit.
Ihr Tresor, Ihre Scopes, Ihr Audit-Trail. Der Proxy fügt einen Durchsetzungspunkt auf Netzwerkebene hinzu – ohne Codeänderungen am Agenten.