Die gesamte Branche hat sich gerade darauf geeinigt, dass Ihr Agent Ihre Schlüssel nicht sehen darf. Sie verstecken sie am falschen Ort.

Diese Woche hat Anthropic eine unauffällige Zeile im Claude Code Changelog veröffentlicht: "Fixed MCP servers requiring authentication exposing auth-stub tools to the model in headless/SDK mode" [1]. In Klartext — wenn Claude Code im Headless-Modus lief (so wie in CI und automatisierten Agenten-Pipelines), wurden Authentifizierungs-Tools, die eigentlich verborgen bleiben sollten, dem Modell offengelegt: Die KI konnte die Namen der Auth-Tools sehen, ihre Parameter und konnte sie womöglich bedienen. In dem meistgenutzten Coding-Agenten der Welt — 133.000 Sterne — sickerte die Zugangsdatenebene genau dorthin, wo man sie am wenigsten will: in den eigenen Kontext des Modells.

Der Fehler wurde behoben. Aber die Korrektur ist die kleine Geschichte. Die große lautet: Warum kämpft plötzlich jedes ernstzunehmende Agenten-Harness denselben Kampf?

Drei Harnesses, eine Woche, derselbe Instinkt

Sehen Sie sich an, was in einem einzigen 24-Stunden-Fenster ausgeliefert wurde:

• Claude Code hat das oben genannte Auth-Stub-Leck geflickt und die MCP-Authentifizierungsprüfung verschärft [1].
• Hermes (v0.17.0) hat „Managed Scope" eingeführt — vom Admin festgeschriebene, für den Benutzer unveränderliche Geheimnisse, die auf Dateisystemebene gesperrt sind, damit ein Agenten-Betreiber sie nicht überschreiben kann — dazu Geheimnis-Redaktion in Debug-Ausgaben und die Blockierung von exfiltrationsverdächtigen MCP-Konfigurationen, bevor sie starten [2].
• Codex (v0.141.0) hat die Remote-Ausführungs-Verkehrströme in verschlüsselte Noise-Kanäle gehüllt und begonnen, Plugins nach ihrem Authentifizierungsmodus zu routen [3].

Drei Konkurrenten, drei Ansätze, eine gemeinsame Schlussfolgerung: Das Harness muss die Geheimnisse besitzen, und der Agent darf die Schlüssel im Klartext nie sehen. Wenn Wettbewerber in derselben Woche so konvergieren, ist das kein Trend. Das ist eine Kategorie, die endlich zugibt, wofür sie da ist.

Das nächste Problem ist die Zugangsdaten-Streuung

Hier liegt der Haken. Jede dieser Korrekturen lebt innerhalb des Harness. Und der Claude Code-Fehler verrät es: Wenn die Authentifizierung im Harness lebt, direkt neben dem Modell, hört „der Agent darf es nie sehen" auf, eine Tatsache zu sein, und wird zu einer Eigenschaft, die Sie fortlaufend konstruieren müssen — und gelegentlich verfehlen, im Headless-Modus, wo kein Mensch zuschaut. Sie können sie nicht einmal deklarieren. Sie verteidigen sie, Release für Release.

Aber das tiefere Problem ist nicht irgendein einzelnes Leck — es ist das, was passiert, wenn jedes Harness, jeder Anbieter und jeder Anwendungsfall seine eigene Antwort ausliefert. Am Ende haben Sie einen Tresor in Claude Code, einen Tresor in Hermes, einen Tresor in Codex, hier einen OAuth-Pool, dort eine Geheimnisdatei — einen eigenen Zugangsdatenspeicher für jedes Werkzeug, das Sie betreiben. Das ist Zugangsdaten-Streuung, und sie ist das nächste Problem, kein gelöstes.

Streuung ist das Versagen, selbst wenn keines der Silos leckt. Ihre Geheimnisse werden in jedes davon kopiert, damit es funktioniert — mehr Kopien, mehr Orte zum Stehlen. Rotation muss N-mal erfolgen, manuell, und die, die Sie vergessen, ist die, die Sie verbrennt. Und niemand kann die einzige Frage beantworten, die wirklich zählt — welcher Agent hat welchen Schlüssel wofür und wann benutzt —, weil die Antwort über ein Dutzend Speicher verstreut ist, die nicht miteinander sprechen. Sie können für jeden Anbieter und jeden Workflow nicht jeweils einen neuen Tresor aufsetzen. Das skaliert nicht. Es ist das, was bricht.

Die Schlüssel gehören überhaupt nicht ins Harness

Die Korrektur, die Sie nie ausliefern müssen, ist die, bei der der Agent die Authentifizierung von vornherein nicht hält. Legen Sie die Zugangsdaten in eine Instanz, die außerhalb jedes Harness sitzt — nicht ein Tresor pro Anbieter, sondern einer unterhalb von allen. Der Agent — in Claude Code, in Codex, in Hermes, das spielt keine Rolle — fragt eine benannte Aktion an und bekommt dafür ein begrenztes, flüchtiges Zugangsdaten-Objekt injiziert, live geholt und danach wieder entfernt. Es gibt keinen Auth-Stub im Kontext des Modells, der versehentlich offengelegt werden könnte, weil die Authentifizierung nie im Harness war. Es gibt keine Streuung, weil es einen Speicher statt eines pro Werkzeug gibt — einmal rotieren statt N-mal. Und jeder Zugriff landet auf einer einzigen Audit-Spur, statt sich über ein Dutzend Silos zu verteilen, die nicht beantworten können, wer was benutzt hat. (Das Geheimnis aus dem Ort herauszuhalten, an dem der Code läuft, steht weit oben auf den Regeln, die ein Werkzeug für Zugangsdaten einhalten sollte — die Branche hat genau das gerade eine Woche lang herausgefunden.)

Und hier geht es um eine Sicherheitsgrenze, nicht um Komfort: Das Zugangsdaten-Objekt darf nicht im selben System leben wie der Agent. Bringen Sie beide zusammen, und sie teilen sich einen Explosionsradius — eine Prompt-Injektion, ein vergifteter MCP-Server, eine gemeinsame Debug-Ausgabe, der nächste Auth-Stub-Fehler, und was den Agenten erreicht, erreicht die Schlüssel mit. Deshalb ist Sichtbarkeit allein schon der Bruch: Sobald ein Geheimnis an einem Ort landet, an dem der Agent es sehen kann, behandeln Sie es als bereits kompromittiert und rotieren es — so wie jedes sorgfältige Team diesen Claude Code Auth-Stub am Tag seiner Veröffentlichung behandelt hat. Halten Sie das Zugangsdaten-Objekt auf Abstand, in einem System, das der Agent nur anfragen kann — nie lesen, nie halten —, und ein vollständig kompromittierter Agent kann immer noch nicht exfiltrieren, was nie in seiner Reichweite war. Er kann eine Aktion anfragen. Er kann den Schlüssel nicht mitgehen lassen. Die Distanz ist die Verteidigung; ein Tresor im Prozess hat sie zu keinem Preis.

Das ist die Grenze, die Clavitor zieht. Das gesamte Feld hat das Prinzip gerade bewiesen — der Agent sollte die Schlüssel nicht sehen. Wir meinen nur, dass Sie es nicht innerhalb jedes Harness, das Sie betreiben, erneut beweisen sollten. Und wir meinen, dass das Ding, das Ihre Schlüssel hält, nicht dasselbe sein sollte, das ein Angreifer gerade kompromittiert hat.

Geben Sie den Harness-Teams ihr Recht: vom Admin festgeschriebene Geheimnisse, verschlüsselte Relais, Standardwerte, die im Fehlerfall schließen — das ist echte, gute Technik. Aber eine Korrektur der Woche für ein Leck, das immer wieder auftaucht, ist keine Architektur — es ist ein Symptom. Die Architektur ist, dass die Schlüssel nicht da sind, um zu lecken.

Wenn drei Konkurrenten dieselbe Wunde in derselben Woche flicken, ist die Wunde das Design. Der Agent sollte Ihre Schlüssel nicht sehen — also hören Sie auf, sie dort aufzubewahren, wo er sie sehen kann.

Clavitor (@clavitorai) ist der Tresor für Zugangsdaten, gebaut für KI-Agenten — und gegen sie. clavitor.ai

Quellen

[1] Claude Code v2.1.183 — „Fixed MCP servers requiring authentication exposing auth-stub tools to the model in headless/SDK mode" — https://github.com/anthropics/claude-code/releases/tag/v2.1.183

[2] Hermes Agent v0.17.0 — Managed Scope (vom Admin festgeschriebene Geheimnisse), Geheimnis-Redaktion, Blockierung von Exfiltrations-Konfigurationen — https://github.com/NousResearch/hermes-agent/releases

[3] OpenAI Codex v0.141.0 — verschlüsselte Noise-Relais-Kanäle, Plugin-Routing nach Authentifizierungsmodus — https://github.com/openai/codex/releases