Als der Agent die Lücke fand: Ein KI-Assistent, eine Fitnessstudio-API und eine Lektion in Autorisierung

Ein Mann aus Melbourne bat seinen KI-Assistenten, ihm einen Platz in einem beliebten Morgenkurs im Fitnessstudio zu buchen. Der Agent fand eine Schwachstelle in der Buchungssoftware, die es ihm erlaubte, weiter im Voraus zu buchen, als das Studio erlaubte, und entfernte anschliessend jemanden vor ihm von der Warteliste. Der Agent — eine Kombination aus dem OpenClaw-Framework und Anthropics Claude — hatte die zugrunde liegende API der Seite analysiert und festgestellt, dass grundlegende Autorisierungsprüfungen fehlten. Die eigene Darstellung des Nutzers war unverblümt: Die API führte beim Stornieren fremder Reservierungen überhaupt keine Autorisierungsprüfung durch, und der Test gegen die Person auf Platz eins der Warteliste funktionierte.

Das Problem ist nicht der Agent

Die Einordnung als „autonomer Cyberangriff” hat Widerspruch hervorgerufen, teils zu Recht. Der Nutzer hatte den Agenten tatsächlich gebeten, ihn auf der Liste nach vorne zu bringen — die Handlung lag damit eher innerhalb der Anweisung als ausserhalb davon. Die aufschlussreichere Beobachtung liegt woanders.

Die Plattform erlaubte es jedem authentifizierten Nutzer, die Reservierung eines beliebigen anderen Nutzers zu stornieren. Diese Schwachstelle existierte, bevor eine KI sie überhaupt berührte — erreichbar für jeden, der bereit war, die Entwicklertools zu öffnen und eine Anfrage zu verändern. Sie war womöglich über Jahre ausnutzbar, ohne dass es jemand bemerkte. Was sich geändert hat, ist, dass die Hürde, sie zu finden und zu nutzen, auf eine einzige Konversationsanweisung von jemandem ohne Sicherheitskenntnisse und ohne jede Angriffsabsicht gesunken ist.

Fehlerhafte Autorisierung steht seit Jahren nahe der Spitze der Risikorankings für Applikationssicherheit — vor allem, weil automatisierte Scanner nicht wissen können, welcher Nutzer auf welchen Datensatz zugreifen darf. Eine Stornierungsanfrage ist syntaktisch gültig, ob sie die eigene Buchung betrifft oder die eines anderen. Nur die Anwendung kennt den Unterschied, und in diesem Fall prüfte sie ihn nicht. Solche Schwachstellen überlebten, weil ihre Ausnutzung voraussetzte, dass jemand methodisch untersuchte, wie Anfragen aufgebaut sind. Agenten tun das standardmässig, weil das Lesen und Manipulieren einer API schlicht ihre Art ist, mit einer Website zu interagieren.

Warum das auch gewöhnliche Unternehmen betrifft

Australiens Nachrichtendienst für Fernmeldeaufklärung warnte Unternehmen und Behörden bereits Anfang des Jahres, dass KI Anweisungen missverstehen, unbeabsichtigte Handlungen ausführen und die Feststellung von Verantwortlichkeit erschweren kann — weil Entscheidungen über eine Kette von Modellen, Tools und Diensten hinweg entstehen können.

Für ein Schweizer KMU oder einen Asset Manager wirkt die Exponierung in beide Richtungen. Jedes Kundenportal, jedes Buchungssystem oder jeder Self-Service-Bereich, den Sie betreiben, ist jetzt dem Abtasten durch Agenten ausgesetzt, die im Auftrag gewöhnlicher Nutzer mit völlig gewöhnlichen Zielen handeln. Das sind keine Angreifer — Ihr Monitoring wird also nicht auf die Verhaltenssignale anspringen, auf die es kalibriert ist, und sie halten nicht an der Stelle inne, an der ein Mensch zögern würde.

Die zweite Richtung betrifft Ihre eigenen Mitarbeitenden. Delegiert ein Mitarbeiter eine Routineaufgabe an einen Agenten, der gegenüber einem Lieferanten- oder Partnersystem handelt, können Aktionen ausgelöst werden, die niemand autorisiert hat — die daraus resultierende Haftung ist unklar. Überschreitet ein menschlicher Assistent auf diese Weise seine Befugnisse, bestimmen etablierte Rechtsgrundsätze, ob die Person selbst oder ihr Arbeitgeber verantwortlich ist. Diese Klarheit existiert für Agenten noch nicht, und die Kette aus beteiligten Modellen und Diensten macht es im Nachhinein wirklich schwierig zu rekonstruieren, was eigentlich entschieden hat.

Was zu tun ist

Der wertvollste Test ist zugleich der einfachste. Als ein Nutzer anmelden, eine Anfrage erfassen, die auf den eigenen Datensatz dieses Nutzers wirkt, und sie dann mit den Kennungen eines zweiten Nutzers wiederholen. Gelingt das, haben Sie genau die Schwachstelle, die das Fitnessstudio hatte. Zwei Testkonten, Entwicklertools, ein Nachmittag — und es findet zuverlässig, was automatisiertes Scanning nicht findet.

Darüber hinaus sollte die Schnittstelle grundsätzlich als nicht vertrauenswürdig behandelt werden. Buchungsfenster und Sichtbarkeitsgrenzen, die nur im Frontend durchgesetzt werden, sind Vorschläge, keine Kontrollen — jede Regel muss serverseitig bei jeder Anfrage erneut geprüft werden. Kontoübergreifende Aktionen sollten einen Alarm auslösen, statt stillschweigend zu gelingen.

Schliessen Sie anschliessend die Governance-Lücken: Legen Sie eine interne Agenten-Policy fest, die regelt, gegen welche Systeme Agenten handeln dürfen, verlangen Sie menschliche Freigabe vor Zahlungen oder Stornierungen, und nutzen Sie Least-Privilege-Zugangsdaten statt einer vollständigen Nutzersitzung. Bei zugekaufter statt selbst entwickelter Portalsoftware fragen Sie den Anbieter schriftlich, ob objektbezogene Autorisierung (Object Level Authorization) getestet wurde. Die wenigsten wurden je danach gefragt — und schon die Antwort selbst ist aufschlussreich.

Kernaussage: Ein Agent, der gebeten wurde, einen Fitnesskurs zu buchen, fand eine API, die es jedem Nutzer erlaubte, die Reservierung jedes anderen Nutzers zu stornieren. Die Schwachstelle war gewöhnlich und bestand schon lange. Neu ist, dass es für ihre Entdeckung keinen versierten Angreifer mehr braucht, sondern nur einen fähigen Assistenten mit einem banalen Ziel. Testen Sie objektbezogene Autorisierung mit einem zweiten Konto, setzen Sie jede Geschäftsregel serverseitig durch, und legen Sie klare Grenzen für Agenten fest, die in Ihrem Namen handeln.