Stagehand 3.7 pone límites al navegador del agente: políticas de dominio y CUA
Browserbase lanzó Stagehand 3.7 con políticas para permitir o bloquear dominios que un browser agent puede visitar. La mejora parece pequeña, pero convierte una navegación abierta en una superficie que puedes gobernar, probar y revisar.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
Browserbase publicó el 13 de julio de 2026 Stagehand 3.7. La novedad que merece atención no es otro modelo de computer use: es setDomainPolicy(), una forma de permitir o bloquear los dominios que un browser agent puede visitar. Cuando una ventana emergente intenta llevar la sesión fuera de la política, Stagehand la cierra automáticamente.
Ese cambio responde a un problema concreto. Un agente que navega con una instrucción amplia puede empezar en tu aplicación, seguir un enlace de terceros, aterrizar en una página de autenticación inesperada y continuar como si toda la web fuera parte del mismo perímetro. El modelo puede tener buenas intenciones y aun así cruzar una frontera que tu producto nunca quiso abrir.
La política es una frontera, no un prompt
La API nueva permite expresar la frontera en código:
await stagehand.context.setDomainPolicy({
allowedDomains: ["app.example.com", "docs.example.com"],
});
El valor está en que la decisión vive al nivel de la sesión y no únicamente en las instrucciones del modelo. El prompt puede decir “usa solo estos sitios”, pero la política añade una comprobación externa al razonamiento. Esa separación es importante para tareas que rellenan formularios, revisan portales internos o trabajan con una identidad persistente.
La política tampoco convierte cada navegación en segura por defecto. Debes decidir si permites subdominios, redirecciones, dominios de proveedores de identidad o recursos externos necesarios para que la página funcione. Un allowlist demasiado corto rompe el flujo; uno demasiado amplio vuelve a crear una zona gris.
Qué cambia en Stagehand 3.7
El changelog también añade modelos de CUA como google/gemini-3.5-flash y la familia GPT-5.6, corrige combinaciones de teclas para acciones de teclado y arregla un problema al pasar un cliente MCP a agent({ integrations }). Son mejoras útiles, pero la política de dominio es la que cambia el contrato de seguridad.
La secuencia que probaría en un proyecto nuevo es:
- inicia una sesión con el mínimo de dominios necesarios;
- registra cada navegación, redirección y popup bloqueado;
- prueba rutas de login, pagos, descargas y dominios de soporte por separado;
- convierte cada excepción aprobada en una prueba de regresión;
- deja la intervención humana para cambios de política, no para cada clic rutinario.
El detalle que suele romper el experimento
Un agente no visita dominios solo cuando ejecuta goto. También puede seguir un enlace, abrir una ventana nueva, cargar un recurso remoto o recibir una redirección desde un proveedor externo. Por eso una prueba feliz que llega a app.example.com no basta. Necesitas casos de salida: popup malicioso, enlace de documentación que cambia de host, OAuth con dominio permitido y descarga que redirige a un CDN.
También separaría dos permisos que suelen mezclarse:
- dónde puede navegar el agente;
- qué puede hacer una vez que está allí.
La primera pregunta la cubre la política de dominio. La segunda exige permisos de aplicación, herramientas de solo lectura, confirmación para operaciones destructivas y secretos inyectados en tiempo de ejecución. La documentación de seguridad de Browserbase insiste en que el navegador debe ser aislado y observable; la política ayuda, pero no sustituye ese diseño.
La intención de búsqueda es clara en queries como Stagehand domain policies, browser agent allowlist, browser agent security y setDomainPolicy. No hay volumen SEO conectado para inventar una cifra. La demanda se infiere del changelog reciente, la documentación de Stagehand y el problema práctico de gobernar agentes que ya pueden navegar por sitios dinámicos.
Si estás empezando a separar tools, permisos y revisión, el curso gratis te da la base. La lectura corta: darle un navegador a un agente es una decisión de infraestructura; decirle por qué sitios puede pasar es una política de producto.