Cuando leer una página también permite actuar

Un asistente que resume un artículo solo necesita interpretar contenido. Un agente de navegador puede ir más allá: leer páginas, navegar entre sitios y, según sus permisos, hacer clic o escribir dentro de una sesión donde la persona ya inició sesión. Esa diferencia amplía lo que puede hacer por encargo, pero también las consecuencias de un error. Google señala que los agentes pueden operar en sesiones autenticadas y que una acción no deseada podría incluir una transacción o la exposición de datos sensibles. https://developer.chrome.com/docs/agents/security https://blog.google/security/architecting-security-for-agentic/

Por eso la cuestión no es únicamente si el modelo responde bien a una pregunta, sino qué contenido ve, qué acciones tiene autorizadas y quién comprueba que cada paso corresponde al objetivo de la persona. La frontera entre leer y actuar es esencial: resumir una reseña tiene un impacto distinto de enviar un mensaje, iniciar sesión o completar un pago. La documentación de Chrome presenta sus medidas como defensas por capas, no como una propiedad mágica del modelo que vuelva inocuo cualquier texto de la web. https://blog.google/security/architecting-security-for-agentic/

La página puede contener instrucciones para el agente

La inyección indirecta de instrucciones ocurre cuando una orden dirigida al modelo aparece dentro de datos que este consulta, en vez de llegar como una instrucción directa de la persona. Puede estar en una página manipulada, en contenido de terceros incrustado o en aportes de usuarios, como comentarios y reseñas. Google describe dos riesgos concretos para herramientas web: definiciones de herramientas con instrucciones ocultas y respuestas aparentemente normales que incorporan texto hostil. https://developer.chrome.com/docs/agents/security https://blog.google/security/architecting-security-for-agentic/

El problema es que el modelo procesa texto procedente de fuentes distintas mientras intenta obedecer una tarea. Si confunde el contenido de una página con una orden legítima, puede desviarse del objetivo original. No hace falta que el sitio tenga autoridad sobre el agente: basta con que el texto influya en su planificación. Google advierte explícitamente que la naturaleza probabilística de los modelos impide garantizar la seguridad únicamente dentro del modelo. Por tanto, incluso una instrucción escondida o mezclada con información útil merece tratarse como contenido no confiable, no como una autorización del usuario. https://developer.chrome.com/docs/agents/security

Hay investigación que ilustra el alcance de esa superficie, aunque sus resultados no deben trasladarse automáticamente a todos los navegadores. Un estudio publicado como prepublicación en arXiv en mayo de 2025 examinó en modo de caja blanca un proyecto de navegación de código abierto y reportó inyección de instrucciones, unusión de validación de dominios y exposición de credenciales. Es un análisis de un proyecto y una configuración concretos: evidencia de que los fallos son posibles, no una medición universal de los agentes actuales ni una prueba sobre Chrome. https://arxiv.org/abs/2505.13076

Capas que reducen el margen de abuso

La guía de Chrome para agentes que usan WebMCP recomienda varias barreras deterministas: limitar el volumen de entrada, acotar los orígenes web con los que puede interactuar el agente y pedir confirmación antes de actuar. También aconseja distinguir las respuestas de herramientas como datos no confiables. La lógica es reducir tanto el material hostil que entra en el contexto como las rutas disponibles para que una instrucción manipuladora cause daño. Son recomendaciones de diseño para quienes construyen agentes, no una garantía de que cualquier extensión o navegador las aplique automáticamente. https://developer.chrome.com/docs/agents/security

Otra técnica descrita es el spotlighting: marcar o transformar contenido no confiable para que el modelo lo interprete como datos y no como órdenes. Chrome advierte que las opciones tienen compromisos. Delimitar texto es barato, pero puede fallar si se manipulan los delimitadores; codificarlo en Base64 dificulta ciertos trucos estructurales, aunque aumenta el consumo de contexto. En ambos casos, el sistema debe explicar al modelo cómo tratar ese contenido. Son medidas complementarias, no un filtro infalible capaz de reconocer toda intención maliciosa. https://developer.chrome.com/docs/agents/security

Google también describe una arquitectura para las capacidades agentivas de Chrome: un modelo planificador propone acciones y un componente separado, llamado User Alignment Critic, revisa si encajan con el objetivo del usuario. La empresa afirma que ese crítico recibe metadatos de la acción, no el contenido web sin filtrar, y puede rechazar propuestas. Además, los conjuntos de orígenes buscan limitar qué sitios puede leer el agente y en cuáles puede actuar. La publicación indica que la primera implementación de esa limitación era más sencilla y que el diseño seguiría ajustándose. https://blog.google/security/architecting-security-for-agentic/

Confirmaciones y límites declarados

Las confirmaciones humanas sirven como freno cuando una acción puede tener consecuencias. Google dice que su agente de Chrome pide permiso antes de ciertos sitios sensibles, antes de iniciar sesión mediante Google Password Manager y antes de acciones como compras, pagos o envío de mensajes. También menciona un registro de pasos y la posibilidad de pausar o detener la tarea. Estas son características descritas por el proveedor; no equivalen a que todas estén disponibles en cualquier región, versión o producto, ni a que la persona deba aceptar cada detalle de la misma manera. https://blog.google/security/architecting-security-for-agentic/

La propia documentación reconoce límites: los clasificadores pueden no detectar todo contenido diseñado para influir en el agente, y las defensas requieren pruebas y mejoras continuas. Google explica que emplea ejercicios automatizados de red team para generar sitios de prueba y observar si las protecciones detienen ataques. Esa evaluación ayuda a encontrar regresiones, pero una tasa de éxito medida en un conjunto de pruebas no demuestra ausencia de vulnerabilidades futuras ni cubre todas las páginas, idiomas, flujos y combinaciones de herramientas. La conclusión prudente es que las capas elevan el costo del ataque y pueden contener el impacto, no que lo vuelvan imposible. https://blog.google/security/architecting-security-for-agentic/

Qué puede hacer la persona usuaria

Antes de delegar, conviene revisar qué permisos solicita el navegador o la extensión y limitar el acceso a los sitios que realmente necesita la tarea. Si una función puede enviar datos, modificar una cuenta o realizar una compra, es razonable mantener la supervisión y comprobar el destinatario, los campos y el resultado antes de confirmar. La guía de Chrome recomienda acotar los orígenes y solicitar confirmación para acciones; no se trata de trasladar toda la responsabilidad a la persona, sino de conservar un punto de control sobre efectos difíciles de revertir. https://developer.chrome.com/docs/agents/security

También ayuda separar tareas de bajo impacto —por ejemplo, organizar información pública— de operaciones con credenciales, datos médicos, información financiera o mensajes privados. Si un agente encuentra una instrucción inesperada en una página, no debería asumirse que forma parte de la petición original. Es preferible detenerse y revisar qué acción se propone. La supervisión reduce exposición, pero no sustituye controles técnicos: la guía oficial insiste en barreras de origen, evaluación periódica y confirmaciones, mientras que la investigación disponible muestra que los fallos pueden aparecer en distintos componentes del sistema. No hay base para prometer protección absoluta. https://developer.chrome.com/docs/agents/security https://arxiv.org/abs/2505.13076