Artikel teilen

Ein KI-Agent baut eine Löschfunktion in eine Tabelle ein, prüft sie im Browser und meldet Erfolg. Gesehen hat er nur das Konto, mit dem er auf dem Entwicklungsserver angemeldet war. Matt Rothenberg, der bei Cloudflare das Designsystem betreut, zeigt, wie ein Prinzip von 2015 solche Lücken sichtbar macht.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Vier Schritte, alle erfolgreich: Code geändert, Typprüfung bestanden, Seite mit der Rolle Inhaber geöffnet, Screenshot gemacht. Mit der Rolle Betrachter zeigt dieselbe Tabelle den Löschknopf ebenfalls, obwohl in der Kopfzeile „Nur Lesen“ steht.[1] Rothenberg nennt das Beispiel konstruiert, aber typisch.

Das Wichtigste in Kürze

  • KI-Agenten prüfen Oberflächen oft nur in dem Konto, mit dem sie gerade angemeldet sind.
  • Schon vier Parameter mit je zwei Werten ergeben 16 Varianten einer Seite.
  • Rothenberg rendert alle Zustände einer Seite nebeneinander, nach dem Prinzip Pure UI.
  • Ein ausgeblendeter Knopf ersetzt keine Rechteprüfung auf dem Server.

Warum übersieht der Agent den Fehler?

Checkliste mit orangefarbenem Haken und weißer Stempel mit schwarzem Text „Fertig“
Agent prüft nur eigenes Konto; Zustand verteilt über React-Komponenten, Kontext und Feature-Flags auf verschiedenen Ebenen

Der Agent prüft nur das Konto, mit dem er angemeldet ist, und der Zustand einer Seite ist in großen React-Anwendungen über viele Stellen verteilt. Die Rolle kommt aus einer Komponente fünf Ebenen höher, der Tarif aus einem Kontext auf oberster Ebene, der Zahlungsstatus aus einem Layout und die Beta-Funktion aus einem Feature-Flag. In Rothenbergs Beispiel kennt die Kopfzeile die Rolle, die Tabelle nicht, und der Prompt nannte nur die Tabelle.[1]

Ein Agent meldet genauso „fertig“, ob er einen Zustand geprüft hat oder sechzehn, während jede generierte Änderung weniger Prüfzeit bekommt.[1] Wie knapp diese Zeit geworden ist, beschreibt unser Beitrag über KI-Code, der die Prüfkapazität der Teams übersteigt.

Was bedeutet Pure UI für Teams mit KI-Agenten?

Pure UI macht jeden Zustand, der die Anzeige bestimmt, zum ausdrücklichen Parameter der Seite, sodass sich alle Varianten nebeneinander rendern lassen. Guillermo Rauch beschrieb 2015 die Oberfläche einer Anwendung als reine Funktion ihres Zustands. Seine Faustregel: Hat ein Team 20 Zustände festgelegt, sollten alle als HTML auf dem Bildschirm zu sehen sein.[2]

Bei Rothenberg erhält die Seite Rolle, Tarif, Zahlungsstatus und Beta-Schalter als Argumente, statt sie tief im Komponentenbaum abzufragen. Auf einer Testseite mit allen 16 Kombinationen fallen die acht Betrachter-Varianten mit Löschknopf sofort auf.[1]

Welche Kombinationen relevant sind, muss das Team selbst festlegen, räumt Rothenberg ein.[1] Mit den Grenzen von Designsystemen hatte er sich schon im August befasst: Viele Teams haben nur eine Komponentenbibliothek, kein Designsystem.

Eine Seite, sechzehn Zustände
Was ein KI-Agent sieht, wenn er nur im eigenen Konto prüft

Das Beispiel von Matt Rothenberg

4
Parameter bestimmen die Seite: Rolle, Tarif, Zahlungsstatus, Beta-Schalter
16
Varianten entstehen bei je zwei Werten pro Parameter
1 von 16
Zuständen prüfte der Agent, bevor er „fertig“ meldete
100 %
der von OWASP getesteten Anwendungen wiesen Lücken in der Zugriffskontrolle auf

Alle 16 Varianten im Raster

bezahlt, Beta an
bezahlt, Beta aus
überfällig, Beta an
überfällig, Beta aus
Inhaber, Pro
geprüft
korrekt
korrekt
korrekt
Inhaber, Free
korrekt
korrekt
korrekt
korrekt
Betrachter, Pro
Löschknopf
Löschknopf
Löschknopf
Löschknopf
Betrachter, Free
Löschknopf
Löschknopf
Löschknopf
Löschknopf

Blau umrandet: der eine Zustand, den der Agent gesehen hat. Orange: acht Betrachter-Varianten, die trotz „Nur Lesen“ einen Löschknopf zeigen. Anordnung vereinfacht nach dem Beispiel des Autors.

Werkzeuge, die Zustände sichtbar machen

Komponenten
Storybook
Aufgabe: ausgewählte Zustände rendern
Lizenz: MIT
Version: 10.6
End-to-End
Playwright
Aufgabe: Zustände in der laufenden Anwendung erreichen
Lizenz: Apache 2.0
Anbieter: Microsoft
Komponententests
Vitest
Aufgabe: Komponenten im Browser testen
Browser-Modus: stabil seit Version 4
Lizenz: MIT

Ein Screenshot aus einem einzigen Konto ist kein Test. Lassen Sie sich vom Agenten zeigen, welche Rollen er gesehen hat.

Michael Dobler, Herausgeber Dr. Web
Zitat teilen

Welche Werkzeuge helfen, und was bleibt Pflicht?

Storybook, Playwright und Vitest machen Zustände sichtbar, die Rechteprüfung auf dem Server bleibt Pflicht. Storybook rendert ausgewählte Zustände einer Komponente, Playwright prüft, ob sie in der laufenden Anwendung erreichbar sind.[1] Das Vitest-Addon von Storybook führt die Beispielzustände aus Storybook als Tests im Browser aus,[3] in einem Modus, den Vitest seit Version 4 als stabil einstuft.[4]

Laut OWASP ist Zugriffskontrolle nur wirksam, wenn sie im Servercode läuft, den Angreifer nicht verändern können. In den OWASP Top 10:2025 steht fehlerhafte Zugriffskontrolle erneut auf Platz 1, in allen getesteten Anwendungen fand sie sich in irgendeiner Form.[5]

Rothenbergs Agent änderte auch die Datei api/functions.ts. Prüfen Sie bei jeder generierten Löschfunktion, ob auch die API die Rolle abfragt.

Artikel 32 der DSGVO verlangt ein Verfahren zur regelmäßigen Überprüfung der Maßnahmen, die die Integrität der Systeme sichern.[6] Ein Raster aller Rollen kann Teil dieser Prüfung sein. Einen anderen Weg geht TesterArmy, das Apps per KI-Agent nach Anweisungen in natürlicher Sprache prüft.

Quellen

6 Quellen anzeigenQuellen ausblenden
  1. Matt RothenbergPure UI in the Agentic Era
  2. Guillermo RauchPure UI
  3. StorybookVitest addon
  4. VitestVitest 4.0 is out!
  5. OWASPA01:2025 Broken Access Control
  6. DSGVOArt. 32 DSGVO, Sicherheit der Verarbeitung

Mehr Newshunger?

4,6 10 Bewertungen

Wie hat Ihnen dieser Artikel gefallen?