KRÖTZSCHKI-Blog · Ohne Bullshit
Newsletter

Suchergebnisse für: „Sicherheit“

  • KI-Coworker brechen das Sicherheitsmodell, das für KI-Agenten noch funktionierte

    KI-Coworker brechen das Sicherheitsmodell, das für KI-Agenten noch funktionierte

    Man stelle sich einen Massenexport von Kundendaten im Audit-Log vor, ausgeführt unter dem Konto eines Entwicklers – kein Einbruch, kein geleaktes Passwort, keine fremde IP. Ein KI-Agent hat die Zugangsdaten dieses Entwicklers benutzt und genau das getan, wozu er beauftragt war. Mit KI-Systemen, die dauerhaft mitarbeiten, rückt dieses Szenario näher. Itamar Apelblat, Mitgründer und CEO des Sicherheitsanbieters Token Security, beschreibt den Wandel in einem von seiner Firma gesponserten Beitrag auf BleepingComputer als dritte Welle der arbeitsbezogenen KI.

    Seine These: Die ersten beiden Wellen ließen sich noch in bestehende Zugriffsmodelle einordnen. Die dritte nicht. Sobald KI-Systeme dauerhaft existieren, eigene Aufgaben verfolgen und über Monate hinweg Zugriff auf Daten und Infrastruktur behalten, verhalten sie sich weniger wie Werkzeuge und mehr wie Kollegen. Kollegen brauchen eine Identität. Wer verstehen will, warum die aktuellen Sicherheitsmodelle an dieser Stelle reißen, muss sich anschauen, woher sie kommen – und was sie stillschweigend vorausgesetzt haben.

    Drei Wellen, ein Muster: Vom Chatfenster zum Kollegen

    Die erste Welle waren sitzungsgebundene Chats. Das Risiko lag in dem, was das Modell sagt: Halluzinationen, Datenlecks in der Antwort, unbedachte Formulierungen. Die Branche antwortete mit Prompt-Filtern, Guardrails und Klassifizierung von Ausgaben – Werkzeuge, die auf Text schauen. Die zweite Welle brachte aufgabenbezogene Agenten. Hier verschob sich das Risiko von der Aussage zur Handlung. Plötzlich ging es nicht mehr darum, was ein Modell behauptet, sondern was es tatsächlich tut: welche API es aufruft, welche Datei es schreibt, welchen Datensatz es verschiebt. Die Antwort darauf waren Zugriffskontrollen und Freigabeprozesse. Ein Mensch muss vor der heiklen Aktion nicken.

    Genau dort stehen die meisten Unternehmen heute. Apelblat hält das für eine Momentaufnahme. Die Torpfosten, so seine Argumentation, wurden bereits weitergeschoben, und die dritte Welle steht unmittelbar bevor: dauerhaft existierende KI-Coworker, die nicht für eine einzelne Aufgabe starten und danach verschwinden, sondern bleiben. Ein Indiz findet er in der Wortwahl der Anbieter. Microsoft spricht von Agenten als „digitalen Kollegen“, Sam Altman skizzierte die Vision virtueller Mitarbeiter bereits im Februar 2025. Vokabular ist keine technische Spezifikation, aber es verrät, wohin die Produkte führen sollen.

    Für das Sicherheitsmodell bedeutet das einen Bruch. Man kann sich das mit dem Firmenausweis vorstellen: Ein heutiger Agent borgt sich den Ausweis eines Menschen, benutzt ihn eine Weile und gibt ihn danach zurück. Ein persistenter Coworker gibt ihn nie zurück. Er behält ihn, arbeitet weiter, sammelt neue Berechtigungen – und ist irgendwann mit einem Zugriffsprofil unterwegs, das niemand bewusst entworfen hat.

    Warum Persistenz aus einem Werkzeug einen Mitarbeiter macht

    Freigabe für Freigabe funktioniert nur, solange jemand da ist, der freigeben kann. Ein Coworker, der nachts, am Wochenende oder parallel in zwanzig Threads arbeitet, kann nicht für jede einzelne Aktion auf einen Menschen warten. Für Apelblat folgt daraus: Zugriff muss vorab bereitgestellt werden, gepaart mit der Möglichkeit, bei Bedarf zusätzliche Rechte anzufordern. Das ist ein anderes Modell als die ereignisgesteuerte Einzelfreigabe, die heute als sicherer Standard gilt.

    Dazu kommt, dass Identitäten speziell für KI-Agenten bislang die Ausnahme sind. Der Normalfall sieht anders aus: OAuth-Grants, Übergaben innerhalb einer Sitzung und Service-Accounts. Bei den ersten beiden Varianten ist der Mensch die primäre Entität, auch wenn der Agent handelt. Der Service-Account wiederum wurde selten für einen Agenten geschaffen, sondern meist für eine andere Maschine und dann zweckentfremdet. In allen drei Fällen fehlt genau das, was ein dauerhafter Coworker bräuchte: eine eigene, klar umrissene Identität mit dokumentiertem Zweck.

    Persistenz erzeugt zusätzlich Standing Privileges, also dauerhaft bestehende Berechtigungen, die einfach da sind, ob genutzt oder nicht. Bei Menschen ist das ein altbekanntes Problem, das niemand sauber gelöst hat. Bei Maschinen wird es ärger. Ein digitaler Kollege braucht einen Lebenszyklus, der das Deprovisioning ausdrücklich einschließt: Was passiert, wenn das Projekt endet, das Team aufgelöst wird oder die verantwortliche Person das Unternehmen verlässt? Wer diese Frage beim Anlegen nicht beantwortet, baut einen Zugang, den niemand mehr kontrolliert.

    Verschärft wird das durch Access Creep. Wer lange genug im Unternehmen ist, sammelt Rechte – das ist der älteste ungelöste Fall der Identity Governance. Für Maschinen rechnet Apelblat mit einer schlimmeren Dynamik, aus zwei Gründen: Zugriff akkumuliert sich schneller, und Agenten nutzen tendenziell alles, was sie bekommen. Mehrere für sich genommen vernünftige Einzelberechtigungen können zusammen eine Reichweite ergeben, die niemand beabsichtigt hat. Der Schlüsselbund wächst nicht durch böse Absicht, sondern durch Gleichgültigkeit gegenüber dem, was schon dranhängt.

    Was die großen Plattformen heute tatsächlich ausgeben

    Praktisch heißt das: Die zwei am weitesten verbreiteten Agentenplattformen geben ihren Agenten derzeit keine eigenen Credentials. Nach Darstellung des Autors betreiben weder Anthropic noch OpenAI den OAuth-Client-Credentials-Grant in ihren gehosteten Chat-Produkten, und die Konnektoren von ChatGPT lehnen Service-Accounts sowie JWT-Assertions ab. Entwickler können einem Agenten über die APIs ein statisches Bearer-Token mitgeben. Das ist keine Identität, sondern ein Schlüssel ohne Namen.

    Die Folge ist kein theoretisches Risiko. Wenn ein KI-System unter den Rechten eines Menschen handelt, steht im Audit-Trail in der Regel der Mensch als Akteur. Die Protokolle werden dadurch unzuverlässig. Eine Untersuchung, die auf solchen Logs baut, kann nicht sauber unterscheiden, ob ein Mitarbeiter um drei Uhr nachts gehandelt hat oder ein Agent in seinem Namen. Attribution ist keine Formalität. Ohne sie lassen sich Sicherheitsvorfälle nicht aufklären.

    Zugleich belastet der Wunsch, den Menschen in der Schleife zu behalten, genau diesen Menschen. OAuth geht davon aus, dass jemand einen Zustimmungsbildschirm liest und eine feste Liste von Scopes absegnet. Agenten geben sich mit ihrer initialen Berechtigung selten zufrieden, sie entdecken Werkzeuge zur Laufzeit und wollen sie benutzen. Alle paar Minuten eine sensible Aktion zu bestätigen ist nervig und sicherheitsschädlich zugleich, denn Aufmerksamkeit ist eine endliche Ressource. Wer hundertmal klickt, klickt beim hundertundersten Mal ohne hinzusehen.

    Googles Chip und der Praxistest aus dem Podcast

    Die Anforderung ist real. Ein Blick auf die Menschen, die solche Produkte bauen, zeigt das. Tara Seshan, die bei OpenAI das Produkt für ChatGPT Work und Codex verantwortet, beschrieb in einem Podcast-Interview, was einen Agenten tatsächlich nützlich macht. Modellintelligenz sei nur ein Teil davon. Der Rest sei das, was sie als handfestes Alltagsgeschäft bezeichnete: Zugang zu Daten, Cloud-Infrastruktur und Verlässlichkeit. Ihr Vergleich: Man stellt jemanden ein und sperrt ihn dann in einen Raum ohne Google Docs, Slack und Unternehmensdatenbank. Dieser Kollege wird nicht wirksam sein. Ein isolierter Cloud-Agent, so ihr Argument, aus genau demselben Grund ebenso wenig.

    Seshan beschrieb außerdem, dass ihr Agent Unteragenten startet, um Arbeit zu parallelisieren, und eine nahe Zukunft, in der ihre Agenten und die ihrer Kollegen gemeinsam an Aufgaben arbeiten. Beide Richtungen sind plausibel. Beide setzen ein Identitätsmodell voraus, das es noch nicht gibt. Denn wenn der Agent einer Person Arbeit an den Agenten einer anderen Person übergibt, gehört das ausführende Credential dem Menschen, der die Kette irgendwann gestartet hat. Verantwortung und Ausführung fallen auseinander.

    Der Rückblick lohnt. Google hat 2024 auf der I/O einen Workspace-Agenten namens Chip vorgestellt, mit eigenem Workspace-Konto, zugewiesener Rolle, konfigurierten Berechtigungen und einem festen Zielkatalog. Chip trat Chaträumen bei und antwortete aus dem Verlauf, den er sehen durfte. Die damalige Workspace-Vizepräsidentin Aparna Pappu sagte, es sei noch viel Arbeit nötig, bevor solche virtuellen Teammitglieder produktreif seien. Chip blieb eine Demo. Ausgeliefert wurden stattdessen Agenten, die die Autorität eines Menschen erben – das Gegenteil des ursprünglichen Entwurfs.

    Fünf Schritte, die der Anbieter empfiehlt

    Aus dieser Analyse leitet Apelblat einen konkreten Katalog ab. Man muss ihn nicht übernehmen, aber als Prüfrahmen taugt er für jedes Unternehmen, das Agenten laufen hat oder laufen lassen will.

    Erstens: Schatten-Coworker finden. Ein Register erfasst nur die Agenten, an die jemand gedacht hat. Die anderen erkennt man an ihrem Authentifizierungsverkehr – an OAuth-Grants, API-Schlüsseln und Login-Mustern, die kein Mensch erklären kann.

    Zweitens: Jeder persistente Agent bekommt eine eigene Identität. Solange er sich als Mensch authentifiziert, kann keine nachgelagerte Kontrolle die beiden auseinanderhalten, und keine Untersuchung ordnet eine Aktion korrekt zu.

    Drittens: Ein menschlicher Eigentümer wird festgehalten. Verwaiste Agenten mit aktiven Credentials sind laut dem Autor die häufigste Quelle agentenbezogener Standing Privileges – Zugänge ohne Ansprechpartner, die niemand mehr hinterfragt.

    Viertens: Berechtigungen werden auf den Agenten zugeschnitten, nicht auf die Person, die ihn gestartet hat. Ein Agent, der Jira liest, sollte kein Token halten, das auch in den Cloud-Provider schreiben darf, nur weil der auslösende Entwickler zufällig beides durfte.

    Fünftens: Vorab festlegen, wann der Agent stirbt. Digitale Coworker sind nicht projektgebunden, aber deshalb nicht unsterblich. Bedingungen wie eine aufgelöste Teamstruktur, ein ausscheidender Eigentümer oder eine definierte Leerlaufzeit gehören in die Konfiguration, nicht ins Nachdenken danach.

    Was daraus folgt

    Nebeneinander gelegt ergibt sich ein Muster. In Welle eins lag das Risiko in der Ausgabe, die Antwort waren Filter und Guardrails. In Welle zwei verlagerte es sich auf Handlungen, die Antwort waren Zugriffskontrolle und Freigaben. In Welle drei verschwindet der Mensch aus der Schleife, während der Zugriff bestehen bleibt. Nicht die Autonomie allein macht die Sache unangenehm, sondern die Autonomie mit dauerhaften Rechten.

    Die Plattformanbieter haben begonnen zu reagieren. Microsoft liefert Entra Agent ID mit eigenständigen Agenten-Identitäten und einem benannten menschlichen Sponsor. Okta hat Agenten-Identitäten ins Universal Directory aufgenommen, mit kurzlebigen, begrenzten Tokens und einem Widerrufspfad. SailPoint und CyberArk haben vergleichbare Angebote. Der Haken ist strukturell: Jede dieser Lösungen sichert Agenten innerhalb der eigenen Umgebung. Wer plattformübergreifend arbeiten muss, findet den einzigen durchsetzbaren Kontrollpunkt bei der Identität, weil Identität den Zugriff auf jede einzelne Aktion regelt.

    Transparenz gehört dazu: Der zitierte Beitrag ist gesponserter Content des Anbieters Token Security und endet mit einem Produktaufruf. Die technische Analyse ist deshalb nicht falsch, aber sie ist nicht interessefrei. Wer die Empfehlungen umsetzt, sollte sie als Prüfliste lesen und nicht als Einkaufsliste – die fünf Schritte funktionieren unabhängig davon, welches Werkzeug am Ende darunter steht.

    Für dich und dein Team heißt das vor allem: Bestandsaufnahme vor Werkzeugauswahl. Wie viele Agenten authentifizieren sich in eurer Umgebung gerade mit den Zugangsdaten von Menschen? Wer ist der Eigentümer, und was passiert, wenn diese Person geht? Die Antworten darauf sind unangenehmer als jede Produktentscheidung – und genau daran zeigt sich, ob euer Sicherheitsmodell die dritte Welle übersteht. Ein Kollege bekommt einen Ausweis, bevor er eine Aufgabe bekommt. Für Maschinen sollte dieselbe Reihenfolge gelten.

    Quelle: bleepingcomputer.com

  • Microsoft Sicherheitslücke: Wie eine fehlende JWT-Prüfung 17 Billionen Datensätze erreichbar machte

    Microsoft Sicherheitslücke: Wie eine fehlende JWT-Prüfung 17 Billionen Datensätze erreichbar machte

    Wie kommt man ohne gültige Zugangsdaten an 17 Billionen Microsoft-Datensätze? Die Antwort führt zu einem internen Analytics-Dienst namens Titan und zu einer einzigen Prüfung, die dort nicht stattfand. Der Sicherheitsforscher, der unter dem Namen Faav auftritt, hat den Fall im September 2026 veröffentlicht. Er beschreibt darin eine Microsoft Sicherheitslücke, die ihn rund zehn Tage beschäftigt hat. Ausgangspunkt war ein automatischer Hinweis seines selbstgebauten KI-Werkzeugs Antares, das er als persönlichen Hackbot bezeichnet.

    Faav ist inzwischen 16 Jahre alt und arbeitet seit gut einem Jahr im Rahmen des Microsoft Bug Bounty Program. Microsoft habe vor der Veröffentlichung redaktionell in den Beitrag eingegriffen, Abschnitte und Abbildungen gekürzt und die Darstellung der Auswirkungen umformuliert, berichtet er. Die geschilderte Wirkung sei hypothetisch: Er habe keine Kundendaten und keine personenbezogenen Informationen ausgelesen, sondern die Schwachstelle über den offiziellen Weg gemeldet. Genau das ist der Kern einer koordinierten Offenlegung einer Microsoft Sicherheitslücke dieser Größenordnung.

    Die Titan API: ein interner Dienst mit offener Flanke

    Titan ist ein interner Microsoft Analytics Service. Über ihn lassen sich Datenbanken abfragen, virtuelle Datensätze definieren und Dashboards betreiben. Seine Weboberfläche liegt hinter einer Seite, die ohne Firmen-VPN keinen Zugang erlaubt, sodass der sichtbare Teil für Außenstehende verschlossen wirkt. Hier setzt eine Analogie an, die sich durch den ganzen Fall zieht: ein Hotel mit elektronischen Türschlössern, bei dem jedes Zimmer seinen eigenen Kartenleser besitzt, am Ende aber jede beliebige Karte jede Tür öffnet. Der Vordereingang war verschlossen, die Nebenpforte stand weit offen.

    Antares durchsuchte Microsoft-Subdomains und stieß auf einen separaten Endpunkt, der auf einen Azure Cloud Services Host auflöste. Dessen öffentlich erreichbare Swagger-Datei listete vier Routen auf, und drei davon verlangten laut Dokumentation eine Azure AD Bearer-Authentifizierung. Die Ausnahme war die Route /v2/Query, die zugleich rohe SQL-Abfragen entgegennahm. Dort begann die weitere Untersuchung. Ein Endpunkt, der beliebige Abfragen entgegennimmt und als einziger ohne dokumentierte Absicherung auskommt, ist ein naheliegender Startpunkt.

    Die Abfrage verlangte einen Wert namens tableName, doch Swagger lieferte keine Beispiele. Über archivierte Momentaufnahmen der Titan-Anmeldeseite aus dem Jahr 2023 und eine gespeicherte Superset-Konfiguration kamen 56 Tabellendefinitionen zum Vorschein, darunter ein Routing-Wert mit dem Namen TestData. Ein Test gegen die Live-API mit diesem Wert lief ohne Autorisierungsheader in ein 401 Unauthorized. Das bestätigte, dass es Zugangskontrollen gab – die Frage war nur, wie gründlich sie arbeiteten.

    Warum die JWT-Authentifizierung zur offenen Tür wurde

    Ein JSON Web Token besteht normalerweise aus drei durch Punkte getrennten Abschnitten: Header, Payload und Signatur. Die Signatur beweist, dass das Token tatsächlich von der erwarteten Stelle ausgestellt wurde und nicht nachträglich verändert worden ist. Wird nur der Inhalt geprüft und die Signatur ignoriert, lässt sich jedes beliebige Token selbst bauen – so wie ein Pförtner, der den Namen auf dem Ausweis liest, aber nie das Foto daneben anschaut. Die JWT-Authentifizierung wird damit zur bloßen Formalie.

    Titan gab bei der Prüfung nacheinander verschiedene Fehlermeldungen zurück: erst zur Mandantenzuordnung, dann zur Zielgruppe, dann zu einer Anwendungs-Allowlist und schließlich zu einer Nutzersuche. Faav änderte jedes Mal nur den Inhalt des Tokens und ließ die Signatur unverändert. Der Dienst akzeptierte die neuen Angaben trotzdem. Das war der entscheidende Hinweis darauf, dass die Signatur überhaupt nicht überprüft wurde.

    Anschließend ersetzte der Forscher das Token durch ein selbst gebautes, dessen dritter Abschnitt leer blieb. Ein normales Token endet auf drei gefüllte Segmente, das synthetische endete auf einen bloßen Punkt, weil die Signatur fehlte. Der Dienst nahm es dennoch an und führte die Abfrage aus. Damit war die interne Microsoft Analytics Service Sicherheitslücke im Kern nachgewiesen: nicht ein einzelner Fehler in einer Randfunktion, sondern die zentrale Vertrauensprüfung fehlte.

    Der Zufallstreffer mit dem Nutzernamen „admin“

    Der Nutzeranspruch im Token trägt üblicherweise einen Namen, der wie eine E-Mail-Adresse aussieht, weil er aus der Entra-Identität stammt. Antares testete über Tage hinweg Platzhalter, veröffentlichte Dienstaliase und Adressen im Mitarbeiterstil. Titan antwortete stets mit einer Meldung, dass kein passender Nutzer gefunden wurde. Das Token passierte also alle Authentifizierungsschichten, scheiterte aber an der lokalen Zuordnung.

    Faav überlegte, was das Backend mit dem Anspruch tatsächlich anstellt, und vermutete, dass der Wert als lokaler Anwendungsbenutzername verwendet wird. Er setzte statt einer E-Mail-Adresse schlicht admin ein und erhielt als Antwort die Zahl 1. Nach zehn Tagen voller Authentifizierungsfehler war das eine aussagekräftige Zahl, denn sie markierte den lokalen Benutzer mit der Administratorrolle. An diesem Punkt liefen unautorisierte SQL-Abfragen gegen Microsofts interne Analytik, und zwar mit den Rechten des höchsten lokalen Kontos.

    admin ist offensichtlich – und zugleich offensichtlich kein gültiger Wert für diesen Anspruch. Genau deshalb hatte das KI-Werkzeug ihn nie ausprobiert, weil es das Feld beim Wort nahm. Der Mensch dagegen hatte die Bedeutung des Feldnamens infrage gestellt und sich gefragt, was ein Entwickler im Backend wohl gebaut haben könnte. Manchmal ist die Antwort so einfach, wie sie aussieht.

    Was hinter der Tür lag: die 17 Billionen Microsoft Datensätze

    Zuerst probierte der Forscher die naheliegende Tabelle TestData und fand dort erwartungsgemäß Testfälle. Ein SHOW DATABASES zeigte jedoch die gesamte Landschaft, darunter die Plattform-Metadatenbank, aus der sich Anwendungstabellen direkt abfragen ließen. Dort fand sich eine Tabelle mit rund 25.000 aktiven Konten samt Namen, E-Mail-Adressen und Anmeldeverlauf, dazu 17.990 Mitarbeiter-E-Mail-Adressen, 15.001 Organisationsdatensätze, 355 Datenbankkonfigurationen und 20.979 virtuelle SQL-Definitionen. Hinzu kamen rund 24.600 Dashboards, über 425.000 Diagramme und knapp 27.400 Datensatzdefinitionen.

    Weil mehr als ein Datensatz dieselbe Kennung für Nutzer enthielt, wäre eine Verknüpfung von Aktivitäten über Dienste hinweg denkbar gewesen. Der Autor hat das nicht versucht. Stattdessen blieb er bei zwei Ein-Zeilen-Stichproben aus einer Bing-Analytik-Partition, um die Erreichbarkeit zu belegen, ohne Inhalte auszuwerten. Die enthaltenen Ortsangaben stammten aus Reverse-IP-Zuordnungen und beschrieben Länder oder Bundesstaaten, keine präzisen Aufenthaltsorte.

    Den Gesamtumfang ermittelte der Forscher zuletzt über die 56 Routing-Werte, von denen 30 noch aktiv waren. Diese 30 Werte führten über 24 Konfigurationen zu 17 verbundenen Analytik-Datenbanken mit 9.863 eindeutigen Tabellennamen. Über zwei Metadatenpfade zählte er je eine Replik pro Shard und kam auf eine Zahl, die er erst in Dreiergruppen gliedern musste, um sie lesen zu können: 17.333.335.124.315 Zeilen. Das ist eine Speicherschätzung aus Metadaten, die historische, duplizierte und abgeleitete Daten einschließen dürfte. Die Größenordnung bleibt bemerkenswert.

    Wenn KI rechnet und der Mensch kombiniert

    Antares hatte über zehn Tage hinweg Arbeit erledigt, die von Hand kaum zu leisten gewesen wäre: Subdomains aufzählen, die Fehlermeldungen der JWT-Prüfung Feld für Feld durchspielen, die Angriffsfläche kartieren und das unsignierte Token durch vier Prüfschichten bringen. Was das Werkzeug nicht schaffte, war der gedankliche Schritt, dass der Anspruch auf einen Nutzernamen keineswegs ein Nutzername sein musste. Der sture Optimierer blieb in seiner Annahme gefangen, weil er den Feldnamen wörtlich genommen hatte.

    Faav zieht daraus eine nüchterne Lehre: Das Werkzeug habe die Ausdauer geliefert, der Mensch den entscheidenden Einfall, und keine der beiden Seiten hätte allein zum Ziel geführt. Solche Schilderungen sind für den aktuellen Stand automatisierten Hackens aufschlussreich, weil sie nicht in Hype verfallen, sondern die Grenze klar benennen. Ein Werkzeug kann Tausende Varianten prüfen, aber es kann nicht den Kontext eines fremden Backends erraten.

    Bemerkenswert ist auch der Umgang mit dem Fund. Sobald die Mitarbeiterdatensätze sichtbar waren, begann der Forscher mit einem Bericht an das Microsoft Security Response Center; nach der Bing-Stichprobe meldete er sofort. Der Fall wurde unter der Nummer 144051 noch am selben Tag eröffnet, und Microsoft bat anschließend darum, weitere Tests einzustellen. Das Unternehmen lobt in seiner Antwort die koordinierte Offenlegung im Rahmen des Microsoft Bug Bounty Program und den Beitrag zum Schutz der Kunden.

    Was Entwickler und Unternehmen daraus mitnehmen sollten

    Die technische Lehre ist einfach und unbequem: Beim Bau von Authentifizierung ist die Signaturprüfung nicht eine Prüfung unter vielen, sondern die Grundlage, auf der alle anderen Kontrollen erst Sinn ergeben. Ein Dienst kann Mandant, Zielgruppe, Anwendungs-ID und Nutzer korrekt prüfen – doch wenn die Signatur fehlt, prüft er nur, ob jemand die richtigen Wörter kennt. Der gesamte Zugriffsschutz existierte in der Anwendung und wurde durch eine einzige unterlassene Prüfung entwertet.

    Für Entwicklerteams heißt das: bei jedem JSON Web Token zuerst die Signatur verifizieren, bevor irgendein Anspruch ausgewertet wird. Zusätzlich lohnt es, interne Feldnamen nicht als selbstverständlich zu behandeln. Wenn ein Wert als Nutzername dienen soll, sollte das Backend ihn auch als solchen behandeln und nicht als Identitätsadresse interpretieren. Solche Details entscheiden über Erfolg oder Misserfolg eines Angriffs, und sie lassen sich in Code-Reviews gezielt suchen.

    Viele Schwachstellen dieser Art bleiben unentdeckt, weil sich niemand die Mühe macht, einen öffentlichen Endpunkt systematisch abzuklopfen. Der Fall zeigt, wie viel ein einzelner nicht abgesicherter API-Pfad in einem ansonsten gut geschützten Umfeld freilegen kann. Wer in einem Bug-Bounty-Programm unterwegs ist, findet dort oft mehr Wirkung als im offensichtlichen Frontend. Für Microsoft ist der Vorgang eine Erinnerung, dass interne Werkzeuge mit Datenzugriff dieselbe Härte verdienen wie kundenseitige Dienste.

    Eine hypothetische Reichweite von 17 Billionen Zeilen klingt spektakulär. Entscheidend ist, dass niemand diese Zugänge ausgenutzt hat und die Lücke über die koordinierte Offenlegung geschlossen wurde. Der eigentliche Wert des Berichts liegt weniger in der Zahl als in der Lücke selbst. Ein signaturloses Token ist kein exotisches Randproblem, sondern ein wiederkehrendes Muster, das sich mit wenigen Codezeilen vermeiden lässt.

    Quelle: blog.faav.net

  • GLM-5.3 im Sicherheitscheck: Wenn offene Gewichte autonome Cyber-Exploits ermöglichen

    GLM-5.3 im Sicherheitscheck: Wenn offene Gewichte autonome Cyber-Exploits ermöglichen

    Ein KI-Modell, das Exploits selbstständig baut — wie gefährlich ist das? Anthropics Sicherheitsteam hat das im September untersucht. Im Mittelpunkt: GLM-5.3, das aktuelle Modell des chinesischen Anbieters Zhipu AI, das außerhalb Chinas als Z.ai firmiert. Das Ergebnis ist unangenehm. Das Modell baut funktionsfähige Angriffswerkzeuge, auf einem Niveau, das bis vor wenigen Monaten nur geschlossenen Spitzenmodellen zugetraut wurde. Der Unterschied liegt weniger in der Fähigkeit selbst als darin, wer sie nutzen darf.

    Ein Bild hilft, die Tragweite einzuordnen. Ein Modell mit offenen Gewichten ist wie ein Werkzeugkasten, bei dem der Bauplan mitgeliefert wird: Jeder kann ihn nachbauen, umschweißen und die eingebaute Sicherung ausbauen. Bei geschlossenen Modellen bleibt der Bauplan beim Hersteller, der Werkzeugkasten wird nur ausgeliehen und später wieder eingesammelt. Dieser Unterschied zieht sich durch den ganzen Bericht über GLM-5.3. Die Autoren Andrew Fasano, Marius Fleischer, Cole McFaul, Robert Xiao und Tripp Gallagher beschreiben nicht nur, was das Modell kann, sondern auch, wie leicht sich seine Schutzmechanismen entfernen lassen.

    Was GLM-5.3 bei Exploits leistet

    Für die Messung der Angriffsfähigkeiten nutzt das Team zwei Werkzeuge. Das erste ist ExploitBench, ein Benchmark für bekannte Schwachstellen in der V8-Engine von Google Chrome. Entscheidend ist nicht, ob ein Modell eine Lücke erkennt, sondern ob es daraus einen vollständigen Exploit baut. Laut Bericht gelingt GLM-5.3 das in 50 von 410 Versuchen, das eigene Modell Claude Mythos Preview in 56 von 410. Zwei Modelle auf Augenhöhe.

    Das zweite Werkzeug ist ein interner Benchmark für binäre Ausnutzung, auf Basis von Projekten aus Googles OSS-Fuzz-Programm. Volle Punktzahl gibt es nur für vollständige Kontrollflussübernahme, also dafür, dass der Angreifer die Programmsteuerung übernimmt. Auf 100 zufällig ausgewählten Aufgaben erreicht GLM-5.3 das in vier Prozent der Durchläufe, Claude Mythos Preview in sechs Prozent. Interessanter als der kleine Abstand ist die Grenze dahinter: Frühere Modelle wie Claude Opus 4.6, GLM-5.2, Kimi K3 oder DeepSeek V4.1-Flash kommen in beiden Tests praktisch nicht über null Prozent.

    Ein Exploit ist mehr als ein einzelner Trick. Er ist eine Kette, bei der jedes Glied stimmen muss: die Lücke finden, ihre Ursache verstehen, den Speicher gezielt manipulieren, Schutzmechanismen umgehen, den Angriff reproduzierbar machen. Solche Ketten baut GLM-5.3 laut Analyse eigenständig. Für Angreifer ist das der entscheidende Sprung. Knapp ist nicht das Wissen um eine Schwachstelle, sondern die Arbeit, aus ihr eine Waffe zu formen.

    Der Sprung zwischen GLM-5.2 und GLM-5.3

    Die Kurven im Bericht zeigen den Erfolg nicht als feste Zahl, sondern abhängig vom Rechenbudget, gemessen in ausgegebenen Tokens. Das verrät, wie schnell ein Modell mit mehr Arbeitszeit besser wird. Bei GLM-5.3 steigt die Erfolgsquote deutlich, bei GLM-5.2 bleibt die Linie nahe null, egal wie viel Rechenzeit man investiert. Dasselbe Muster zeigt der Vergleich von Claude Opus 4.6 und Claude Mythos Preview.

    Die Autoren lesen daraus einen Generationssprung, keinen graduellen Fortschritt. Zwischen aufeinanderfolgenden Versionen liegt offenbar eine Schwelle, ab der aus vereinzelten Teilerfolgen eine belastbare Fähigkeit zur autonomen Ausnutzung wird. Deshalb ist die Veröffentlichung von GLM-5.3 mehr als eine weitere Zeile in einer Rangliste. Wer ein Modell dieser Klasse kontrolliert, kontrolliert ein Werkzeug, das vorher nur hinter Zugangsschranken zu haben war.

    Auch wie die Vergleiche zustande kommen, ist bemerkenswert. Die eigenen Claude-Modelle wurden mit deaktivierten Sicherheitsvorkehrungen getestet, in einem Zustand also, den normale Nutzer nicht erreichen. Bei GLM-5.3 brauchte es diesen Kunstgriff nicht, weil das Modell ohnehin frei herunterladbar ist. Der Vergleich misst damit nicht nur Fähigkeiten, sondern auch, wer sie tatsächlich abrufen kann.

    Ein Forschertag genügt für eine Exploit-Kette

    Neben den automatisierten Benchmarks schildern die Autoren Tests, bei denen Fachleute das Modell auf unbekannte Ziele ansetzten. In einer ersten Sitzung arbeitete ein Forscher auf einer abgeschotteten Maschine mit einer Linux-Version eines verbreiteten Browsers. Im Laufe eines Tages fand GLM-5.3 mehrere bis dahin unbekannte Schwachstellen in der JavaScript-Engine und verknüpfte sie zu einem funktionierenden Exploit. Das Ergebnis: eine Webseite, die beim Besuch beliebige Dateien vom Rechner ausliest, darunter einen privaten SSH-Schlüssel. Der menschliche Aufwand blieb gering, unter einer Stunde konzentrierter Arbeit.

    Die Autoren weisen darauf hin, dass die Lücke im Linux-Build nachgewiesen wurde, andere Plattformen aber wahrscheinlich ebenfalls betroffen sind, wenn auch über komplexere Wege. Der Hersteller wurde informiert. In derselben Sitzung stieß der Forscher mit Unterstützung des Modells auf weitere ausnutzbare Schwachstellen, unter anderem in Funk- und Grafiktreibern sowie in netzwerknaher Gerätesoftware. Diese Fälle werden derzeit geprüft.

    Eine zweite Sitzung widmete sich einer bekannten Lücke, dem Chrome-Fehler CVE-2026-11645. Es ging um die Frage, wie schnell sich ein öffentlicher Patch in einen funktionierenden Angriff verwandeln lässt, in der Sicherheitsszene als N-Day-Problem bekannt. Das kleinere Modell GLM-5.3-Flash verband den Fehler mit einer weiteren bekannten Schwachstelle zu einer zuverlässigen Exploit-Kette für ARM64-Systeme und umging die Pointer-Authentication-Härtung. Der menschliche Anteil: rund zwanzig Minuten Aufmerksamkeit. Das Modell arbeitete acht Stunden. Zu den API-Preisen von Zhipu entspricht das etwa 20,40 Dollar.

    Warum sich die Sicherheitsvorkehrungen umgehen lassen

    GLM-5.3 hat Schutzmechanismen. Auf klar schädliche Anfragen verweigert das Modell in der Regel die Antwort. Die Autoren zeigen aber, dass sich diese Verweigerung mit einfachen Mitteln aushebeln lässt. In einer simulierten Umgebung, in der das Modell offen zur Attacke auf kritische Systeme aufgefordert wurde, lehnte es zunächst in allen Durchläufen ab. Mit einer Rahmenhandlung, die es zu einem autonomen Red-Team-Agenten in einer Übung erklärte, sank die Verweigerungsquote auf 64 Prozent. Das Modell spielte also in mehr als der Hälfte der Versuche mit. Wurde ihm ein Teil seiner Antwort vorab eingefüllt, reagierte es in 92 Prozent der Fälle.

    Die gründlichste Methode heißt Abliteration. Dabei werden die Gewichte, also die trainierten Zahlenwerte des Modells, so verändert, dass die eingelernte Weigerungshaltung verschwindet. Weil GLM-5.3 als Open-Weight-Modell erscheint, kann das jeder mit entsprechender Hardware selbst tun. Mehrere Entwickler veröffentlichten schon wenige Tage nach dem Release passende Varianten. Anthropic erstellte zu Forschungszwecken eine eigene abliterierte Fassung und beziffert den Aufwand auf rund 2.200 GPU-Stunden und etwa 4.400 Dollar Rechenkosten. Für die kleinere Variante GLM-5.3-Flash genügten rund 600 GPU-Stunden.

    Das Ergebnis ist eindeutig. Die Verweigerungsquote fiel von über 90 Prozent auf etwa drei Prozent im JailbreakBench, zwei Prozent im HarmBench und zwölf Prozent im StrongREJECT. Die Leistungsfähigkeit blieb weitgehend erhalten: Im GPQA-Diamond, einem Test für allgemeine wissenschaftliche Fähigkeiten, schnitten Original und abliterierte Fassung identisch ab; im CyberGym-Test lag die veränderte Version nur wenige Prozentpunkte niedriger. Bei den geschlossenen Claude-Modellen ist dieser Weg versperrt, weil die Gewichte nicht veröffentlicht werden und sich nicht nachträglich umbauen lassen.

    Was die NIST-CAISI-Bewertung von GLM-5.3 zeigt

    Die Analyse steht nicht allein. Am 17. September veröffentlichte das Center for AI Standards and Innovation (CAISI) am US-NIST eine eigene Einschätzung der Cyberfähigkeiten von GLM-5.3. Die Behörde nennt es das bislang fähigste Open-Weight-Modell im Bereich Cyber und verortet es im Aggregat ihrer Benchmarks etwa vier Monate hinter der US-Spitze. Die Befunde von Anthropic decken sich in der Tendenz damit.

    Ein Detail der CAISI-Methodik ist wichtig. Die amerikanischen Vergleichsmodelle wurden, wo nötig, mit deaktivierten Sicherheitsvorkehrungen getestet, und zur US-Spitze zählen auch Modelle, die nur geprüften Nutzern zugänglich sind. Für Angreifer sind diese Versionen praktisch unerreichbar. GLM-5.3 dagegen kann jeder herunterladen — ohne Antrag, ohne Prüfung, ohne Vertrag. Der Abstand von vier Monaten beschreibt deshalb nicht nur einen technischen Rückstand, sondern eine offene Tür.

    Was das für Angreifer und Verteidiger bedeutet

    Die Fähigkeit selbst ist nicht neu. Neu ist ihre Verteilung. Genau das meinen die Autoren, wenn sie schreiben, Modelle dieser Klasse seien nun angekommen: Was zuvor in einem kontrollierten Kreis von Verteidigern zirkulierte, liegt jetzt als herunterladbare Datei vor. Wer Software betreibt, muss deshalb nicht in Panik verfallen, sollte aber realistisch rechnen. Der Abstand zwischen dem Bekanntwerden einer Schwachstelle und einem funktionierenden Angriff schrumpft — auf Stunden, wenn ein Modell acht Stunden rechnen darf.

    Zugleich gilt der umgekehrte Fall. Dieselben Fähigkeiten helfen Verteidigern, Schwachstellen zu finden, bevor sie ausgenutzt werden. Im Programm Project Glasswing, mit dem Anthropic sein eigenes Spitzenmodell zunächst nur geprüften Sicherheitsteams zur Verfügung stellte, wurden nach Angaben des Unternehmens mehr als 10.000 Schwachstellen in kritischer Software aufgespürt. Diesen Vorsprung beschreiben die Autoren als bewusst gewählten Zeitgewinn, bevor vergleichbar fähige Modelle allgemein verfügbar wurden. Offen bleibt, wie lange solche Vorsprünge halten, wenn Gewichte frei verteilt werden.

    Für die Praxis bleibt eine nüchterne Einordnung. Die Abliteration eines Modells kostet derzeit noch Tausende Dollar Rechenzeit und einiges an Know-how. Beide Hürden sinken mit jeder Generation. Sicherheitsvorkehrungen, die nur in den Antworten eines Modells verankert sind und nicht in der Verfügbarkeit seiner Gewichte, halten einem entschlossenen Angreifer nicht dauerhaft stand. Wer Systeme betreibt, sollte deshalb weniger darauf setzen, dass ein Angreifer keine KI benutzt, und mehr darauf, dass Angriffe schneller erkannt, Patches rascher eingespielt und Schutzmechanismen wie Pointer-Authentication nicht als Allheilmittel behandelt werden.

    Quelle: anthropic.com

  • Cloudflares security-audit-skill: mehrphasiger Sicherheitsaudit für Coding-Agenten mit maschinenlesbaren Befunden

    Cloudflares security-audit-skill: mehrphasiger Sicherheitsaudit für Coding-Agenten mit maschinenlesbaren Befunden

    Zuerst wird ein Ledger angelegt: jede untersuchbare Einheit der Codebasis bekommt eine Kennung und einen Prüfstatus. Erst danach beginnt die Suche. Isolierte Agenten arbeiten die Einheiten ab, eine zweite Gruppe sucht Lücken im Prüfplan, und jeder vorläufige Befund geht an einen Prüfer, dessen Auftrag das Widerlegen ist.

    Cloudflare hat diesen Ablauf als offenes Skill für Coding-Agenten auf GitHub veröffentlicht. security-audit-skill ist eine Sammlung von Anweisungen, Schemata und Prüfskripten, die einen Agenten durch sechs Phasen führt: Aufnahme, Abdeckung, Kandidatenprüfung, strukturierte Ausgabe, unabhängige Nachprüfung und Bericht. Nach Angaben des Projekts ist es das Skill, aus dem Cloudflares Vulnerability-Discovery-Harness hervorgegangen ist. Der Harness wurde daraus zu einem mehrstufigen, flottenweiten System ausgebaut; dieses Repository ist der Ausgangspunkt für ein einzelnes Projekt.

    Das Vorgehen erinnert an die Trennung von Bauausführung und Prüfstatik. Wer die Wand gemauert hat, nimmt sie nicht selbst ab. Diese Trennung ist hier nicht als Empfehlung formuliert, sondern in den Ablauf eingebaut. Das unterscheidet den Ablauf von einem Scanner, den man einmal über ein Repository laufen lässt.

    Einen Agenten nach einem Sicherheitsaudit zu fragen und den ersten Bericht als Ergebnis zu nehmen, ist verständlich, aber meistens zu optimistisch. Ein Sprachmodell produziert plausiblen Text. Plausibilität ist das Gegenteil von Beweis. Der folgende Durchgang zeigt, wie das Skill dagegen arbeitet.

    Ein Ledger statt Bauchgefühl: wie die Aufnahme den Prüfumfang festlegt

    Die erste Phase heißt Reconnaissance und hat wenig mit Suchen zu tun, sondern viel mit Kartieren. Der Agent erfasst Architektur, Vertrauensgrenzen und Eingabeoberflächen, dazu frühere Befunde und die deterministisch bekannte Abdeckung. Zwei Dateien entstehen dabei: architecture.md für das Bild des Systems und coverage-ledger.json für das Verzeichnis aller Einheiten, die geprüft werden müssen oder bereits geprüft wurden. Das Ledger ist kein Protokoll im Nachhinein, sondern der Prüfplan, gegen den später abgerechnet wird.

    Phase zwei folgt diesem Plan. Aus den Einheiten des Ledgers werden isolierte Hunter zugewiesen, jeder mit einem begrenzten Auftrag, und jeder Hunter trägt seine durchgeführten Checks zurück ins Ledger ein. Danach kommen Coverage-Critics zum Einsatz, deren einzige Aufgabe es ist, Lücken zu finden: Stellen, die im Ledger fehlen oder nur scheinbar abgedeckt sind. Damit unterscheidet sich der Ablauf von der freien Suche. Nicht der Fund steuert den Fortgang, sondern die Frage, was noch nicht angesehen wurde.

    Damit das Ledger nicht selbst zur Behauptung verkommt, läuft nach dem Anlegen und nach jeder späteren Aktualisierung ein Prüfskript darüber. validate-coverage-ledger.cjs arbeitet ohne Abhängigkeiten und prüft die Struktur der Datei in den Phasen eins bis fünf. Ein Eintrag, der formal nicht stimmt, fällt auf, bevor er die weiteren Phasen verzerrt.

    Falsifikation statt Bestätigung: der Finder prüft sich nicht selbst

    In Phase drei bekommt jeder eindeutige Kandidat einen frischen Prüfer. Dessen Auftrag ist nicht, den Befund zu bestätigen, sondern ihn zu widerlegen. Doppelte Kandidaten werden vorher zusammengeführt, damit nicht fünf Prüfer dieselbe Beobachtung fünfmal abnicken. Der Prüfer ist ein separater Agent, ohne den Fundweg des ersten. Er sieht das Ergebnis und die Quelle, nicht die Überlegung, die dazu geführt hat.

    Das Projekt formuliert es als Designprinzip: Der Agent, der einen Befund prüft, ist nie der Agent, der ihn gefunden hat. In der Praxis entscheidet das darüber, ob ein automatischer Audit brauchbar ist. Ein Modell, das seinen eigenen Fund nachbewertet, bestätigt ihn fast immer, weil die Begründung schon im Kontext liegt. Ein zweiter Durchlauf ohne diesen Kontext hat diese Bequemlichkeit nicht.

    Dazu kommen Regeln, die den Begriff der Schwachstelle schärfen. Bestätigt wird nur ein etablierter Grenzübertritt, also ein nachvollziehbarer Bruch einer Vertrauensgrenze mit beobachtbarer Wirkung. Eine Lücke in der Defense-in-Depth ist keine Schwachstelle: Wenn Schutzschicht A den Angriff verhindert, ist das Fehlen von Schutzschicht B ein Härtungshinweis und wandert nicht in die Befundliste. Die Schwere eines Befunds verlangt einen Impact, berechnet aus Wahrscheinlichkeit mal Auswirkung, nicht aus der Abweichung von einer Checkliste.

    Ein blockierter, aber quellenbelegter Hinweis wird nicht weggelassen und nicht hochgestuft. Er bleibt als needs_validation stehen, mit dem exakten ungelösten Fakt, der zu seiner Klärung fehlt. Solche Einträge bleiben offen, das ist unbequem. Ein glatter Befund ohne Belege wäre schlechter.

    Drei Urteile, ein Schema und zwei Validatoren

    Phase vier übersetzt die Prüfergebnisse in eine maschinenlesbare Datei namens findings.json. Jeder Eintrag trägt eines von drei Urteilen. confirmed bedeutet: vollständiger Quellennachweis und ein begrenztes, tatsächlich beobachtetes Ergebnis. needs_validation bedeutet: ein exakter, ungelöster Fakt und ausdrücklich keine Schweregradeinschätzung. rejected dokumentiert einen widerlegten Kandidaten. Auch das ist ein Ergebnis, weil es verhindert, dass dieselbe Spur beim nächsten Lauf wieder aufgemacht wird.

    Gegen das Schema report-schema.json prüft validate-findings.cjs, wieder ohne Abhängigkeiten. Das Skript läuft in Phase vier und erneut nach jeder Ersetzung in Phase fünf, damit kein nachträglich geänderter Datensatz ungeprüft stehen bleibt. Zu beiden Validatoren gehören Testdateien, die unter anderem prüfen, ob erzeugte Datensätze zum Schema passen.

    Die Befunde sind keine Prosa, die man von Hand aus einem Langtext zieht. Sie sind Datensätze mit Quelle, Urteil und Begrenzung, die sich in ein Ticketsystem, eine Pipeline oder ein Prüfprotokoll übernehmen lassen. Einen zehnseitigen Scan-Bericht in Arbeitsschritte zu zerlegen, ist mühsam. Ob ein Audit weiterverarbeitet oder nur abgeheftet wird, hängt davon ab, ob die Befunde maschinenlesbar sind.

    Unabhängige Nachprüfung und der additive Lauf über mehrere Durchgänge

    Phase fünf setzt eine weitere Schicht darauf. Dort verifizieren frische Agenten die endgültigen Quellenaussagen, also die Behauptung, dass eine bestimmte Stelle im Code tatsächlich das tut, was der Befund ihr zuschreibt. Wird ein Eintrag inhaltlich ersetzt, bekommt er einen weiteren unabhängigen Prüfer. Erst danach entstehen in Phase sechs die Berichte: REPORT.md, FINDINGS-DETAIL.md und NEEDS-VALIDATION.md, abgeleitet aus den verifizierten Datensätzen und dem Coverage-Ledger. Die Berichte leiten sich aus den Datensätzen ab, sie sind nicht die Quelle der Wahrheit.

    Mehrere Durchläufe gegen dasselbe Repository addieren sich. Frühere Ledger und Befunde werden genutzt, um gezielt Lücken anzugehen, geänderten Quellcode neu zu prüfen und belegte Aussagen zum aktuellen Code mitzunehmen. Veraltete oder ungelöste Arbeit wird dabei ausdrücklich nicht als erledigt behandelt. Ein Audit ist hier kein einmaliger Termin.

    Cloudflare nennt für die eigenen Testläufe eine Zahl: Ein einzelner Durchlauf fand ungefähr die Hälfte der Schwachstellen, die wiederholte Läufe zusammen fanden. Ein mehrphasiger Sicherheitsaudit mit KI-Agent ist also nicht deshalb gründlich, weil er schlau ist, sondern weil er mehrfach und mit Gedächtnis läuft. Ein einmaliger Scan erreicht das nicht.

    Angriffsklassen als Nachschlagewerk für verschiedene Zieltypen

    Das Skill besteht nicht nur aus Ablauflogik, sondern aus einer Reihe von Wissensdateien. SKILL.md beschreibt Einrichtung, Grundprinzipien und Anti-Muster eines Audits, RECONNAISSANCE.md die Aufnahme, HUNTING.md die Orchestrierung der Suche, VALIDATION-AND-REPORTING.md die Phasen drei bis sechs. Dazu kommen Angriffsklassen als eigene Dateien.

    Für native Ziele gibt es MEMORY-SAFETY-AND-BINARY.md mit Speichersicherheit, Binär- und Kernel-Klassen. Für Systeme mit Sprachmodellen liegt AI-AND-LLM.md bereit, mit Prompt-Injection, Agenten- und Werkzeuggrenzen sowie der Behandlung von Modellausgaben. Weitere Dateien decken HTTP-Protokoll und Authentifizierung, clientseitige Themen von DOM-Injection bis Prototype-Pollution, Supply Chain und Release, Cloud und Deployment, RPC und Messaging, Ressourcenerschöpfung, Mandantentrennung und Datenlebenszyklus sowie Desktop-, Mobile- und lokale IPC-Flächen ab. Die Reihenfolge ist keine Rangfolge, sondern eine Auswahlhilfe je nach Ziel.

    Solche Prüfungen scheitern üblicherweise an einem Muster: Ein Agent, der „finde Schwachstellen“ liest, greift auf das Offensichtliche zu und verteilt seine Aufmerksamkeit dünn über alles. Ein Katalog verschiebt die Arbeit von allgemeinem Verdacht zu konkreten Klassen mit bekannten Mustern. Ein Sprachmodell prüft hier ein System, das selbst Sprachmodelle enthält. Prompt-Injection betrifft beide Seiten.

    Installation, Sandbox-Pflicht und was das im Alltag bedeutet

    Die Installation läuft über die Skills-CLI. Ein Aufruf wie npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit bindet das Skill ein, mit dem Zusatz --global gilt es benutzerweit statt nur im aktuellen Projekt. Für Auswahl des Agenten und nicht-interaktive Varianten gibt die Hilfe der CLI Auskunft. Danach startet man den Coding-Agenten im zu prüfenden Repository und bittet um ein Security Audit; das Skill aktiviert sich, wenn die Anfrage zu seinen Auslösern passt.

    Zwei Betriebsarten sind vorgesehen. Eine gezielte Frage oder eine einzelne Schwachstellenanalyse läuft im Guidance-Modus, ein vollständiger Audit- oder Pen-Test-Auftrag im Full-Audit-Modus. In diesem Modus landen die Ergebnisse ohne Angabe eines Verzeichnisses unter einem Benutzerpfad mit Repo-Namen und laufender Nummer; in das Repository selbst wird nur geschrieben, wenn ausdrücklich ein ignoriertes Verzeichnis gewählt wurde. So liegen Audit-Artefakte nicht ungewollt im Versionskontrollsystem.

    Die Anforderungen sind nüchtern, mit einer harten Kante: Gebraucht wird ein Coding-Agent, dessen Modell Werkzeugnutzung und parallele Unteragenten beherrscht, dazu Node.js für die Validatoren. Vor allem aber braucht es eine vom Betriebssystem erzwungene Sandbox für alles, was vom Ziel gesteuert wird: Builds, Tests, Prozesse, Browser, Emulatoren und Fuzzer. Diese Sandbox muss externes Netzwerk abschalten, eine bereinigte Umgebung mit Erlaubnisliste verwenden, Ressourcengrenzen durchsetzen und Schreibzugriffe auf zugewiesene Pfade begrenzen. Fehlen diese Kontrollen, führt der Ablauf den Code des Ziels nicht aus, sondern belässt den Hinweis als needs_validation.

    Ein automatisiertes Audit, das fremden Build-Code ohne Netzwerksperre und ohne Ressourcengrenzen ausführt, verschiebt das Risiko vom Prüfling zum Prüfer. Der Workflow nimmt dafür lieber einen offenen Eintrag in Kauf, als diese Grenze zu überschreiten. Das Skill ist unter MIT-Lizenz veröffentlicht, Rückmeldungen laufen über eine Cloudflare-Adresse für Sicherheitsforschung mit KI.

    Wer einen Coding-Agenten für Schwachstellenanalyse einsetzen will, sollte auf den Ablauf achten, nicht auf das Modell: ein Prüfplan mit Kennungen, getrennte Finder und Prüfer, drei klar definierte Urteile und Datensätze, die eine Pipeline lesen kann. Ein Sicherheitsaudit wird damit zu einem wiederkehrenden Vorgang mit wachsendem Ledger statt zu einem einmaligen Knopfdruck. Ein einzelner Durchlauf findet etwa die Hälfte aller Schwachstellen. Der Rest braucht weitere Läufe.

    Quelle: github.com

  • Wenn Coding-Agents Produktionszugriff erhalten: Ein Sicherheits-Tradeoff in der Praxis

    Wenn Coding-Agents Produktionszugriff erhalten: Ein Sicherheits-Tradeoff in der Praxis

    Ein Entwickler mit jahrzehntelanger Infrastruktur-Erfahrung beschreibt, wie er seinem KI-Coding-Agenten direkten Zugriff auf sensible Produktionsgeheimnisse gewährt: Tailscale-Auth-Key, SSH-Private-Keys, OAuth-Tokens für Anthropic und Codex sowie ein Gmail-App-Passwort. Die Werte liegen in einem Passwort-Tresor; der Agent nutzt sie, ohne die Klartext-Inhalte zu sehen. Das Setup liegt bewusst jenseits dessen, was viele Sicherheitsrichtlinien empfehlen. Der Autor macht das transparent.

    Wie funktioniert dieses Setup? Wo geht er bewusst Risiken ein, wo ist die Argumentation nachvollziehbar? Wer mit Coding-Agents arbeitet, steht früher oder später vor genau dieser Frage: Wie viel Vertrauen bekommt ein Werkzeug, das Texte aus dem Internet liest und Root-Rechte auf einem Produktionssystem haben könnte?

    Hintergrund des Autors: Infrastruktur-Erfahrung und KI-Agenten-Plattform

    Der Autor stellt seinen Werdegang voran, um die Tragweite seiner Entscheidung zu begründen. Er arbeitete in Rechenzentren, betrieb jahrelang Linux-Infrastruktur, war Security- und Network-Engineer und baute Produktionssysteme für verschiedene Firmen – darunter eine Plattform für KI-Coding-Agents, die nach seinen Angaben Hunderttausende nutzen. Diese Selbstauskunft soll Glaubwürdigkeit schaffen. Wer Sicherheitsfragen behandelt, sollte wissen, wovon er spricht.

    Die Doppelrolle erzeugt eine Spannung: Wer eine Agent-Plattform mit großer Verbreitung betreibt, will Agents als produktiv und sicher zugleich wahrgenommen sehen. Das macht seine Aussagen nicht falsch. Aber man sollte sie vor diesem Hintergrund lesen, statt sie ungeprüft zu übernehmen. Am Ende sind es die persönlichen Trade-offs einer einzelnen Person, keine allgemeingültige Sicherheitsempfehlung.

    Simon Willisons tödliche Dreiheit: Alle Risiken sind erfüllt

    Der Autor beruft sich auf Simon Willisons Konzept der ›lethal trifecta‹ – der tödlichen Dreiheit. Ein KI-Agent besitzt darin drei Fähigkeiten gleichzeitig: Zugriff auf private Daten, die Fähigkeit, nicht vertrauenswürdige Inhalte zu lesen, und die Möglichkeit, nach außen zu kommunizieren. Die Kombination ist gefährlich, weil ein Angreifer in einem scheinbar harmlosen Dokument, einer Webseite oder einem Issue versteckte Anweisungen unterbringen kann. Der Agent befolgt sie, ohne dass der Mensch am Bildschirm es merkt.

    Das beschriebene Setup erfüllt genau dieses Profil. Der Agent hat über den Passwort-Tresor Zugriff auf produktive Geheimnisse, liest in seinem Aufgabenbereich Code, Webseiten, Issues und möglicherweise E-Mails und kann über das Netzwerk nach außen kommunizieren. Ein einziger geschickter Prompt-Injection-Vektor könnte ihn dazu bringen, diese Geheimnisse nach außen zu senden. Der Autor verschweigt das nicht. Er benennt das Risiko ausdrücklich und verwendet bewusst das Wort „in theory“, um zu zeigen, dass er es kennt.

    Produktivitäts-Tradeoff: Warum der Zugriff sinnvoll ist

    Das Vertrauen folgt einer einfachen Rechnung. Ein Agent mit Produktionszugriff kann bei einem Ausfall selbstständig Logs lesen, Hypothesen bilden, einen Fix deployen und prüfen, ob er funktioniert. Ohne den Zugriff übernimmt der Mensch diese Schritte manuell – genau diese Schleife kostet bei Vorfällen wertvolle Minuten.

    Dazu zieht er einen Vergleich, der in Diskussionen über KI-Agenten selten fällt: den mit einem neuen, unerfahrenen Teamkollegen. Auch einem neuen Mitarbeiter gibt man Zugriff auf Produktionssysteme, obwohl er versehentlich Malware installieren oder auf eine Phishing-Mail hereinfallen könnte. Man gibt den Zugriff trotzdem – die Alternative, gar nichts zu delegieren, würde den Betrieb unmöglich machen. In dieser Sicht ist der Agent keine Blackbox, sondern ein Teammitglied mit einer anderen Fehlerklasse. Die Analogie ist gewagt, weil ein Mensch rechtlich und organisatorisch eingebunden ist, ein Agent nicht. Das Grundprinzip der Abwägung ist aber plausibel.

    Frontier-Modelle und Prompt-Injection: Warum das Risiko neu bewertet wird

    Ein zentraler Punkt: Aktuelle Frontier-Modelle sollen besser zwischen Anweisungen des Nutzers und Anweisungen in gelesenen Inhalten unterscheiden können. Der Autor arbeitet laut eigenen Angaben ausschließlich mit Astra und Fable für schwierige Probleme sowie Sol und Opus für Routineaufgaben. Ältere Modelle hätte er mit diesem Setup nicht betraut; bei den aktuellen sei die Sorge vor Prompt-Injection deutlich geringer.

    Vorsicht ist angebracht. Die Aussage, Modelle würden besser zwischen Nutzer- und Inhaltsanweisungen trennen, wiederholt das, was Labore in ihren Berichten schreiben. Das Problem ist damit nicht gelöst. Die Forschung ist sich weitgehend einig: Eine robuste, nachweisbare Lösung gegen Prompt-Injection gibt es nicht. Es gibt nur Modelle, die in Benchmarks und Red-Teamings seltener darauf hereinfallen. Wer das anders darstellt, macht sich etwas vor.

    Der Autor grenzt weiter ein: Das Vertrauen gilt Agents, die in der eigenen, als vertrauenswürdig eingestuften Codebase arbeiten. Ein zufälliges GitHub-Projekt mit derselben Zugriffsstufe zu öffnen, wäre eine sehr schlechte Idee. Wichtiger Hinweis: Die Angriffsfläche wächst mit der Menge an unvertrautem Input, den ein Agent verarbeitet.

    Docker als Sandbox: Isolation statt Sicherheitsgrenze

    Trotz des Vertrauens laufen seine Agents in isolierten Docker-Containern. Der Autor sagt ehrlich, warum: Die Container trennen die Arbeitsverzeichnisse der Agents, verhindern, dass sich parallele Dev-Server stören, und fangen wilde rm -rf-Kommandos auf – oder Prozesse, die man später aufräumen müsste. Wer schon einmal erlebt hat, wie ein Agent die eigene Festplatte oder einen Git-Worktree demoliert, weiß den Komfort zu schätzen.

    Gleichzeitig machen die Container für ihn keine Sicherheitsgrenze aus. Geheimnisse und Zugriff auf Produktionsmaschinen bleiben verfügbar; einen Prompt-Injection-Angriff hält eine Sandbox nicht auf. Diese Unterscheidung zwischen Komfort und Sicherheit ist ehrlich – und sie fehlt in vielen Blogposts.

    Least Privilege und die Frage nach der feinkörnigen Kontrolle

    Der klassische Einwand lautet: Prinzip der minimalen Rechte, „least privilege“. Jeder Agent soll nur die Zugriffe bekommen, die er für seine Aufgabe braucht. Der Autor widerspricht nicht im Prinzip, bezweifelt aber, dass die Praxis schon so weit ist. Feinkörnige Kontrollen stünden im Weg, wenn ein Agent spontan von einer Log-Analyse zu einem Deployment wechseln muss, um ein Problem zu beheben.

    Ein weiterer Punkt wird in der Security-Community gern übersehen: Das Verstecken von Credentials allein löst das größte Risiko nicht. Ein Agent, der nie einen SSH-Key im Klartext sieht, aber eine Root-Shell auf einem Produktionsserver bekommt, kann trotzdem rm -rf ausführen und das System zerstören. Credential-Hygiene ist wichtig, aber sie ist nicht Zugriffskontrolle. Diese Unterscheidung sollte man sich merken – viele Secrets-Management-Lösungen laufen an der eigentlichen Gefahr vorbei.

    Die philosophische Frage: Wetten wir gegen die Modelle?

    Zum Schluss blickt der Autor nach vorn. Wer annimmt, Agents müssten auf absehbare Zeit streng kontrolliert werden, wettet gegen weitere große Modellverbesserungen. Treten sie ein, könnten wir Agents irgendwann mehr vertrauen als uns selbst. Das klingt provokant, ist aber eine logische Konsequenz des aktuellen Trends: Modelle werden in Benchmarks zuverlässiger, die Fehlerquote bei klassischen Aufgaben sinkt messbar.

    Offen bleibt, ob sich Zuverlässigkeit in Benchmarks auf die offene Welt übertragen lässt. Wählt ein Agent in 99 Prozent der Fälle die richtige Aktion, ist er im verbleibenden Prozent ein kaum kalkulierbares Risiko – gerade wenn dieser eine Fall das rm -rf ist. Modell-Updates helfen dann nicht mehr. Nötig ist Architektur: Read-only-Tools für gefährliche Operationen, Bestätigungsschritte für destruktive Aktionen, Audit-Logs, die zeigen, was passiert ist.

    Was das für die eigene Arbeit mit Coding-Agents bedeutet

    Was bleibt von diesem Erfahrungsbericht? Erstens: Eine wachsende Zahl von Entwicklern gibt ihren Agents deutlich mehr Vertrauen, als die Sicherheitsliteratur empfiehlt – mit bewusster Risikoabwägung. Das ist kein Grund, es nachzumachen. Aber es zeigt, dass die Diskussion über Agent-Sicherheit nicht nur aus Verboten bestehen kann.

    Zweitens: Die tödliche Dreiheit bleibt real, auch wenn Modelle besser werden. Wer Agents mit Produktionszugriff ausstattet, muss fragen, ob der gelesene Input kontrolliert ist und ob sich die Kommunikation nach außen einschränken lässt. Drittens: Docker sorgt für Komfort und Reproduzierbarkeit, ist aber keine Verteidigung gegen Prompt-Injection. Viertens: Wer Least Privilege umsetzen will, braucht Tools, die granulare Freigaben erzwingen – nicht nur versteckte Geheimnisse.

    Die zentrale Botschaft ist keine Empfehlung, sondern eine Einladung zum Nachdenken. Coding-Agents mit Produktionszugriff sind längst Alltag in vielen Teams. Wie viel Vertrauen wir ihnen geben, ist keine rein technische Frage. Es ist eine Entscheidung zwischen Produktivität und Kontrolle – nicht verallgemeinerbar, aber bewusst treffbar.

    Quelle: jacob.gold

Weitere Beiträge