Secret-Leak über den KI-Kontext

Was ist Secret-Leak über den KI-Kontext?

Ein agentenbasierter Coding-Assistent liest das Arbeitsverzeichnis, um Ihnen zu antworten, und schreibt in Artefakte, die Sie veröffentlichen. Hier hat er beim Debuggen eines Tests eine lokale Secret-Datei gelesen und den Live-Schlüssel anschließend in der Beschreibung eines Pull Requests zitiert, die öffentlich wurde. Sie suchen im Sitzungsprotokoll den Lesezugriff auf das Secret und den Schreibvorgang, der es nach draußen getragen hat, sehen, warum .gitignore das nicht verhindert hat, rotieren den offengelegten Schlüssel in der richtigen Reihenfolge und legen eine .aiignore an, damit der Assistent das Secret nicht mehr lesen kann.

Was Sie lernen in Secret-Leak über den KI-Kontext

• Beschreiben, wie ein agentenbasierter Assistent Dateien lesen kann, die ihm nie ausdrücklich übergeben wurden, weil er das Arbeitsverzeichnis liest, um seinen eigenen Kontext aufzubauen
• Erklären, warum .gitignore einen Assistenten nicht einschränkt: Die Datei regelt die Versionskontrolle, nicht, was der Assistent lesen darf
• Mit dem Sitzungsprotokoll und der Kontextkarte den Lesezugriff auf ein Secret und den Schreibvorgang finden, der es in eine öffentliche Ausgabe getragen hat
• Einen offengelegten Schlüssel in der richtigen Reihenfolge rotieren: zuerst den kompromittierten Schlüssel widerrufen, dann einen Ersatz ausstellen
• Den Dateizugriff eines Assistenten mit einer .aiignore begrenzen, damit Secrets nicht in seinen Kontext gelangen, und prüfen, dass der Lesezugriff blockiert wird

Secret-Leak über den KI-Kontext — Trainingsschritte

1. Ein Scanner-Treffer

   Bob lässt einen Scanner über öffentliche Code-Plattformen laufen. Heute Morgen hat er einen neuen Pull Request auf github.tullowick.dev gemeldet, in dessen Beschreibung etwas zitiert wird, das wie ein Live-Zahlungsschlüssel aussieht. Der Feed ist auf Bobs Bildschirm geöffnet. Sehen Sie ihn sich an.

2. Ein Live-Schlüssel, öffentlich einsehbar

   Der Feed hat den Schlüssel direkt aus der Beschreibung des Pull Requests gezogen. Er trägt das Live-Präfix und ist kein Platzhalter. Der Feed weist ihn als verifiziert aus, doch Bob will selbst sehen, was sich damit öffnen lässt.

3. Den Schlüssel einsetzen

   Ein Produktionsschlüssel ist ein Bearer-Token: Wer ihn hat, hat das Konto. Bob richtet den API Tester auf den Zahlungsendpunkt von Quellby und übergibt den Schlüssel in einem Authorization -Header. Ist der Schlüssel noch aktiv, liefert die Antwort die echten Buchungen des Kontos. Einbrechen muss dafür niemand. Ein veröffentlichter Schlüssel öffnet die Tür von selbst.

4. Der Alarm

   Das Sicherheitsteam von Quellby betreibt einen eigenen Secret-Scanner. Er hat denselben Schlüssel entdeckt und die Kontoinhaberin per E-Mail benachrichtigt.

5. Die Sitzung von gestern wieder öffnen

   Alice öffnet den Billing-Workspace in der Code-App. Gestern hat sie den Assistenten gebeten, den fehlschlagenden Billing-Test zu debuggen. Die vier Dateien, mit denen er gearbeitet hat, liegen hier, und seine Aufzeichnung der Sitzung wird geladen: die Dateien in seinem Kontext, die Schritte, die er ausgeführt hat, und die Zeilen, die er geschrieben hat.

6. Wo der Schlüssel gelesen wurde

   Das Sitzungsprotokoll zeigt die Sitzung von gestern als Zeitachse. Ein Ereignis ist markiert: Der Assistent hat .env.local gelesen, eine Secret-Datei, während er einen Test debuggte, der sie nie gebraucht hat. Suchen Sie es im Sitzungsprotokoll: die erste rote Markierung (Hotspot) in der Spur „read“ um 14:01:22, beschriftet mit .env.local .

7. Git ignoriert die Datei, der Assistent nicht

   Auf der Kontextkarte ist .env.local jetzt ausgewählt und als Secret markiert. Öffnen Sie auf der Karte die .gitignore : Die Secret-Datei ist dort eingetragen, Git erfasst sie also nie. Doch die .gitignore sagt nur der Versionskontrolle, was sie auslassen soll. Der Assistent liest das Arbeitsverzeichnis direkt, eine ignorierte Datei kann also trotzdem in seinem Kontext landen.

8. Wo der Schlüssel nach draußen gelangte

   Das Lesen des Secrets war nur die eine Hälfte. Das nächste markierte Ereignis im Sitzungsprotokoll ist eine Bearbeitung der Beschreibung des Pull Requests. Suchen Sie es: die zweite rote Markierung (Hotspot) in der Spur „edit“ um 14:01:58, beschriftet mit PR-218 description.md .

9. Eingefügt, nie geprüft

   Die PR-Beschreibung öffnet sich. Um den Abschnitt „Verifying locally“ anschaulich zu machen, hat der Assistent das Beispiel mit den echten Werten aus seinem Kontext gefüllt, einschließlich des Live-Schlüssels. Die Randleiste markiert diese Zeilen violett und gestrichelt: von Claude geschrieben und von keinem Menschen geprüft, bevor der PR öffentlich wurde.

10. Wie kam der Schlüssel nach draußen?