Ein auf Safari MCP basierendes Automatisierungstool schloss den Dashboard-Tab des Entwicklers, während dieser gerade gelesen wurde. Der Vorfall legte einen versteckten Fehler in der Schutzinstanz (Guard) offen, die KI-gesteuerte Agenten eigentlich daran hindern sollte, Tabs zu berühren, die nicht ihnen gehörten. Er zeigt auf, warum „safe-by-default“-Kategorien zu einer Belastung werden können.

Die Schutzinstanz, die funktionierte – bis sie es nicht mehr tat

Das Tool versieht jeden von ihm erstellten Tab mit einer internen Kennung. Bevor der Agent einen Befehl ausführt, prüft die Schutzinstanz auf dieses Markierungszeichen; fehlt die Kennung, verweigert die Instanz die Ausführung. In der Praxis verhinderte die Schutzinstanz, dass der Agent eine Seite las, die er nicht selbst geöffnet hatte – genau das, wofür sie entwickelt worden war.

Beim Ausfüllen eines Formulars wurde die Seite auf eine andere Domain umgeleitet. Durch die Weiterleitung wurde die Kennung entfernt, sodass der Tab unbeschriftet blieb. Die Schutzinstanz bemerkte die fehlende Kennung und meldete: „Ich kann die Inhaberschaft nicht verifizieren, daher werde ich diesen Tab nicht lesen.“ Zu diesem Zeitpunkt verhielt sich die Sicherheitsprüfung wie vorgesehen.

Der Bereinigungscode, der die Grenze überschritt

Als Nächstes folgte eine manuelle Bereinigungsroutine, die dazu gedacht war, „verwaiste“ Tabs zu schließen – also solche ohne Kennung. Die Routine wies das Tool an, einen „Tab zu schließen“, ohne zuvor die Inhaberschaft zu bestätigen. Da die Schutzinstanz nicht beweisen konnte, dass der Tab ihr gehörte, griff das Tool auf eine Standardaktion zurück: „den aktuellen Tab schließen“. Der aktuelle Tab war jedoch das Dashboard, das der Entwickler gerade las, und kein verwaister Tab.

Das Ergebnis war eine destruktive Operation, die durch einen Sicherheitspfad ausgelöst wurde, der eigentlich eine Sackgasse hätte sein sollen.

Drei Ebenen, die „keine Inhaberschaft“ als Erlaubnis behandelten

  1. Befehlskategorisierung – Die Liste, die die Befehle gruppierte, ordnete close_tab einem breiten Bereich namens „tab management“ zu. Der Entwickler ging davon aus, dass alles in diesem Bereich harmlos sei, da andere Befehle (wie „list tabs“) lediglich Informationen auslesen. Da kein expliziter Hinweis close_tab als destruktiv kennzeichnete, übernahm der Befehl die vermeintliche Sicherheit seiner Nachbarbefehle.
  2. Richtlinie auf Extension-Ebene – Die Safari-Extension, die alle Browser-Aktionen vermittelte, erlaubte jede Operation, wenn die Sitzung keinerlei Inhaberschaft besaß. Diese Regel funktioniert bei schreibgeschützten Aktionen gut, öffnete aber auch die Tür für die Ausführung von close_tab ohne Herkunftsprüfung.
  3. Logik-Fehlanpassung – Die Bereinigungsroutine prüfte das Inhaberschafts-Flag eines Tabs, rief dann aber die Schließfunktion für den Tab auf, den der Browser als „aktuell“ meldete. Diese Diskrepanz führte dazu, dass das Scheitern der Schutzinstanz beim Finden einer Kennung den Schließbefehl umging und ihn auf das falsche Ziel umleitete.

Jede Ebene ging davon aus, dass „keine Inhaberschaft registriert“ gleichbedeutend mit „sicherer Ausführung“ sei, und zusammen erzeugten sie einen Befehl zum Schließen eines Tabs, der ohne jeglichen Legitimitätsnachweis ausgeführt wurde.

Die Lösung: Inhaberschaftsnachweis ist für destruktive Aktionen zwingend erforderlich

Die überarbeitete Logik trennt schreibgeschützte Pfade von destruktiven Pfaden. Bevor ein close_tab-Befehl nun ausgeführt werden kann, muss das Tool eine gültige Kennung für den Ziel-Tab vorweisen. Falls die Kennung fehlt, wirft der Befehl einen Fehler aus, anstatt auf den aktuellen Tab zurückzugreifen. Die Schutzinstanz fällt nicht mehr auf einen generischen „etwas tun“-Zweig zurück.

Diese Änderung beseitigt den mehrdeutigen Zustand, in dem eine fehlende Kennung entweder als „nichts zu tun“ oder als „bitte fortfahren“ interpretiert werden konnte. Durch das Erzwingen eines expliziten Fehlers schützt das Tool die Arbeit des Benutzers vor versehentlichem Verlust.

Worauf Entwickler achten sollten

  • Lassen Sie nicht zu, dass ein Kategoriename die Sicherheit bestimmt – Eine Bezeichnung wie „tab management“ sagt nichts über die Auswirkungen der darin enthaltenen Befehle aus. Dokumentieren Sie die „Kosten“ jeder Operation (lesen vs. zerstören) direkt neben dem Befehl selbst.
  • Schutzbedingungen müssen der Schwere der Aktion entsprechen – Eine Prüfung, die für eine Leseanfrage ausreicht, genügt nicht für einen Befehl, der Daten löschen kann. Erstellen Sie separate Validierungspipelines für jede Wirkungsklasse.
  • Vermeiden Sie implizite Fallbacks – Wenn eine Schutzinstanz die Inhaberschaft nicht verifizieren kann, ist die sicherste Reaktion der Abbruch und nicht die Wahl eines Standardziels. Standardaktionen sind eine häufige Quelle für Bugs bei der Privilegieneskalation.
  • Prüfen Sie Annahmen über benachbarte Befehle – Überprüfen Sie alle Listen oder Menüs, in denen Befehle nebeneinander stehen. Ein harmloser Befehl kann das Vertrauen übernehmen, das seinen Nachbarn entgegengebracht wird, wenn der Code die Sicherheit nicht explizit neu bewertet.

Fazit

Eine fehlende Inhaberschaftsprüfung ist kein Bug, sondern eine Designlücke. Behandeln Sie jeden destruktiven Befehl als eine separate Sicherheitsdomäne, die einen expliziten Autorisierungsnachweis erfordert, und lassen Sie niemals zu, dass „keine Kennung“ als „bitte fortfahren“ interpretiert wird. Nur so können Automatisierungstools genau die Tabs schützen, die sie eigentlich verwalten sollen.