Sie haben die Arbeit auf dreizehn Agenten verteilt. Paperclip hat den Schlüssel nicht aufgeteilt.

Sie haben die moderne Variante gewählt. Statt eines großen Agenten haben Sie eine Flotte aufgesetzt — einer für die Ticket-Triage, einer für Texte, einer für die Design-Pipeline, ein Dutzend insgesamt, jeder mit eigener Aufgabe und eigener Konfiguration. Das fühlt sich sicherer an. Kleinerer Schadensradius. Mehr Least-Privilege.

Dann durchlief ein Sicherheits-Scan die Konfigurationen eines Agenten-Frameworks namens Paperclip mit 71.000 Sternen und stellte fest, dass zwölf seiner dreizehn Agenten dieselben Zugangsdaten mit sich führten — einen identischen Token, in Klartext in die Konfiguration jedes Agenten eingefügt [1]. Ein Anthropic-API-Schlüssel lag unmaskiert in der Konfiguration eines Design-Agenten. Ein Bot-Token, das für einen einzigen Agenten gedacht war, war für Agenten lesbar, die damit nichts zu tun hatten.

Dreizehn Türen. Ein Schlüssel, in zwölf davon kopiert. Stehlen Sie ihn dem schwächsten Agenten, und Sie haben die anderen elf.

Was tatsächlich passiert ist

Paperclip gibt jedem Agenten eine MCP-Serverkonfiguration — die Datei, die dem Agenten sagt, welche Tools und Dienste er erreichen kann und wie er sich dort authentifiziert. Irgendwann sind die Geheimnisse als buchstäblicher Text in diese Dateien geraten: ein n8n-JWT, ein Bearer-Token, ein Anthropic-API-Schlüssel. Nicht referenziert. Nicht zur Laufzeit injiziert. Eingetippt — und dann, weil das Aufsetzen des nächsten Agenten aus Kopieren und Einfügen besteht, über die ganze Flotte dupliziert.

Der Scan meldete drei Dinge. Die gemeinsamen Klartext-Tokens über zwölf Agenten hinweg (bewertet HIGH). Der Anthropic-Schlüssel im Klartext in der Konfiguration eines Design-Agenten (bewertet CRITICAL). Und ein Bot-Token mit einem zu weit gefassten Geltungsbereich für Agenten, für die es nie gedacht war — ein klarer Verstoß gegen Least-Privilege [1]. Das Paperclip-Team hat schnell reagiert: Umstellung auf Credential-Referenzen, Maskierung der Konfiguration bei leseübergreifenden Zugriffen zwischen Agenten, und erzwungener Binding-Sync [2]. Die richtige Richtung.

Das ist keine Nachlässigkeit von Paperclip

Der Teil, über den es sich nachzudenken lohnt, ist dieser: Paperclip hat genau das getan, was fast jedes Framework tut. Ein Geheimnis in eine Konfigurationsdatei zu legen, ist die Art, wie Software sich seit dreißig Jahren authentifiziert. Es hat funktioniert, weil es eine Anwendung gab, eine Konfiguration und einen Betreiber, der wusste, wo der Schlüssel lag.

Unter dieser Gewohnheit hat sich die Epoche geändert. Ein Multi-Agenten-System ist nicht eine Anwendung mit einer Konfiguration — es sind ein Dutzend Prozesse, jeder mit einer Datei, jede eine Kopie der vorherigen. Klartext-in-der-Config war ein verkraftbarer Shortcut, solang es nur eine Stelle gab, an der etwas austreten konnte. Bei dreizehn Stellen bedeutet derselbe Shortcut, dass ein Leck dreizehn Lecks ist — und die Frage „welcher Agent hat das getan?“ hat keine Antwort, weil der Token im Protoll allen gehörte.

Credential-Referenzen — der Fix, den Paperclip ausgeliefert hat — sind tatsächlich besser. Aber beachten Sie, was sie ändern und was nicht. Eine Referenz löst sich weiterhin zu einem echten Geheimnis an der Stelle auf, an der der Agent läuft; der Agent, oder alles, was ihn kompromittiert, kann den aufgelösten Wert weiterhin lesen. Und der eigene Fehlertracker des Frameworks zeigt bereits den nächsten Ausfallmodus: eine Referenz, die aus der Bindung heraus driftet, sodass die Konfiguration gefüllt aussieht, während die Validierung stillschweigend fehlschlägt [3]. Das Geheimnis ist eine Ebene nach hinten gerückt. Verlassen hat es das Gebäude nicht.

Es betrifft nicht nur Paperclip

Selbe Woche, selbe Ursache, andere Repos. Ein weit verbreiteter Coding-Agent wurde gemeldet, weil er rohe .env-Werte — Passwörter, Tokens, API-Schlüssel — direkt in seine Chat-Ausgabe schrieb. Ein anderer Agent-Runner gab seine vollständige Umgebung des übergeordneten Prozesses an Subprozesse weiter, sodass jeder Provider-Schlüssel für einen Kindprozess sichtbar war [4]. Ein Sprach-Hook schrieb Transkripte mitsamt Zugangsdaten in weltlesbares /tmp [5]. Unabhängige Teams, unabhängige Bedrohungsmodelle, eine gemeinsame Annahme: dass es in Ordnung ist, wenn das Geheimnis dort liegt, wo der Agent es sehen kann. Ein Angreifer muss nur argumentieren, dass das eben nicht in Ordnung ist.

Bewusst dafür gebaut

Clavitor geht von der gegenteiligen Annahme aus: Der Agent hält die Zugangsdaten niemals selbst. Er fordert eine Aktion an; die Anfrage wird abgefangen, gegen ein Geheimnis authentifiziert, das der Agent nicht lesen kann, und ausgeführt. Es gibt keine Config, in die man einen Token einfügt, weil es keinen Token in der Config gibt. Nichts, was sich über dreizehn Agenten kopieren ließe, weil die Umgebung des Agenten nie das enthält, was sich zu stehlen lohnt.

Jeder Agent erreicht nur das, wofür er benannt wurde — nicht den gesamten Tresor —, sodass ein Bot-Token nicht für einen Agenten lesbar werden kann, der ihn nie angefordert hat. Und jede Aktion wird dem konkreten Akteur zugeordnet, der sie ausgeführt hat, nie einem gemeinsamen Token, den zwölf Agenten teilten — sodass die Frage „welcher war es?“ eine Antwort hat.

Der ehrliche Vorbehalt: Das macht einen Agenten nicht unhackbar. Ein kompromittierter Agent kann weiterhin im Moment genau die Dinge tun, für die er autorisiert wurde. Was er nicht kann, ist mit dem Schlüssel verschwinden und zu den anderen zwölf werden — denn es gibt keinen Schlüssel in seinen Händen, mit dem er verschwinden könnte.

Die Lehre ist nicht „Token rotieren“

Paperclip wird die Tokens rotieren, die Migration abschließen und die Issues schließen. Gut — das sollte man auch. Aber die Rotation ist nicht die Lehre. Die Lehre ist, dass „das Geheimnis liegt in der Config“ in dem Moment, in dem Sie eine Flotte von Agenten statt einer Anwendung betreiben, aufhört, ein Shortcut zu sein, und zum Multiplikator wird. Einen Multiplikator beheben Sie nicht, indem Sie das Geheimnis etwas schwerer lesbar machen. Sie beheben ihn, indem Sie sicherstellen, dass das Geheimnis nie in die Hände des Agenten gelangt ist.

Wir haben die Regeln aufgeschrieben, die ein Werkzeug für Zugangsdaten aus unserer Sicht in der Agenten-Ära einhalten sollte — darunter, dass das Geheimnis nie dort liegt, wo der Code läuft, und dass ein Agent nur das erreicht, wofür er benannt wurde. Prüfen Sie Ihre eigene Lösung daran: clavitor.ai/rules.

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

Quellen

[1] Paperclip agent framework — credential hygiene findings (CFG-H1 shared plaintext tokens, CFG-C1 hardcoded Anthropic key, CFG-H2 mis-scoped bot token): https://github.com/paperclipai/paperclip

[2] Paperclip — enforce agent secret-binding sync across lifecycle flows (merged): https://github.com/paperclipai/paperclip/pull/8307

[3] Paperclip — secret_ref env entries can drift from secret_bindings rows, config appears populated but validation fails silently (#8309): https://github.com/paperclipai/paperclip/issues/8309

[4] Chetter — runBatchAgent inherits full runner environment, exposing provider API keys to the subprocess (#56): https://github.com/flatout-works/chetter/issues/56

[5] Claude Code voice hook — full transcripts (credentials included) written to world-readable /tmp (#58): https://github.com/rodlaneedu-hash/claude-code-voice-hook/issues/58