When "Do Not" Is Not Deny: Security Rules in CLAUDE.md vs Built-In Controls

In der modernen Welt der Softwareerstellung ist eine neue Art von Helfer entstanden: der Coding-Agent. Dies sind Programme der künstlichen Intelligenz, die Code schreiben, Fehler beheben und Dateien verwalten können, genau wie ein menschlicher Entwickler. Um diese digitalen Assistenten sicher und auf dem richtigen Weg zu halten, schreiben Entwickler Instruktionsdateien. Betrachten Sie diese Dateien als eine Sammlung geschriebener Regeln, ähnlich einem Rezept oder einem Verhaltenskodex, in dem ein Mensch dem Agenten sagt, was er tun darf und was er niemals tun darf. Ein Entwickler könnte schreiben: „Speichere niemals Passwörter im Klartext“ oder „Frage nach, bevor wichtige Daten gelöscht werden.“ Jahrelang war diese Methode der Anweisungsgebung der Standardweg, um diese intelligenten Werkzeuge zu steuern. Die Annahme war, dass der Agent die Regel verstehen und befolgen würde, wenn man sie klar formuliert, wodurch eine sichere Umgebung für die entwickelte Software geschaffen wird.

Ein kürzlich durchgeführter Bericht der Forscherin Ting Yan offenbart jedoch eine stille, aber bedeutende Lücke in diesem System. Die Forschung konzentriert sich auf einen spezifischen Typ von Instruktionsdatei, die bei einem populären Coding-Agenten namens Claude Code verwendet wird. Die Studie stellt eine einfache, aber kritische Frage: Wenn ein Entwickler eine Sicherheitsregel in natürlichem Englisch schreibt, verfügt die Software dann tatsächlich über einen eingebauten Mechanismus, um diese Regel durchzusetzen, oder ist die Regel nur ein Vorschlag, bei dem die künstliche Intelligenz raten muss, wie sie zu folgen ist? Die Ergebnisse legen nahe, dass für die überwältigende Mehrheit dieser geschriebenen Regeln Letzteres der Fall ist. Die Datei fungiert als Einbahnstraße, auf der der Entwickler spricht, das System aber niemals bestätigt, ob die Regel durchgesetzt wird. Dies erzeugt eine falsche Sicherheit, bei der ein Entwickler glaubt, eine gefährliche Aktion sei blockiert, während das System in Wirklichkeit nur darauf vertraut, dass die künstliche Intelligenz sich an die Anweisung erinnert und ihr gehorcht, ohne dass eine harte Sperre implementiert ist.

Um das Ausmaß dieses Problems zu verstehen, sammelten die Forscher fast fünfhundert öffentliche Instruktionsdateien von Entwicklern aus der ganzen Welt. Sie behandelten diese Dateien wie eine Sammlung handgeschriebener Notizen und scannten sie Zeile für Zeile nach Sätzen, die wie Sicherheitsregeln klangen. Sie suchten nach Phrasen wie „darf nicht“, „niemals“ oder „nicht tun“, die eine Einschränkung signalisieren. Aus diesen Dateien extrahierten sie tausende Regelkandidaten. Der nächste Schritt bestand darin, als Übersetzer zwischen der menschlichen Sprache der Regel und der technischen Sprache der Software zu fungieren. Sie fragten sich, ob der spezifische Coding-Agent, Claude Code, bereits einen eingebauten Schalter oder eine Einstellung besitzt, die die beschriebene Aktion automatisch blockieren könnte. Wenn zum Beispiel eine Regel besagte „führe diesen spezifischen Befehl nicht aus“, prüften die Forscher, ob die Software über eine Berechtigungseinstellung verfügte, die diesen Befehl einfach verweigern könnte, bevor er überhaupt stattfindet. Wenn die Software keinen solchen Schalter hatte, wurde die Regel der künstlichen Intelligenz zur Interpretation überlassen, was bedeutete, dass der Agent selbst entscheiden musste, ob er der Anweisung folgt.

Die Ergebnisse dieses Vergleichs waren drastisch. Wenn die Forscher einen strengen Standard anlegten – mit der Anforderung, dass die eingebaute Kontrolle exakt die Aktion, das exakt Ziel und die exakt Bedingung der geschriebenen Regel abdecken muss –, besaß nur ein winziger Bruchteil der Regeln einen passenden Sicherheitsmechanismus. Konkret fanden sie heraus, dass nur etwa vier bis sechs Prozent der von Entwicklern geschriebenen Sicherheitsregeln durch eine eingebaute Kontrolle gedeckt waren, die sie ohne zusätzliche Arbeit durchsetzen konnte. Selbst wenn sie einen lockereren Standard anwandten, der Teilübereinstimmungen zuließ, stieg die Zahl nur auf etwa sechzehn Prozent. Das bedeutet, dass für etwa 95 Prozent der in diesen Dateien geschriebenen Sicherheitsregeln es kein automatisches Sicherheitsnetz gab. Die Regel existierte nur als Text und verließ sich vollständig darauf, dass die künstliche Intelligenz sie jedes Mal korrekt interpretiert.

Die Studie untersuchte auch, warum so viele Regeln keinen Treffer fanden. Die Forscher stellten fest, dass die Regeln oft Dinge forderten, die die eingebauten Werkzeuge der Software schlichtweg nicht sehen oder tun konnten. Eine Regel könnte sagen: „Übertrage niemals Geheimnisse in den Code“, aber die Berechtigungseinstellungen der Software können einen Dateipfad oder einen Befehl blockieren, nicht aber den tatslichen Inhalt einer Datei. Um eine Regel über Geheimnisse durchzusetzen, müsste die Software die Datei lesen und verstehen, was darin enthalten ist – eine Aufgabe, die sie mit ihren Standardeinstellungen nicht bewältigen kann. Ähnlich könnte eine Regel erfordern, den Zustand eines Systems zu prüfen oder die Genehmigung einer bestimmten Person einzuholen – Details, auf die die eingebauten Kontrollen keinen Zugriff hatten. In diesen Fällen war die Regel kein Befehl, den die Software ausführen konnte; sie war eine Aufforderung an die künstliche Intelligenz, ihr Urteilsvermögen einzusetzen. Die Forscher merkten an, dass dieser Unterschied für den Entwickler unsichtbar ist. Die Instruktionsdatei sieht gleich aus, egal ob eine Regel durch eine harte System sperre oder durch das weiche, fehlbare Gedächtnis einer künstlichen Intelligenz durchgesetzt wird.

Dieser Mangel an Feedback erzeugt das, was die Forscher einen „Write-Only“-Kanal nennen. In der meisten Softwareentwicklung erhält ein Entwickler, wenn er eine Regel schreibt, sofortiges Feedback. Wenn er Code schreibt, der gegen eine Regel verstößt, könnte der Computer die Ausführung verweigern oder ein Test könnte fehlschlagen und ihn sofort darauf hinweisen, dass etwas nicht stimmt. Bei diesen Instruktionsdateien gibt es kein solches Signal. Ein Entwickler kann eine Regel schreiben, weitermachen und niemals erfahren, ob der Agent sie tatsächlich befolgt. Die Studie hebt hervor, dass dies besonders riskant für Entwickler ist, die neu im Bereich Sicherheit sind. Sie könnten eine Regel schreiben, in dem Glauben, ihr System gesichert zu haben, ohne zu realisieren, dass das System keine Möglichkeit hat, diese spezifische Einschränkung tatsächlich durchzusetzen. Die künstliche Intelligenz folgt der Regel zwar meistens, kann aber auch Fehler machen, verwirrt werden oder durch andere Eingaben getäuscht werden, was das System verwundbar macht.

Die Forscher fanden nicht heraus, dass die Software defekt sei oder die Entwickler etwas falsch machten. Stattdessen identifizierten sie einen Designfehler in der Art und Weise, wie diese Werkzeuge mit ihren Nutzern kommunizieren. Die Werkzeuge erlauben es Nutzern, Regeln in natürlicher Sprache zu schreiben, was einfach und intuitiv ist, aber sie teilen dem Nutzer nicht mit, welche dieser Regeln tatsächlich vom System durchgesetzt werden und welche lediglich Vorschläge sind. Die Studie legt nahe, dass diese Werkzeuge erst dann wirklich sicher sind, wenn sie diesen Kreislauf schließen. Sie müssen Entwicklern eine Möglichkeit bieten zu sehen, welche Regeln durch harte Kontrollen abgesichert sind und welche nicht. Idealerweise sollte die Software einen Entwickler warnen, wenn er eine Regel schreibt, die das System nicht durchsetzen kann, oder sie sollte ihm helfen, diese Regel in eine Einstellung umzuwandeln, die das System tatsächlich nutzen kann. Bis dieser Feedback-Kreislauf geschlossen ist, hängt die Sicherheit dieser Systeme stark von der Hoffnung ab, dass die künstliche Intelligenz jede Anweisung perfekt erinnert und befolgt – eine Hoffnung, die die Daten zeigen, oft unangebracht ist.

Die Studie schließt mit dem Hinweis, dass dies ein lösbares Problem ist, es aber eine Änderung in der Art und Weise erfordert, wie diese Werkzeuge gebaut werden. Die Lücke zwischen dem, was ein Entwickler schreibt, und dem, was das System durchsetzt, ist kein Mysterium; es ist eine messbare Tatsache. Durch die Messung haben die Forscher gezeigt, dass die derzeitige Art, diese Agenten zu sichern, unvollständig ist. Die Lösung liegt darin, das Unsichtbare sichtbar zu machen und sicherzustellen, dass ein Entwickler, wenn er eine Regel schreibt, genau weiß, welche Art von Schutz sie bietet. Dies würde die Instruktionsdatei von einer einseitigen Notiz in ein Gespräch auf zwei Wegen verwandeln, bei dem das System bestätigt, dass die Regeln nicht nur geschrieben, sondern tatsächlich wirksam sind.