Uno strumento di automazione basato su Safari MCP ha chiuso la scheda della dashboard dello sviluppatore mentre veniva letta. L'incidente ha messo in luce un difetto nascosto nel guard che avrebbe dovuto impedire agli agenti guidati dall'IA di toccare qualsiasi scheda non di loro proprietà, e dimostra perché le categorie "safe-by-default" possono rappresentare un rischio.

Il guard che funzionava — finché non ha smesso di farlo

Lo strumento appone a ogni scheda creata un identificatore interno. Prima che l'agente emetta qualsiasi comando, il guard controlla la presenza di tale marker; se il marker è assente, il guard rifiuta di agire. In pratica, il guard ha impedito all'agente di leggere una pagina che non aveva aperto — esattamente ciò per cui era stato progettato.

Mentre si compilava un modulo, la pagina è stata reindirizzata a un dominio diverso. Il reindirizzamento ha rimosso il marker, lasciando la scheda senza etichetta. Il guard ha rilevato la mancanza del marker e ha segnalato: "Non posso verificare la proprietà, quindi non leggerò questa scheda". A quel punto, il controllo di sicurezza si è comportato come previsto.

Il codice di pulizia che ha superato il limite

Successivamente è intervenuta una routine di pulizia manuale destinata a chiudere le schede "orfane" — quelle prive di marker. La routine ha chiesto allo strumento di "chiudere una scheda" senza prima confermarne la proprietà. Poiché il guard non poteva dimostrare che la scheda fosse propria, lo strumento è passato a un'azione predefinita: "chiudi la scheda corrente". La scheda corrente era la dashboard che lo sviluppatore stava leggendo, non una scheda orfana.

Il risultato è stata un'operazione distruttiva innescata da un percorso di sicurezza che avrebbe dovuto essere un vicolo cieco.

Tre livelli che hanno interpretato l'assenza di proprietà come un permesso

  1. Categorizzazione dei comandi – La lista che raggruppava i comandi inseriva close_tab sotto una generica categoria "tab management". Lo sviluppatore ha dato per scontato che tutto in quella categoria fosse innocuo perché altri comandi (come list tabs) eseguivano solo operazioni di lettura. Nessuna nota esplicita segnalava close_tab come distruttivo, quindi ha ereditato la sicurezza percepita dei comandi adiacenti.
  2. Policy a livello di estensione – L'estensione Safari che mediava tutte le azioni del browser consentiva qualsiasi operazione quando la sessione non possedeva nulla. Questa regola funziona per le azioni di sola lettura, ma ha anche aperto la porta all'esecuzione di close_tab senza un controllo di provenienza.
  3. Incongruenza logica – La routine di pulizia ha controllato il flag di proprietà su una scheda, ma ha poi chiamato la funzione di chiusura sulla scheda che il browser riportava come "corrente". L'incongruenza ha permesso al fallimento del guard nel trovare un marker di bypassare il comando di chiusura e reindirizzarlo verso il bersaglio sbagliato.

Ogni livello ha dato per assunto che "nessuna proprietà registrata" significasse "sicuro agire", e insieme hanno prodotto un comando di chiusura scheda che è stato eseguito senza alcuna prova di legittimità.

La soluzione: la prova di proprietà è obbligatoria per le azioni distruttive

La logica rivista separa i percorsi di sola lettura da quelli distruttivi. Ora, prima che un comando close_tab possa essere eseguito, lo strumento deve presentare un marker valido per la scheda di destinazione. Se il marker è assente, il comando genera un errore invece di passare per impostazione predefinita alla scheda corrente. Il guard non ricorre più a un ramo generico di tipo "fai qualcosa".

Questa modifica elimina lo stato ambiguo in cui la mancanza di un marker poteva essere interpretata sia come "nulla da fare" sia come "procedi pure". Imponendo un fallimento esplicito, lo strumento protegge il lavoro dell'utente dalla perdita accidentale.

A cosa dovrebbero prestare attenzione gli sviluppatori

  • Non lasciare che il nome di una categoria detti la sicurezza – Un'etichetta come "tab management" non dice nulla sull'impatto di ogni comando al suo interno. Registra il costo di ogni operazione (lettura vs. distruzione) accanto al comando stesso.
  • Le condizioni del guard devono corrispondere alla gravità dell'azione – Un controllo sufficiente per una richiesta di lettura non è abbastanza per un comando che può eliminare dati. Crea pipeline di validazione separate per ogni classe di impatto.
  • Evita i fallback impliciti – Quando un guard non può verificare la proprietà, la risposta più sicura è l'aborto, non la scelta di un bersaglio predefinito. Le azioni predefinite sono una fonte comune di bug di escalation dei privilegi.
  • Verifica le assunzioni di adiacenza – Esamina qualsiasi elenco o menu in cui i comandi siano posizionati l'uno accanto all'altro. Un comando innocuo può ereditare la fiducia riposta nei suoi vicini se il codice non rivaluta esplicitamente la sicurezza.

Conclusione

La mancanza di un controllo sulla proprietà non è un bug; è un vuoto di progettazione. Tratta ogni comando distruttivo come un dominio di sicurezza separato che richiede una prova esplicita di autorità, e non lasciare mai che "nessun marker" venga interpretato come "procedi pure". Solo allora gli strumenti di automazione potranno proteggere proprio quelle schede che dovrebbero gestire.