Ein KI-Coding-Agent führte printenv aus, um ein Deployment zu debuggen, und brachte damit ein aktives AWS-Session-Token in sein Context Window. Niemand hat etwas falsch gemacht. Deshalb haben wir ctxcop gebaut, ein Open-Source-CLI-Tool, das Secrets aus dem Agentenkontext entfernt, bevor das Modell sie sieht.
Ihr KI-Coding-Agent braucht Ihre Zugangsdaten nicht, um seinen Job zu machen. Wir haben einen CLI-Hook gebaut, der aufhört, sie weiterzugeben, und ihn als Open Source veröffentlicht.
Vor ein paar Monaten habe ich zugesehen, wie ein KI-Coding-Agent ein fehlgeschlagenes Deployment debuggte. Er führte printenv aus, was ich auch getan hätte. Das Problem: printenv gab auf dieser Maschine ein aktives AWS-Session-Token aus. Dieses Token landete im Context Window des Modells, dann im Konversationstranskript, das im Klartext auf dem Laptop lag, und schließlich auf dem Computer von jemand anderem. Es hätte genauso leicht auch in einem ganzen Haufen von Logs landen können.
Niemand hat etwas falsch gemacht. Der Agent war hilfreich, und die Engineerin war produktiv. Ein Produktions-Credential landete einfach dort, wohin es niemand von uns bewusst geschickt hatte.
Das ist der ganze Grund für diesen Beitrag.
Der Reflex
Wenn ein mächtiges neues Tool auftaucht, ist die reflexhafte Security-Reaktion, es einzusperren. Eine Policy schreiben, es im Handbuch verbieten, es über ein Review-Board leiten. Es fühlt sich wie Kontrolle an.
Das ist es nicht. Engineers haben KI-Coding-Agenten schneller übernommen als jedes andere Tool, das ich gesehen habe, und zwar unabhängig davon, ob Security zugestimmt hat. Verbieten Sie das Tool, bekommen Sie keine Sicherheit. Sie bekommen dieselbe Credential-Exposition, nur außerhalb eines sanktionierten Workflows, und ein Security-Team, das davon nichts mehr sieht. Sie verlieren Produktivität und Sichtbarkeit gleichzeitig.
„Dagegen" war also nie wirklich die gewinnende Seite. Was funktioniert, ist, das Tool dort abzuholen, wo es läuft, und die Sicherheitsvorgabe direkt darin einzubauen.
Need to know
Die Sicherheitsvorgabe stammt aus einer alten Idee: Need to know.
Ich möchte hier vorsichtig mit der Behauptung sein, denn die laute Version dieser Geschichte ist falsch. Ich sage nicht, dass man Anthropic oder OpenAI (oder Deepinfra et al.) nicht vertrauen kann. Die meisten Anbieter sind vertraglich solide, und mehrere von ihnen trainieren nicht auf Ihrem Kontext. Aber sie haben trotzdem Logs, manchmal an mehreren Stellen, aus mehreren Gründen, bei mehreren ihrer eigenen Vendors. Nein, meine Behauptung ist kleiner und schwerer zu widerlegen: Man sollte keinem Dritten mehr Informationen geben, als er zur Erledigung der Aufgabe braucht. Niemand muss in böser Absicht handeln, damit das eine Rolle spielt. Den Wirkungsradius klein zu halten, ist einfach gute Praxis, und das Context Window eines Coding-Agenten ist ein neuer Ort, um das zu üben.
Ein Agent muss über Ihren Code und die Welt, in der dieser Code läuft, nachdenken können. Dafür braucht er nicht den literalen Wert Ihres Datenbank-Passworts. Er braucht die Form des Problems, nicht das Secret. Also haben wir aufgehört, ihm das Secret zu geben.
Ein Cop für das Context Window
Das ist ctxcop, kurz für „context cop" (Kontext-Polizist).
Es ist ein einfaches CLI-Tool, das sich in jeden Agenten installiert, den Sie nutzen: Claude Code, Cursor, Codex, Pi, OpenCode, Aider, was auch immer wir alle morgen nutzen. Es hakt sich an den Momenten ein, in denen ein Secret von Ihrer Maschine in den Kontext des Modells übergehen könnte. Wenn der Agent einen Befehl ausführt, eine Datei liest oder ein Tool aufruft, sieht sich ctxcop die Ausgabe an, bevor das Modell sie sieht, und ersetzt alles, was wie ein Credential aussieht:
Das Modell bekommt einen Platzhalter, wo das Secret war. Der Befehl lief trotzdem mit dem echten Wert in Ihrer Shell. Das Modell hat es einfach nie gesehen. Nichts verlässt Ihre Maschine. Es gibt keinen Proxy oder Gateway zum Betreiben und kein Konto zu erstellen. Sie führen ctxcop install aus, es findet Ihre Agenten und klinkt sich ein. Es ist Open Source unter MIT-Lizenz, denn blinder Glaube ist immer der falsche Schritt, wenn man mit Secrets arbeitet.
Die Schwärzung ist nur die halbe Miete. Wenn ctxcop ein Secret entfernt, hinterlässt es dem Agenten auch eine Notiz: Das war ein Credential, wir haben es entfernt, und wenn du den Wert brauchst, referenziere ihn indirekt. Es briefet den Agenten auch am Anfang einer Session, damit die Konventionen später keine Überraschung sind. So bekommt der Agent keinen rätselhaften Platzhalter und fängt an zu raten. Er versucht nicht, die Schwärzung base64-zu-dekodieren oder den Befehl erneut auszuführen, um an das Original zu kommen. Er wird darüber informiert, was passiert ist, und arbeitet weiter.
Dieser Teil ist bewusst so gestaltet: Wir versuchen nicht nur, nicht mehr gegen unsere Entwickler:innen zu kämpfen, wir versuchen auch, nicht mehr gegen den Agenten zu kämpfen. Eine Sicherheitsvorgabe, die die Eingaben eines Agenten still verstümmelt, ist eine, die er irgendwann lernt zu umgehen. Erklärt sich ein Tool stattdessen selbst, kann der Agent damit kooperieren.
Keiner der schwierigen Teile (das tatsächliche Auffinden von Secrets) stammt von uns. ctxcop baut auf betterleaks auf, dem gepflegten Nachfolger von gitleaks, und ohne ihn wäre dieses Projekt ein riesiger Schmerz zum Bauen gewesen. Wir bekommen seine gesamte Detection-Engine und das Regelwerk kostenlos. Worauf wir uns noch mehr stützen, ist, wie erweiterbar es ist. Die Regeln sind einfach Config, sodass Sie unsere verschärfen, Muster für Ihre eigenen internen sensiblen Daten hinzufügen oder ein ganzes Zusatzpaket mit einer einzigen Umgebungsvariable laden können. Genau so liefert ctxcop ein optionales Crypto- und Finanz-PII-Regelwerk aus: standardmäßig aus, eine Variable zum Einschalten. Ihre Secrets sind nicht unsere Secrets, und betterleaks macht es einfach, das auch so zu handhaben.
Wie es funktioniert
Jedes Harness hat seinen eigenen Ansatz zur Erweiterbarkeit, das variiert also von Harness zu Harness. Details finden Sie unter https://github.com/webflow/ctxcop/blob/main/docs/harnesses.md, aber schauen wir uns beispielhaft die Hooks von Claude Code an:
Bei SessionStart lenkt ctxcop den Agenten, indem es ihm über hookSpecificOutput.additionalContext eine Präambel gibt, die Claude mitteilt, dass ctxcop in die Session eingehakt ist, wie ein geschwärztes Muster aussieht und was zu tun ist, wenn es auf eines trifft.
Wenn der Agent sich entscheidet, das Bash-Tool zu nutzen, hakt sich ctxcop in PreToolUse ein und schreibt den geplanten Befehl des Agenten um:
cat .env ⇒ ctxcop run -- bash -c 'cat .env'
Wenn ctxcop einen Befehl umschließt, durchsucht es stdout und schwärzt gemäß den Regeln, mit denen es konfiguriert ist, wobei genug übrig bleibt, damit der Agent darüber nachdenken kann, zusammen mit einer Erinnerung, wie man mit Secrets arbeitet, ohne den Kontext zu verschmutzen:
Es gibt mehrere weitere Oberflächen für Claude Code: Fügt eine Nutzerin ein Secret in den Prompt ein, liest der Agent eine Datei oder nutzt MCP-Server, hakt sich ctxcop auch in diese Ereignisse ein und achtet dabei darauf, den Wert der Operation zu erhalten, während es die Vertraulichkeit dort wahrt, wo es möglich ist.
Was es nicht tut
Ein Security-Tool, das sich selbst übertreibt, ist schlimmer als kein Tool, also hier, was ctxcop nicht tut.
Es arbeitet auf Content-Ebene. Es schwärzt, was das Modell sieht. Es ist keine Firewall, kein Egress-Proxy und kein Verhaltensmonitor. Es stoppt keine SSRF. Es weiß nichts von, und kümmert sich nicht um, ein vergiftetes MCP-Tool oder eine langsame, mehrstufige Exfiltration. Das sind echte Probleme, und sie liegen auf einer anderen Ebene. ctxcop steht neben einer Netzwerk-Egress-Kontrolle, es ersetzt keine.
Pipelock und Runlayer sind gute Beispiele für diese andere Ebene. Sie arbeiten auf dem Netzwerk statt auf der Sicht des Modells darauf, und setzen am Egress-Punkt durch statt auf Ihrer Maschine. Das ist ein anderes Betriebsmodell mit eigenen echten Vorteilen, und es lohnt sich wirklich, einen Blick darauf zu werfen. Die Leute hinter Pipelock veröffentlichen auch einen externen, herstellerneutralen Benchmark namens agent-egress-bench. Wir haben die Teile davon ausgeführt, die auf ctxcop zutreffen, und die Ergebnisse ins Repo gestellt, einschließlich jeder Kategorie, die wir nicht abdecken. Wenn Sie wissen wollen, wo die Grenzen liegen, sind sie dokumentiert.
Damit arbeiten
Ich denke, so sieht es aus, wenn ein Security-Team rund um ein neues Tool erwachsen wird, statt sich davor aufzubauen.
Die Agenten verschwinden nicht, und der Druck auf jeden Engineer, sie zu nutzen, auch nicht. Die Aufgabe von Security ist nicht, die Abteilung des „Nein" zu sein, sondern Sicherheit in die Workflows der Nutzer:innen einzubauen. Ein Tool sicher zu benutzen, sollte einfach, intuitiv und klar darin sein, wo die Risiken liegen.
ctxcop ist eine Sicherheitsvorgabe für eine Grenze. Es ist offen und live unter github.com/webflow/ctxcop. Lesen Sie es, führen Sie es aus, und sagen Sie uns, ob es Ihnen hilft, nachts besser zu schlafen.
