Una herramienta de automatización construida sobre Safari MCP cerró la pestaña del panel de control del desarrollador mientras esta estaba siendo leída. El incidente dejó al descubierto un fallo oculto en la protección que supuestamente debía evitar que los agentes impulsados por IA tocaran cualquier pestaña que no les perteneciera, y demuestra por qué las categorías "seguras por defecto" (safe-by-default) pueden convertirse en un riesgo.

La protección que funcionaba... hasta que dejó de hacerlo

La herramienta etiqueta cada pestaña que crea con un identificador interno. Antes de que el agente emita cualquier comando, la protección comprueba la presencia de ese marcador; si el marcador falta, la protección se niega a actuar. En la práctica, la protección impidió que el agente leyera una página que no había abierto, que es exactamente para lo que fue diseñada.

Mientras se completaba un formulario, la página redirigió a un dominio diferente. La redirección eliminó el marcador, dejando la pestaña sin etiqueta. La protección detectó la ausencia del marcador e informó: "No puedo verificar la propiedad, por lo que no leeré esta pestaña". En ese punto, la comprobación de seguridad funcionó según lo previsto.

El código de limpieza que cruzó la línea

A continuación, se ejecutó una rutina de limpieza manual destinada a cerrar pestañas huérfanas (aquellas sin marcador). La rutina le pidió a la herramienta "cerrar una pestaña" sin confirmar primero la propiedad. Debido a que la protección no pudo demostrar que la pestaña fuera propia, la herramienta recurrió a una acción por defecto: "cerrar la pestaña actual". La pestaña actual era el panel de control que el desarrollador estaba leyendo, no una pestaña huérfana.

El resultado fue una operación destructiva activada por una ruta de seguridad que debería haber sido un callejón sin salida.

Tres capas que trataron la "falta de propiedad" como un permiso

  1. Categorización de comandos – La lista que agrupaba los comandos situó close_tab bajo un grupo amplio de "gestión de pestañas". El desarrollador asumió que todo lo que había en ese grupo era inofensivo porque otros comandos (como "list tabs") solo leían información. Ninguna nota explícita señaló a close_tab como destructivo, por lo que heredó la seguridad percibida de sus elementos adyacentes.
  2. Política a nivel de extensión – La extensión de Safari que mediaba todas las acciones del navegador permitía cualquier operación cuando la sesión no poseía nada. Esa regla funciona para acciones de solo lectura, pero también abrió la puerta para que close_tab se ejecutara sin una comprobación de procedencia.
  3. Desajuste lógico – La rutina de limpieza comprobó el indicador de propiedad en una pestaña, pero luego llamó a la función de cierre en la pestaña que el navegador reportaba como "actual". El desajuste permitió que el fallo de la protección al no encontrar un marcador omitiera el comando de cierre y lo redirigiera al objetivo equivocado.

Cada capa asumió que "no hay propiedad registrada" significaba "seguro para actuar" y, en conjunto, produjeron un comando de cierre de pestañas que se ejecutó sin ninguna prueba de legitimidad.

La solución: la prueba de propiedad es obligatoria para las acciones destructivas

La lógica revisada separa las rutas de solo lectura de las destructivas. Ahora, antes de que se pueda ejecutar un comando close_tab, la herramienta debe presentar un marcador válido para la pestaña de destino. Si el marcador falta, el comando lanza un error en lugar de recurrir por defecto a la pestaña actual. La protección ya no recurre a una rama genérica de "hacer algo".

Este cambio elimina el estado ambiguo en el que la falta de un marcador podía interpretarse como "no hay nada que hacer" o "adelante, actúa". Al forzar un fallo explícito, la herramienta protege el trabajo del usuario de una pérdida accidental.

En qué deben fijarse los desarrolladores

  • No permita que el nombre de una categoría dicte la seguridad – Una etiqueta como "gestión de pestañas" no dice nada sobre el impacto de cada comando en su interior. Registre el coste de cada operación (lectura frente a destrucción) junto al propio comando.
  • Las condiciones de protección deben coincidir con la gravedad de la acción – Una comprobación que es suficiente para una solicitud de lectura no es suficiente para un comando que puede eliminar datos. Cree canales de validación separados para cada clase de impacto.
  • Evite los valores por defecto implícitos – Cuando una protección no puede verificar la propiedad, la respuesta más segura es abortar, no elegir un objetivo por defecto. Las acciones por defecto son una fuente común de errores de escalada de privilegios.
  • Audite las suposiciones de adyacencia – Revise cualquier lista o menú donde los comandos estén situados uno al lado del otro. Un comando inocuo puede heredar la confianza depositada en sus vecinos si el código no reevalúa explícitamente la seguridad.

Conclusión

La ausencia de una protección de propiedad no es un error; es un vacío de diseño. Trate cada comando destructivo como un dominio de seguridad separado que exige una prueba explícita de autoridad, y nunca permita que "sin marcador" se interprete como "adelante". Solo entonces podrán las herramientas de automatización proteger las mismas pestañas que deben gestionar.