Een automatiseringstool gebouwd op Safari MCP sloot het dashboard-tabblad van de ontwikkelaar terwijl dit werd gelezen. Het incident legde een verborgen gebrek bloot in de guard die AI-gestuurde agenten ervan moest weerhouden tabbladen aan te raken die niet van hen waren, en het laat zien waarom "safe-by-default"-categorieën een risico kunnen vormen.

De guard die werkte — tot het niet meer zo was

De tool markeert elk tabblad dat hij aanmaakt met een interne identifier. Voordat de agent een commando geeft, controleert de guard op die marker; als de marker ontbreekt, weigert de guard actie te ondernemen. In de praktijk voorkwam de guard dat de agent een pagina las die hij niet zelf had geopend — precies waarvoor hij ontworpen was.

Tijdens het invullen van een formulier werd de pagina doorgeleid naar een ander domein. De redirect verwijderde de marker, waardoor het tabblad ongelabeld bleef. De guard zag de ontbrekende marker en meldde: "Ik kan het eigendom niet verifiëren, dus ik zal dit tabblad niet lezen." Op dat moment werkte de veiligheidscontrole zoals bedoeld.

De cleanup-code die de grens overschreed

Vervolgens kwam er een handmatige cleanup-routine die bedoeld was om 'orphaned tabs' (verweesde tabbladen) te sluiten — tabbladen zonder marker. De routine vroeg de tool om "een tabblad te sluiten" zonder eerst het eigendom te bevestigen. Omdat de guard niet kon bewijzen dat het tabblad van de tool zelf was, viel de tool terug op een standaardactie: "sluit het huidige tabblad". Het huidige tabblad was het dashboard dat de ontwikkelaar aan het lezen was, niet een verweesd tabblad.

Het resultaat was een destructieve operatie, getriggerd door een veiligheidstraject dat een doodlopende weg had moeten zijn.

Drie lagen die "geen eigendom" behandelden als toestemming

  1. Command categorisatie – De lijst die commando's groepeerde, plaatste close_tab onder een brede categorie "tab management". De ontwikkelaar ging ervan uit dat alles in die categorie onschadelijk was, omdat andere commando's (zoals "list tabs") alleen informatie lazen. Er was geen expliciete melding die close_tab als destructief markeerde, waardoor het de vermeende veiligheid van de omliggende commando's erfde.
  2. Beleid op extensieniveau – De Safari-extensie die alle browseracties bemiddelde, stond elke operatie toe wanneer de sessie niets in eigendom had. Die regel werkt voor read-only acties, maar het opende ook de deur voor de uitvoering van close_tab zonder een herkomstcontrole (provenance check).
  3. Logica-mismatch – De cleanup-routine controleerde de eigenschapsvlag op het ene tabblad, maar riep vervolgens de sluitfunctie aan op het tabblad dat de browser als "huidig" rapporteerde. De mismatch zorgde ervoor dat het niet vinden van een marker door de guard het sluitcommando omzeilde en naar het verkeerde doel leidde.

Elke laag ging ervan uit dat "geen eigendom geregistreerd" betekende "veilig om actie te ondernemen", en samen produceerden ze een commando om een tabblad te sluiten dat werd uitgevoerd zonder enig bewijs van legitimiteit.

De oplossing: eigendomsbewijs is verplicht voor destructieve acties

De herziene logica scheidt read-only paden van destructieve paden. Nu, voordat een close_tab commando kan worden uitgevoerd, moet de tool een geldige marker voor het doel-tabblad presenteren. Als de marker ontbreekt, geeft het commando een foutmelding in plaats van terug te vallen op het huidige tabblad. De guard valt niet langer terug op een generieke "doe iets"-tak.

Deze wijziging verwijdert de ambigue staat waarin een ontbrekende marker gelezen kon worden als ofwel "niets te doen" of "ga maar aan de slag". Door een expliciet falen af te dwingen, beschermt de tool het werk van de gebruiker tegen onbedoeld verlies.

Waar ontwikkelaars op moeten letten

  • Laat een categorienaam de veiligheid niet bepalen – Een label als "tab management" zegt niets over de impact van elk commando daarin. Noteer de impact van elke operatie (lezen vs. vernietigen) naast het commando zelf.
  • Guard-voorwaarden moeten overeenkomen met de ernst van de actie – Een controle die voldoende is voor een leesverzoek, is niet genoeg voor een commando dat gegevens kan verwijderen. Bouw aparte validatiepijplijnen voor elke klasse van impact.
  • Vermijd impliciete fallbacks – Wanneer een guard het eigendom niet kan verifiëren, is de veiligste reactie om af te breken, in plaats van een standaarddoel te kiezen. Standaardacties zijn een veelvoorkomende bron van bugs die leiden tot privilege-escalatie.
  • Controleer aannames over nabijheid – Loop alle lijsten of menu's na waarin commando's naast elkaar staan. Een onschuldig commando kan het vertrouwen van zijn buren erven als de code de veiligheid niet expliciet opnieuw evalueert.

Conclusie

Een ontbrekende eigendomsguard is geen bug; het is een ontwerpgat. Behandel elk destructief commando als een apart beveiligingsdomein dat expliciet bewijs van autoriteit vereist, en laat "geen marker" nooit interpreteren als "ga maar aan de slag". Pas dan kunnen automatiseringstools de tabbladen beschermen die ze juist bedoeld zijn te beheren.