An automation tool built on Safari MCP closed the developer’s dashboard tab while it was being read. The incident exposed a hidden flaw in the guard that was supposed to keep AI-driven agents from touching any tab that didn’t belong to them, and it shows why “safe-by-default” categories can be a liability.

The guard that worked—until it didn’t

The tool tags every tab it creates with an internal identifier. Before the agent issues any command, the guard checks for that marker; if the marker is missing, the guard refuses to act. In practice, the guard stopped the agent from reading a page it didn’t open—exactly what it was designed to do.

While filling out a form, the page redirected to a different domain. The redirect stripped the marker, leaving the tab unlabelled. The guard saw the missing marker and reported, “I cannot verify ownership, so I will not read this tab.” At that point the safety check behaved as intended.

The cleanup code that crossed the line

Next came a manual cleanup routine meant to close orphaned tabs—those without a marker. The routine asked the tool to “close a tab” without first confirming ownership. Because the guard could not prove the tab was its own, the tool fell back to a default action: “close the current tab.” The current tab was the dashboard the developer was reading, not an orphaned one.

The result was a destructive operation triggered by a safety path that should have been a dead end.

Three layers that treated “no ownership” as permission

  1. Command categorisation – The list that grouped commands placed close_tab under a broad “tab management” bucket. The developer assumed everything in that bucket was harmless because other commands (like “list tabs”) only read information. No explicit note flagged close_tab as destructive, so it inherited the perceived safety of its neighbours.
  2. Extension-level policy – The Safari extension that mediated all browser actions allowed any operation when the session owned nothing. That rule works for read-only actions, but it also opened the door for close_tab to execute without a provenance check.
  3. Logic mismatch – The cleanup routine checked the ownership flag on one tab but then called the close function on the tab the browser reported as “current.” The mismatch let the guard’s failure to find a marker bypass the close command and redirect it to the wrong target.

Each layer assumed that “no ownership recorded” meant “safe to act,” and together they produced a tab-closing command that ran without any proof of legitimacy.

The fix: ownership proof is mandatory for destructive actions

The revised logic separates read-only paths from destructive ones. Now, before a close_tab command can execute, the tool must present a valid marker for the target tab. If the marker is missing, the command throws an error instead of defaulting to the current tab. The guard no longer falls back to a generic “do something” branch.

This change removes the ambiguous state where a missing marker could be read as either “nothing to do” or “go ahead and act.” By forcing an explicit failure, the tool protects the user’s work from accidental loss.

What developers should watch for

  • Don’t let a category name dictate safety – A label like “tab management” says nothing about the impact of each command inside it. Record the cost of each operation (read vs. destroy) next to the command itself.
  • Guard conditions must match the severity of the action – A check that is sufficient for a read request is not enough for a command that can delete data. Build separate validation pipelines for each class of impact.
  • Avoid implicit fallbacks – When a guard cannot verify ownership, the safest response is to abort, not to choose a default target. Default actions are a common source of privilege-escalation bugs.
  • Audit adjacency assumptions – Review any list or menu where commands sit next to each other. An innocuous command can inherit the trust placed in its neighbours if the code does not explicitly re-evaluate safety.

Takeaway

A missing ownership guard is not a bug; it is a design gap. Treat every destructive command as a separate security domain that demands explicit proof of authority, and never let “no marker” be interpreted as “go ahead.” Only then can automation tools protect the very tabs they are meant to manage.