Инструмент автоматизации, построенный на Safari MCP, закрыл вкладку с панелью управления разработчика в тот момент, когда она читалась. Инцидент выявил скрытый изъян в защитнике (guard), который должен был предотвращать доступ ИИ-агентов к любым вкладкам, им не принадлежащим, и показал, почему категории «безопасные по умолчанию» могут стать источником проблем.

Защитник, который работал — пока не перестал

Инструмент помечает каждую создаваемую им вкладку внутренним идентификатором. Прежде чем агент выполнит какую-либо команду, защитник проверяет наличие этого маркера; если маркер отсутствует, защитник отказывается действовать. На практике защитник не позволил агенту прочитать страницу, которую тот не открывал — именно так он и должен был работать.

Во время заполнения формы произошел редирект на другой домен. При перенаправлении маркер был удален, и вкладка осталась без метки. Защитник обнаружил отсутствие маркера и сообщил: «Я не могу подтвердить право владения, поэтому не буду читать эту вкладку». В этот момент проверка безопасности сработала как положено.

Код очистки, перешедший черту

Затем последовала процедура ручной очистки, предназначенная для закрытия «осиротевших» вкладок — тех, у которых нет маркера. Процедура запросила у инструмента «закрыть вкладку», не подтвердив предварительно право владения. Поскольку защитник не смог доказать, что вкладка принадлежит инструменту, тот перешел к действию по умолчанию: «закрыть текущую вкладку». Текущей вкладкой оказалась панель управления, которую читал разработчик, а не «осиротевшая» вкладка.

Результатом стала деструктивная операция, вызванная путем безопасности, который должен был стать тупиком.

Три уровня, которые восприняли «отсутствие владения» как разрешение

  1. Категоризация команд — В списке, группирующем команды, close_tab была помещена в широкий раздел «управление вкладками». Разработчик исходил из предположения, что всё в этом разделе безвредно, так как другие команды (например, list tabs) только считывают информацию. Никакой явной пометки о том, что close_tab является деструктивной, не было, поэтому она унаследовала статус «безопасной» от своих соседей.
  2. Политика на уровне расширения — Расширение Safari, которое выступало посредником во всех действиях браузера, разрешало любую операцию, если сессия не владела никакими объектами. Это правило подходит для действий «только чтение», но оно также открыло возможность для выполнения close_tab без проверки происхождения (provenance check).
  3. Логическое несоответствие — Процедура очистки проверяла флаг владения на одной вкладке, но затем вызывала функцию закрытия для вкладки, которую браузер сообщал как «текущую». Это несоответствие позволило тому факту, что защитник не нашел маркер, обойти команду закрытия и перенаправить её на неверную цель.

Каждый уровень исходил из того, что «владение не зафиксировано» означает «можно действовать», и в совокупности они создали команду закрытия вкладки, которая выполнилась без каких-либо доказательств легитимности.

Исправление: подтверждение владения обязательно для деструктивных действий

Обновленная логика разделяет пути «только чтение» и деструктивные пути. Теперь, прежде чем команда close_tab будет выполнена, инструмент должен предъявить валидный маркер для целевой вкладки. Если маркер отсутствует, команда выдает ошибку, а не переключается на текущую вкладку по умолчанию. Защитник больше не переходит к ветке общего действия «сделай что-нибудь».

Это изменение устраняет неопределенное состояние, при котором отсутствие маркера могло трактоваться либо как «делать нечего», либо как «действуй». Принудительно вызывая явную ошибку, инструмент защищает работу пользователя от случайной потери.

На что стоит обратить внимание разработчикам

  • Не позволяйте названию категории определять безопасность — Метка вроде «управление вкладками» ничего не говорит о последствиях каждой команды внутри неё. Указывайте «стоимость» каждой операции (чтение против удаления) рядом с самой командой.
  • Условия защиты должны соответствовать серьезности действия — Проверки, достаточной для запроса на чтение, недостаточно для команды, которая может удалить данные. Создавайте отдельные конвейеры валидации для каждого класса воздействия.
  • Избегайте неявных переключений на значения по умолчанию — Если защитник не может подтвердить владение, самым безопасным ответом будет отмена действия, а не выбор цели по умолчанию. Действия по умолчанию — частый источник багов, приводящих к повышению привилегий.
  • Проверяйте допущения о соседстве — Пересматривайте любые списки или меню, где команды расположены рядом друг с другом. Безобидная команда может унаследовать уровень доверия, которому пользуются её соседи, если код явно не перепроверяет безопасность.

Итог

Отсутствие защиты владения — это не баг, а пробел в проектировании. Относитесь к каждой деструктивной команде как к отдельному домену безопасности, требующему явного подтверждения полномочий, и никогда не позволяйте интерпретировать «отсутствие маркера» как «продолжайте». Только тогда инструменты автоматизации смогут защитить те самые вкладки, которыми они должны управлять.