KI-Agenten Zugangsdaten: Secrets technisch schützen statt vertrauen

Ein Softwareentwickler richtet einen Coding-Agenten ein und bestätigt eine Rückfrage mit dem bequemen Klick. Keine Woche später liegt in seinem öffentlichen GitHub-Repository eine Konfigurationsdatei mit einem gültigen API-Schlüssel. Er hat nichts falsch gemacht, was auf den ersten Blick auffällt. Er hat nur eine Funktion genutzt, die genau dafür gedacht war, ihm Klicks zu sparen. Dass daraus ein öffentlich erreichbarer Zugangsdatensatz wurde, sieht niemand in seinem Team.

In diesem Artikel erfährst du, wie KI-Agenten diese Woche für Schlagzeilen gesorgt haben, warum das kein Anfängerfehler ist, sondern ein Systemmuster, warum Regeln im Prompt gegen solche Risiken nicht tragen, und mit welchen fünf Bausteinen du Zugangsdaten und Agentenrechte technisch absicherst.

---

Inhaltsverzeichnis

1. Der Vorfall: Zugangsdaten im öffentlichen Repository
2. Warum das ein Muster ist, kein Ausrutscher
3. Guardrails reichen nicht
4. Fünf Bausteine für Secrets und Rechte
5. Umsetzung in sieben Tagen
6. Fazit

---

Der Vorfall: Zugangsdaten im öffentlichen Repository

heise online hat am 9. November 2026 über eine Analyse des IT-Sicherheitsunternehmens Apiiro berichtet. Die Forscher haben mehr als 100.000 öffentlich auf GitHub abgelegte Kopien einer Claude-Code-Konfigurationsdatei untersucht und in 1.105 davon echte Geheimnisse gefunden. In der Gesamtschau fanden sie 2.539 echte Zugangsdaten in 1.994 öffentlichen Repositories: Datenbankpasswörter, Cloud-Schlüssel, API-Token und SSH-Root-Logins. Weitere 1.160 Geheimnisse steckten in der Git-Historie, in einer von Teams absichtlich geteilten Einstellungsdatei sowie in Agent-Chat-Transkripten, die jemand mit abgelegt hatte. In 539 der betroffenen Repositories gab es einen Commit, in dem der Agent selbst als Mitautor die Datei verändert hatte.

Die Ursache ist unspektakulär und genau deshalb lehrreich. Ein Coding-Agent fragt bei Zugriffen auf eine Datenbank oder eine API nach, ob der vorgeschlagene Befehl ausgeführt werden soll, und bietet die Option an, künftig nicht mehr zu fragen. Der ausgeführte Befehl enthält die Zugangsdaten. Wählt man die Option zur Bequemlichkeit, landen diese Zugangsdaten in einer lokalen Einstellungsdatei im Projektordner. Eigentlich soll diese Datei nie das Entwicklerrechner verlassen, und das Werkzeug trägt sie auch in die Git-Ignore-Liste ein. Das funktioniert aber nicht, wenn ein Ordner erst später zu einem Repository wird, wenn er von einer anderen Maschine geklont wurde oder wenn jemand die Datei bereits committet hat. Dann ist die Regel wirkungslos und die Datei ungeschützt.

Apiiros Rat ist bewusst in dieser Reihenfolge formuliert: Suche deine GitHub-Organisation und die Git-Historie nach diesen beiden Dateinamen ab, tausche gefundene Zugangsdaten zuerst aus, und räume erst danach auf. Wer zuerst löscht, hat ein geleaktes Geheimnis, das weiter gültig ist. Der Leiter von Claude Code hat inzwischen angekündigt, dass sein Team prüft, wie sich der Fall technisch abfangen lässt.

Warum das ein Muster ist, kein Ausrutscher

Es wäre beruhigend, das als Werkzeugproblem abzutun. Es ist keins. Ein zweiter Bericht dieser Woche zeigt die Gegenrichtung. GitGuardian hat am 9. November 2026 etwa 45 Open-Source-Frameworks katalogisiert, die ein Sprachmodell in eine Schleife einbinden, die Werkzeuge ausführt und auf deren Ausgaben reagiert. Vier davon bringen einen Secret-Scanner mit, der gezielt nach Zugangsdaten auf öffentlichem GitHub sucht. Nach der Analyse von Microsoft konnten Angreifer mit einem dieser Werkzeuge ausgeleitete Zugangsdaten in weniger als fünf Minuten dazu nutzen, in eine Azure-Umgebung zu gelangen.

Das heißt nicht, dass dein Mittelständler Ziel eines gezielten Angriffs wird. Es heißt, dass die Werkzeuge, die nach vergessenen Zugangsdaten suchen, automatisiert und billig geworden sind. Ein Geheimnis, das versehentlich öffentlich liegt, ist nicht mehr lange ein Geheimnis. Die Katalogisierung für die Suchmaschine Shodan fand allein in der Werkzeugfamilie um das inzwischen abgeschaltete Framework ARTEX am 7. November 2026 insgesamt 1.428 erreichbare Dienste im offenen Netz. Ein Teil dieser Werkzeuge ist ohne jede Anmeldung erreichbar, wenn man sie unbedacht betreibt.

Für dich ist die Lehre doppelt. Erstens: Ein Agent, dem du Zugangsdaten gibst, kann sie weitergeben, und zwar an einen Ort, den du nicht kontrollierst. Zweitens: Die Gegenseite sucht mit denselben Mitteln, mit denen du arbeitest.

Guardrails reichen nicht

Ein zweiter Artikel von heise online, ein Hintergrundbeitrag zur Architektur von KI-Agenten im Backoffice, benennt das Kernproblem präziser als jede Werkzeugdiskussion. Die Autoren beschreiben einen realistischen Betrugsfall. Ein Agent überwacht das Postfach der Buchhaltung, erhält eine Mail von einem bekannten Absender mit der Bitte um eine Änderung der Bankverbindung, klassifiziert sie korrekt als Stammdatenänderung, erkennt die Dringlichkeit, ruft das Werkzeug zur Änderung auf, und die nächste Zahlung geht statt an den Lieferanten an einen Betrüger im Ausland. Jeder einzelne Schritt war für sich plausibel.

Der naheliegende Reflex ist ein schärferer Prompt, eine zusätzliche Regel, ein besserer Hinweis an den Agenten. Genau dort liegt der Denkfehler. Regeln im Prompt, im Fachjargon Guardrails, steuern das Verhalten, aber sie erzwingen es nicht. Das Modell interpretiert die Anweisung, es befolgt sie nicht wie ein Programm eine Bedingung. Widersprüchliche Vorgaben, Fehlinterpretationen oder manipulierte Eingaben können ihre Wirkung aushebeln. Der Beitrag ordnet das den vier Risiken zu, die die OWASP für LLM-basierte Systeme und Agenten in ihren Top-10-Listen für 2026 führt:

Prompt Injection. Versteckte Anweisungen in Mails, Dokumenten oder Webseiten manipulieren das Verhalten. Eine Lieferantenanfrage kann im Kleingedruckten die Anweisung enthalten, ein anderes Konto zu verwenden.

Excessive Agency. Der Agent hat mehr Rechte, als seine Aufgabe verlangt. Wer Rechnungen prüft, braucht nicht das Recht, Zahlungen auszulösen.

Agent Goal Hijack. Nicht eine einzelne Aktion wird manipuliert, sondern das übergeordnete Ziel. Eine Kette plausibler Schritte führt dazu, dass der Agent im Interesse des Angreifers handelt, ohne dass ein Alarm auslöst, weil jeder Einzelschritt erklärbar wirkt.

Memory and Context Poisoning. Wer gezielt Inhalte in das Langzeitgedächtnis eines Agenten schleust, beeinflusst spätere Entscheidungen dauerhaft. Das kennen wir aus dem Betrieb: Wenn Agenten sich erinnern, erinnern sie sich auch an Falsches.

Die Schlussfolgerung der Autoren ist der wichtigste Satz der Woche für jeden, der Agenten produktiv betreibt: Ein System, das kritische Handlungen grundsätzlich zulässt, steht in einem Wettrennen mit kreativen Angreifern. Wer das verhindern will, muss das System so bauen, dass der Fehler gar nicht erst entstehen kann. Guardrails sind Verhaltenssteuerung. Technische Kontrollen sind Grenzen. Wie eng Rechte und Freigaben gesetzt sein müssen, haben wir in KI-Agenten mit Rechten und Freigaben steuern aufgeschlüsselt, hier geht es um die Zugangsdaten und die technische Durchsetzung.

Fünf Bausteine für Secrets und Rechte

Du brauchst dafür keine Security-Abteilung. Du brauchst fünf Gewohnheiten, die sich in einem normalen Mittelstandsbetrieb einführen lassen.

Baustein 1: Keine Zugangsdaten im Kontext. Ein Geheimnis gehört nie in einen Prompt, nie in ein Konfigurationsfile im Projektordner und nie in ein Chat-Transkript. Werkzeuge lesen Zugangsdaten zur Laufzeit aus einem Secret-Store oder aus einer Umgebungsvariable, niemals aus dem, was der Agent selbst sieht. Wenn ein Agent eine Datenbankabfrage ausführen soll, gibt ihm das System den Zugriff, nicht der Text in seiner Anweisung.

Baustein 2: Eigene Identität je Agent, kurzlebige Tokens. Jeder Agent bekommt eine eigene technische Identität statt eines gemeinsam genutzten Kontos. Noch besser sind Tokens, die nach einer Stunde ablaufen. Dann ist ein ausgeleitetes Token nach kurzer Zeit wertlos, und im Protokoll steht, welcher Agent gehandelt hat. Das ist derselbe Grundsatz wie bei Rechten, nur konsequent auf Zugangsdaten angewendet.

Baustein 3: Rechte so eng wie die Aufgabe. Prüfe für jeden Agenten die Frage, was er wirklich braucht. Ein Rechnungsprüfer braucht Leserechte und vielleicht das Recht, einen Datensatz zu markieren, aber nicht das Recht, Zahlungen auszulösen. Diese Trennung ist der wirksamste Schutz gegen den Betrugsfall aus dem heise-Beitrag, weil der Agent den kritischen Schritt gar nicht ausführen kann, selbst wenn eine manipulierte Mail ihn dazu bringen will.

Baustein 4: Sichtbarkeit nach außen. Ein Agent, der mit deinen Zugangsdaten auf fremde Systeme zugreift, muss protokolliert werden. Wer hat wann welches Werkzeug mit welchem Token aufgerufen? Bei einem Agenten mit Netzzugriff gehört zusätzlich eine Ausgangskontrolle dazu: Ein Werkzeug, das plötzlich versucht, Daten an eine unbekannte Adresse zu senden, ist ein Warnsignal, kein normaler Vorgang. Angriffswerkzeuge wie die aus dem GitGuardian-Bericht laufen genau dann durch, wenn niemand auf Ausgänge schaut.

Baustein 5: Erkennen und rotieren. Suche deine Repositories und deren Historie systematisch nach bekannten Dateinamen und Schlüsselmustern ab, etwa mit einem Secret-Scanner. Wenn du etwas findest, gilt die Reihenfolge aus dem Apiiro-Bericht: erst den Zugangsdatensatz ungültig machen und ersetzen, dann die Datei aus dem Repository und der Historie entfernen. Und weil ein Agent auch im Betrieb ein Geheimnis in ein Protokoll schreiben kann, gehören Zugangsdaten in Logs maskiert, nicht im Klartext. Wer ein ausgeleitetes Credential erst nach dem Aufräumen rotiert, hat die Lücke nur versteckt, nicht geschlossen.

Umsetzung in sieben Tagen

Das lässt sich in einer Woche aufsetzen, ohne den Betrieb zu stoppen.

Tag 1: Bestandsaufnahme. Liste alle Agenten und Automatisierungen auf, die mit Zugangsdaten arbeiten. Für jeden Eintrag notierst du zwei Dinge: Wo liegen die Zugangsdaten, und welche Rechte haben sie?

Tag 2: Repositories prüfen. Lass einen Secret-Scanner über deine GitHub-Organisation laufen, inklusive Historie. Prüfe zusätzlich gezielt auf Einstellungsdateien, die Agenten anlegen. Jeden Treffer behandelst du nach Baustein 5.

Tag 3: Zugangsdaten aus dem Kontext ziehen. Alles, was im Klartext in einem Prompt, einem Konfigurationsfile oder einem Workflow-Node steht, wandert in einen Secret-Store oder in eine Umgebungsvariable. Prüfe nach dem Umbau, dass jeder Lauf weiter funktioniert.

Tag 4: Rechte verkleinern. Nimm dir den Agenten mit den weitesten Rechten vor und entziehe alles, was er für seine Aufgabe nicht zwingend braucht. Beginne mit dem Recht, Zahlungen oder Stammdaten zu verändern. Ein n8n-Workflow ist hier dein Vorteil: Rechte lassen sich an einen einzigen Freigabe-Node binden, den du zentral scharf schaltest.

Tag 5: Kurzlebige Tokens und Protokollierung. Wo dein Zielsystem es erlaubt, stelle auf zeitlich begrenzte Tokens um. Ergänze für jeden Werkzeugaufruf eine Protokollzeile mit Agentenname, Werkzeug und Zeitpunkt. Setze zusätzlich die Maskierung von Zugangsdaten in Logs durch.

Tag 6: Ausgangskontrolle. Für Agenten mit Netzzugriff definierst du eine Liste erlaubter Ziele. Alles, was nicht darauf steht, wird blockiert und gemeldet. Das ist derselbe Baustein, der in einem Notfall das Schlimmste verhindert, siehe KI-Agenten Notbremse.

Tag 7: Übung und Kalendereintrag. Teste einmal, wie lange es dauert, einen Zugangsdatensatz zu finden, zu rotieren und zu prüfen. Setze danach einen wiederkehrenden Termin im Quartal an. Und vergiss den unsichtbaren Kanal nicht: Zwei Agenten mit Zugriff auf dasselbe System können über dieses System indirekt miteinander kommunizieren, ohne dass du es beabsichtigt hast. Warum das ein eigenes Risiko ist, steht in KI-Agenten-Kollusion über Nebenkanäle.

Praxistipp: Rotiere Zugangsdaten sofort und automatisch, sobald ein Scanner anschlägt, und behandle jeden Fund so, als wäre er bereits ausgenutzt worden. Die Minute Verzögerung beim Nachdenken ist billiger als die Woche Aufräumen danach.

Fazit

Diese Woche hat zwei Seiten desselben Problems gezeigt. Auf der einen Seite leiten Agenten Zugangsdaten dorthin aus, wo sie nicht hingehören, ohne dass jemand einen Fehler bemerkt. Auf der anderen Seite stehen automatisierte Werkzeuge bereit, die genau solche Geheimnisse suchen und innerhalb von Minuten ausnutzen. Dazwischen steht die Versuchung, das Problem mit einem schärferen Prompt lösen zu wollen. Das funktioniert nicht, weil ein Prompt das Verhalten lenkt, aber keine Grenze setzt.

Der wirksame Weg ist unspektakulär: Geheimnisse nie in den Kontext, eigene Identität je Agent, Rechte so eng wie die Aufgabe, Sichtbarkeit nach außen, und beim Fund sofort rotieren. Wer diese fünf Punkte hat, kann einen Betrugsversuch wie die manipulierte Bankverbindung abweisen, weil der Agent die kritische Handlung technisch nicht ausführen kann. Wer sie nicht hat, verlässt sich auf ein Sprachmodell an einer Stelle, an der ein Programm stehen müsste.

Der erste Schritt ist heute machbar und dauert keine Stunde: ein Secret-Scanner über deine Repositories. Diese Woche hat gezeigt, wie viel dabei oft zum Vorschein kommt. Wie wir Agenten mit eigenem Secret-Store, Freigabepunkten und Ausgangskontrolle betreiben, steht auf der Seite zum B.R.A.I.N. KI-System.

Über MadeByBrain: Wir bauen KI-Automatisierung für den Mittelstand, eigene AI-Agenten, n8n-Workflows und GEO-Strategien, live im Einsatz. Von der ersten Idee bis zur produktiven Automatisierung.

Jetzt kostenloses Strategiegespräch vereinbaren →