Uma ferramenta de automação construída sobre o Safari MCP fechou a aba do painel do desenvolvedor enquanto ela estava sendo lida. O incidente expôs uma falha oculta no mecanismo de proteção que deveria impedir que agentes baseados em IA tocassem em qualquer aba que não lhes pertencesse, e mostra por que categorias “seguras por padrão” (safe-by-default) podem ser um risco.

O mecanismo de proteção que funcionava — até que parou de funcionar

A ferramenta marca cada aba que cria com um identificador interno. Antes de o agente emitir qualquer comando, o mecanismo de proteção verifica esse marcador; se o marcador estiver ausente, o mecanismo se recusa a agir. Na prática, o mecanismo impediu que o agente lesse uma página que não havia aberto — exatamente o que foi projetado para fazer.

Ao preencher um formulário, a página foi redirecionada para um domínio diferente. O redirecionamento removeu o marcador, deixando a aba sem etiqueta. O mecanismo de proteção detectou a ausência do marcador e relatou: “Não posso verificar a propriedade, portanto não lerei esta aba”. Naquele momento, a verificação de segurança comportou-se como pretendido.

O código de limpeza que passou dos limites

Em seguida, veio uma rotina de limpeza manual destinada a fechar abas órfãs — aquelas sem um marcador. A rotina solicitou à ferramenta para “fechar uma aba” sem antes confirmar a propriedade. Como o mecanismo de proteção não pôde provar que a aba era sua, a ferramenta recorreu a uma ação padrão: “fechar a aba atual”. A aba atual era o painel que o desenvolvedor estava lendo, não uma aba órfã.

O resultado foi uma operação destrutiva acionada por um caminho de segurança que deveria ter sido um beco sem saída.

Três camadas que trataram a “falta de propriedade” como permissão

  1. Categorização de comandos – A lista que agrupava comandos colocou o close_tab sob um amplo grupo de “gerenciamento de abas”. O desenvolvedor assumiu que tudo naquele grupo era inofensivo porque outros comandos (como “list tabs”) apenas liam informações. Nenhuma nota explícita sinalizou o close_tab como destrutivo, então ele herdou a segurança percebida de seus vizinhos.
  2. Política ao nível da extensão – A extensão do Safari que mediava todas as ações do navegador permitia qualquer operação quando a sessão não possuía nada. Essa regra funciona para ações de apenas leitura, mas também abriu as portas para que o close_tab fosse executado sem uma verificação de procedência.
  3. Incompatibilidade de lógica – A rotina de limpeza verificou a flag de propriedade em uma aba, mas depois chamou a função de fechar na aba que o navegador reportou como “atual”. A incompatibilidade permitiu que a falha do mecanismo de proteção em encontrar um marcador contornasse o comando de fechamento e o redirecionasse para o alvo errado.

Cada camada assumiu que “nenhuma propriedade registrada” significava “seguro para agir” e, juntas, produziram um comando de fechamento de aba que foi executado sem qualquer prova de legitimidade.

A correção: a prova de propriedade é obrigatória para ações destrutivas

A lógica revisada separa os caminhos de apenas leitura dos caminhos destrutivos. Agora, antes que um comando close_tab possa ser executado, a ferramenta deve apresentar um marcador válido para a aba de destino. Se o marcador estiver ausente, o comando gera um erro em vez de recorrer à aba atual por padrão. O mecanismo de proteção não recorre mais a um ramo genérico de “fazer algo”.

Essa mudança remove o estado ambíguo em que a ausência de um marcador poderia ser interpretada como “nada a fazer” ou “prossiga e aja”. Ao forçar uma falha explícita, a ferramenta protege o trabalho do usuário contra perdas acidentais.

O que os desenvolvedores devem observar

  • Não deixe que o nome de uma categoria dite a segurança – Um rótulo como “gerenciamento de abas” não diz nada sobre o impacto de cada comando dentro dele. Registre o custo de cada operação (leitura vs. destruição) ao lado do próprio comando.
  • As condições do mecanismo de proteção devem corresponder à gravidade da ação – Uma verificação que é suficiente para uma solicitação de leitura não é suficiente para um comando que pode excluir dados. Construa pipelines de validação separados para cada classe de impacto.
  • Evite retornos (fallbacks) implícitos – Quando um mecanismo de proteção não consegue verificar a propriedade, a resposta mais segura é abortar, não escolher um alvo padrão. Ações padrão são uma fonte comum de bugs de escalonamento de privilégios.
  • Audite suposições de adjacência – Revise qualquer lista ou menu onde os comandos estejam posicionados próximos uns dos outros. Um comando inócuo pode herdar a confiança depositada em seus vizinhos se o código não reavaliar explicitamente a segurança.

Conclusão

A ausência de um mecanismo de proteção de propriedade não é um bug; é uma lacuna de design. Trate cada comando destrutivo como um domínio de segurança separado que exige prova explícita de autoridade e nunca permita que “nenhum marcador” seja interpretado como “prossiga”. Só assim as ferramentas de automação poderão proteger as próprias abas que deveriam gerenciar.