El 26 de agosto de 2026, Anthropic anunció la disponibilidad general de Claude in Chrome para los planes de pago y la llegada de un navegador integrado en Claude Cowork. Estas herramientas pueden leer páginas, navegar entre pestañas, introducir texto y rellenar formularios con una autonomía mayor. Permiten acceder a portales internos o antiguos sin API, pero también desplazan la frontera de seguridad: el contenido de una página se convierte en una instrucción potencialmente hostil situada junto a una sesión autenticada.
Idea clave: un agente de navegador nunca debe heredar implícitamente todos los permisos de su usuario. Hay que aislar su entorno, limitar los dominios y las cuentas, clasificar las acciones por riesgo, exigir confirmación para los efectos sensibles, registrar las decisiones y verificar el resultado. Las protecciones del modelo reducen el riesgo de prompt injection, pero no lo eliminan.
1. El navegador se convierte en un entorno de ejecución
Las primeras generaciones de asistentes se limitaban a responder preguntas. Ahora un agente de navegador puede observar el estado de una página, decidir una secuencia de pasos y actuar en una aplicación. Por tanto, es comparable a un usuario automatizado con capacidades de razonamiento.
Esta evolución resulta útil para sistemas que no ofrecen ni API ni conector: un extranet de proveedores, una interfaz de administración histórica, un CRM vertical o un panel interno. El agente puede recopilar datos, preparar una entrada, recorrer varias pantallas y devolver el resultado en la misma conversación.
Pero una automatización clásica sigue un escenario escrito de antemano. El agente elige su recorrido a partir del contenido mostrado. Su flexibilidad también constituye su superficie de ataque: una información encontrada durante el recorrido puede modificar su plan.
Por tanto, hay que tratar el navegador como un runtime sensible, con políticas de acceso, entorno aislado, trazas, límites de recursos y mecanismos de parada. Añadir una extensión a un navegador de trabajo sin revisar estos elementos equivale a desplegar un nuevo robot de software con los permisos de un empleado, pero sin una gobernanza adecuada.
2. Distinguir el navegador personal del navegador aislado
Los dos anuncios de Anthropic ilustran dos modelos diferentes.
Una extensión como Claude in Chrome funciona en el contexto del navegador que ya se está utilizando. Se beneficia de las sesiones abiertas y puede intervenir en la página visible. Esta proximidad facilita las tareas diarias, pero aumenta el impacto potencial de un error: el agente puede encontrarse con el correo, un CRM y un área de administración en la misma sesión.
El navegador integrado en Cowork está separado del navegador personal. Según Anthropic, por defecto no accede a las pestañas, favoritos ni contraseñas del usuario. Las conexiones pueden importarse sitio por sitio y ciertas categorías sensibles, como la banca, el correo o el SSO, quedan excluidas salvo elección explícita.
Para una empresa, el aislamiento debería ser el modo predeterminado. Cree un perfil dedicado, sin sincronización del navegador, con un almacén de secretos separado y cuentas de servicio limitadas. El navegador personal puede seguir siendo útil para una asistencia puntual bajo supervisión, pero no debe convertirse en la base de una automatización recurrente.
La elección depende de la necesidad: ayudar a una persona en la página que ve o delegar una tarea a un entorno controlado. Confundir estos dos usos expone innecesariamente las sesiones.
3. Por qué la prompt injection cambia la amenaza
En una inyección clásica, un atacante intenta hacer que una aplicación ejecute un comando. En una prompt injection, coloca instrucciones en una página, un correo, un documento o un campo para influir en el modelo que las lee.
El contenido malicioso puede ser visible, discreto o estar integrado en un dato legítimo. Por ejemplo, el usuario pide resumir las solicitudes de los clientes; uno de los mensajes contiene una instrucción que pide al agente abrir otra pantalla y transmitir información. Para el modelo, la petición del usuario y el texto de la página pertenecen al mismo contexto de trabajo, salvo que la arquitectura imponga una separación clara.
Anthropic describe sondas que analizan el contenido y un clasificador que comprueba las acciones previstas frente a la petición inicial. El editor también precisa que estas medidas no pueden eliminar el riesgo y recomienda empezar por sitios de confianza.
Esta reserva debe guiar el diseño. Ninguna puntuación de resistencia proporcionada por un proveedor cubre sus aplicaciones, formulaciones, integraciones y permisos. La prompt injection es un problema de sistema: el modelo, las herramientas, las sesiones, los datos, la política y el control humano deben diseñarse conjuntamente.
4. Aplicar el mínimo privilegio a las sesiones web
La primera barrera es reducir los permisos accesibles para el agente.
Utilice una cuenta distinta cuando la aplicación lo permita. Retire los roles de administración, las exportaciones globales, la gestión de usuarios y las funciones financieras si la tarea no los necesita. Prefiera un perímetro de datos limitado al equipo o expediente tratado.
Defina después una lista de dominios autorizados. Una tarea en el CRM no debería poder abrir un servicio arbitrario de intercambio de archivos. Controle las redirecciones, los subdominios y las descargas, porque una página aprobada puede contener un enlace a un origen no aprobado.
Limite también los flujos de red del navegador aislado. El acceso saliente puede pasar por un proxy que registre los destinos y bloquee las categorías prohibidas. Las descargas deben analizarse y almacenarse en una zona temporal sin ejecución automática.
Los secretos no deben copiarse en el prompt ni en un archivo de configuración legible por el modelo. Utilice un mecanismo de autenticación gestionado por el navegador o un almacén que proporcione una sesión sin revelar el valor original. Debe ser posible rotarlos rápidamente si el perfil se ve comprometido.
Este enfoque prolonga los principios de nuestro artículo sobre agentes de IA zero-trust, firmas de escrituras y aislamiento del código generado: cada capacidad debe concederse explícitamente y poder verificarse.
5. Controlar las acciones, no solo las respuestas
Un agente puede formular una respuesta correcta y, al mismo tiempo, haber realizado una acción no deseada. Por tanto, la política debe aplicarse en el momento de la acción.
Clasifique las operaciones en cuatro niveles. La lectura de páginas públicas puede ser automática. La preparación de un formulario o borrador puede autorizarse sin envío. Un cambio reversible, como añadir una nota interna, requiere verificar el contenido y el destino. Una acción externa o difícil de revertir—enviar un correo, cambiar un permiso, eliminar, hacer un pedido, pagar o publicar—exige una confirmación explícita y reciente.
La confirmación debe presentar elementos concretos: dominio, cuenta, objeto modificado, valor actual, nuevo valor y consecuencias. Una pregunta genérica como «¿continuar?» no ayuda al usuario a detectar una desviación.
Después de la validación, el agente debe ejecutar únicamente la acción aprobada. No debe aprovechar la confirmación para añadir otros pasos. Las herramientas pueden imponer esquemas estrictos, listas de campos autorizados y límites de volumen.
En los procesos sensibles, separe la preparación y la ejecución. El agente prepara la transacción; un servicio determinista o una persona comprueba las reglas de negocio y realiza la escritura.
6. Registrar, verificar y prever la reversión
La trazabilidad no debe limitarse a un vídeo de la sesión. Registre la identidad del solicitante, la tarea inicial, el modelo y su versión, los dominios visitados, las herramientas llamadas, las decisiones de política, las confirmaciones, los objetos modificados y el resultado observado.
Evite, no obstante, registrar secretos o datos personales innecesarios. Las capturas de pantalla y los contenidos de las páginas deben respetar un plazo de conservación, un control de acceso y una finalidad definidos.
Después de cada escritura, el agente debe volver a leer el estado obtenido. Hacer clic en un botón no demuestra que el cambio se haya guardado. Verifique el mensaje de confirmación, el valor persistido o un identificador de transacción. Para un lote, concilie el número de elementos previstos y procesados.
Prepare un mecanismo de anulación: borrador en lugar de publicación directa, papelera en lugar de eliminación definitiva, transacción idempotente, conservación de la versión anterior o registro que permita reproducir la operación inversa. Algunas operaciones, como un correo enviado o un pago, no son realmente reversibles; deben situarse detrás del nivel de control más estricto.
7. Probar el agente como un sistema no determinista
Las pruebas funcionales habituales no son suficientes. Un agente puede elegir recorridos diferentes para la misma petición y reaccionar ante formulaciones inesperadas.
Construya un conjunto de evaluación con tareas normales, ambigüedades, errores de autenticación, redirecciones, páginas lentas y contenidos que intenten orientar al agente. Compruebe que se detiene cuando falta información, que pide confirmación en el momento adecuado y que no amplía su perímetro.
Añada casos de prompt injection adaptados a sus aplicaciones, sin exponer datos reales: instrucciones en la descripción de un ticket, un nombre de archivo, un campo del CRM, un correo o una página de documentación. Mida la tasa de bloqueo, pero también los falsos positivos que impiden el trabajo legítimo.
Pruebe cada nueva versión del modelo y cada cambio de política. Una mejora general del modelo puede modificar su interpretación de las instrucciones, su tendencia a pedir confirmación o la forma en que utiliza una herramienta.
Por último, realice una fase de observación en modo de solo lectura. Compare las decisiones propuestas por el agente con las acciones de un operador antes de autorizar escrituras.
8. Desplegar por clases de uso
Comience por tareas de bajo impacto: recopilar información pública, comprobar un estado, preparar un informe o introducir un borrador en un entorno de prueba.
La segunda etapa puede cubrir portales internos con una cuenta limitada y acciones reversibles. Mantenga la validación humana y mida el tiempo realmente ahorrado, incluida la revisión y la corrección.
Los usos que impliquen correo, datos sensibles, cambios de permisos, pedidos o finanzas deben permanecer en un perímetro separado. Exija un análisis de riesgos, un responsable de negocio, un responsable técnico, registros utilizables y un plan de incidentes.
Defina también las exclusiones: dominios no autorizados, categorías de datos, franjas horarias, volúmenes y acciones que el agente nunca realizará. Una lista clara protege mejor que un prompt general que le pida «tener cuidado».
La ampliación debe depender de pruebas: tasa de tareas completadas, errores confirmados, intervenciones humanas, incidentes de política, coste y satisfacción de los usuarios. La autonomía es un nivel de servicio que hay que ganarse, no una opción que se active globalmente.
Conclusión
Los agentes de navegador permiten automatizar aplicaciones que las integraciones tradicionales dejaban de lado. Su capacidad para utilizar sesiones existentes e interpretar páginas dinámicas aporta un valor real, pero también acerca datos no fiables a acciones autenticadas.
La seguridad debe construirse alrededor del modelo: navegador aislado, permisos mínimos, dominios autorizados, política de acciones, confirmaciones informativas, verificación del resultado y registro. Partitech acompaña el diseño de estas arquitecturas agénticas, la definición de barreras y la puesta en marcha de pilotos medibles antes de cualquier generalización.