Los agentes de navegador de Amazon y Google afrontan un problema de prompt injection sin una solución perfecta

Los agentes de navegador de Amazon y Google afrontan ahora el mismo conflicto: una mayor autonomía da a los ataques de prompt injection más margen para causar daños. A pesar de las nuevas salvaguardas, los investigadores siguen encontrando formas de dirigir a los agentes mediante páginas web, correos electrónicos, formularios y publicaciones en redes sociales ordinarios. La debilidad se está convirtiendo en una limitación duradera del diseño de los navegadores con IA, no en otro fallo de navegador que espera una solución única y definitiva.

La preocupación inmediata es la prompt injection indirecta, en la que instrucciones hostiles se ocultan dentro del contenido que lee un agente de IA. Esas instrucciones pueden competir con la solicitud del usuario e influir en la siguiente acción del agente. Un navegador convencional muestra el contenido hostil. Un navegador agéntico puede interpretarlo, acceder a otro servicio y actuar con la autoridad del usuario.

Esta diferencia sitúa a Amazon y Google en una competencia de seguridad más amplia que involucra a Microsoft, OpenAI, Anthropic, Perplexity y proveedores especializados de navegadores. Cada empresa quiere agentes capaces de completar tareas útiles en la web. Sin embargo, cada permiso adicional amplía las consecuencias cuando un agente malinterpreta a quién debe obedecer.

La conclusión inquietante no es que los agentes de navegador sean inutilizables. Es que los proveedores no pueden considerar la detección de prompt injection como una frontera de seguridad completa. Las empresas deben asumir que algunas instrucciones maliciosas lograrán pasar y limitar aquello a lo que un agente comprometido puede acceder, modificar o divulgar.

Qué ha cambiado en la carrera por la seguridad de los navegadores de Amazon y Google

La prompt injection ha pasado de ser una debilidad teórica de los modelos a un problema operativo de seguridad en los navegadores.

Los investigadores de seguridad han demostrado repetidamente que el contenido malicioso puede redirigir a un agente sin explotar la vía tradicional de ejecución de código del navegador. En su lugar, el atacante apunta a la interpretación que el modelo hace del contenido. Una instrucción oculta puede aparecer en una página web, un correo electrónico, un documento o incluso un elemento de la interfaz de usuario.

El ataque se vuelve grave cuando el agente puede usar sesiones autenticadas del navegador. Podría leer una bandeja de entrada, abrir otra pestaña, enviar un formulario o recuperar información de un servicio conectado. Las acciones que parecen prácticas durante una tarea normal se convierten en componentes útiles dentro de una cadena de ataque.

Investigadores de Zenity describieron esta clase más amplia de debilidades de los navegadores agénticos como PleaseFix. Sus pruebas se dirigieron a la forma en que los agentes siguen objetivos en lenguaje natural mientras se desplazan entre sitios web y recursos locales. Según los hallazgos sobre seguridad de navegadores, los investigadores encontraron distintos diseños y salvaguardas, pero aun así identificaron rutas de ataque en navegadores agénticos comerciales.

El cambio importante está en la vía del atacante. Los ataques tradicionales contra navegadores suelen depender de una vulnerabilidad de software, una extensión maliciosa, una credencial robada o un clic engañoso. La prompt injection puede comenzar con contenido que se esperaba que el agente procesara durante una solicitud ordinaria.

Un usuario podría pedir a un asistente que resuma una página de producto. La página podría contener instrucciones ocultas visualmente pero que siguen estando disponibles para el modelo. Un atacante también podría colocar instrucciones dentro de una publicación pública, un formulario de suscripción a un boletín o contenido recuperado mediante una herramienta de navegador.

Esto no garantiza que todas las instrucciones inyectadas tengan éxito. Los modelos, clasificadores, sistemas de permisos y comprobaciones de acciones pueden detener muchos intentos. El problema es que estos controles operan frente a un adversario adaptable que puede revisar la redacción, la presentación, el momento y el contexto.

Las propias mediciones de Google refuerzan ese cambio. Sus equipos de seguridad analizaron contenido web público en busca de patrones conocidos de prompt injection indirecta e informaron de un aumento relativo del 32 por ciento en las detecciones maliciosas entre noviembre de 2025 y febrero de 2026. La empresa también encontró una cantidad considerable de texto benigno que se parecía a los ataques, lo que complica una clasificación fiable.

Esa investigación sobre amenazas web importa porque una defensa del navegador debe gestionar dos errores contrapuestos. Si no detecta contenido hostil, un agente puede ser manipulado. Si bloquea de forma demasiado agresiva, las páginas rutinarias y las instrucciones legítimas se vuelven inutilizables.

Amazon aborda el problema a través de su plataforma de agentes en la nube, en lugar de mediante un navegador de consumo masivo. Bedrock AgentCore Browser ofrece a los desarrolladores un entorno aislado para agentes que navegan por sitios, completan formularios y extraen información. Esas capacidades siguen exponiendo a los agentes a contenido no confiable, incluso cuando la sesión subyacente del navegador está aislada.

Por tanto, la comparación entre Amazon y Google refleja dos modelos de distribución diferentes. Google está incorporando funciones agénticas a un navegador que las personas usan directamente. Amazon proporciona infraestructura que las empresas utilizan para crear su propia automatización de navegadores. Ambas deben gestionar la misma colisión entre el contenido de la web abierta y las acciones privilegiadas de los agentes.

Por qué los agentes de navegador debilitan una antigua frontera de seguridad

La debilidad central aparece cuando un mismo modelo recibe instrucciones de confianza y datos no confiables mediante un proceso de razonamiento compartido.

Los navegadores web han dedicado décadas a separar unos sitios web de otros. La política del mismo origen generalmente impide que un origen lea libremente información sensible de otro. Los entornos aislados, las solicitudes de permisos, el aislamiento de procesos y las políticas de seguridad de contenido añaden más barreras.

Un agente de IA puede cruzar esas fronteras porque el usuario lo autoriza a realizar una tarea. Puede leer una página, consultar otro servicio y combinar los resultados. Esa capacidad es el principal beneficio del producto, pero también crea un puente que el contenido hostil puede intentar controlar.

El modelo no necesita vulnerar directamente la política del mismo origen. Puede utilizar funciones legítimas del navegador disponibles para el usuario. Si una página maliciosa persuade al agente para abrir una bandeja de entrada, leer un mensaje y transmitir información, cada paso individual podría parecer autorizado.

A veces se denomina problema del delegado confundido. Un componente de confianza tiene autoridad legítima, pero un atacante lo manipula para que use esa autoridad con un fin equivocado. Los agentes de navegador hacen que el delegado sea conversacional, probabilístico y capaz de planificar varios pasos.

La investigación sobre agentes de navegador de código abierto ha demostrado cómo ese patrón puede provocar exposición de credenciales y acciones no autorizadas. Un estudio académico informó de prompt injection, evasión de validación de dominios y exfiltración de credenciales en un marco de automatización de navegadores. Su análisis de agentes de navegador también incluyó una vulnerabilidad divulgada y una prueba de concepto funcional.

El problema crece cuando un agente conserva memoria entre tareas. Una instrucción hostil no siempre necesita causar daño inmediato. Puede intentar alterar el contexto almacenado, crear una preferencia engañosa o influir en una decisión posterior cuando haya recursos sensibles disponibles.

La comprensión visual introduce otra vía. Un agente que interpreta capturas de pantalla puede encontrar instrucciones incrustadas dentro de imágenes o elementos de interfaz. Filtrar solo el texto sin procesar de la página no detectará todos los mensajes que un modelo multimodal puede percibir.

Los atacantes también pueden evitar frases obvias como “ignora las instrucciones anteriores”. Pueden presentar los pasos maliciosos como partes necesarias del objetivo original del usuario. Una solicitud para registrarse en un boletín, por ejemplo, puede convertirse en un pretexto para recuperar datos o abrir otra herramienta.

Esta técnica importa porque muchas defensas buscan un conflicto entre el objetivo del usuario y la instrucción hostil. En su lugar, un atacante puede hacer que la acción maliciosa parezca coherente con ese objetivo. La redacción se vuelve menos sospechosa mientras que la capacidad solicitada sigue siendo peligrosa.

La prompt injection se diferencia de la inyección SQL en un aspecto crítico. El software puede separar los comandos SQL de los datos mediante sintaxis estricta y consultas parametrizadas. Los agentes de lenguaje natural dependen de la interpretación contextual, por lo que las instrucciones y la información no siempre tienen una frontera técnica clara.

Los mensajes estructurados y las etiquetas de procedencia pueden mejorar esa separación. Los desarrolladores pueden indicar qué contenido procede del usuario, una página web, una herramienta o la aplicación. Sin embargo, el modelo aún debe interpretar el contenido externo cuando la tarea depende de su significado.

La investigación publicada como BrowseSafe evaluó los riesgos de prompt injection en agentes de navegador y examinó defensas en entornos realistas. Ese trabajo refleja un consenso emergente: la detección ayuda, pero la arquitectura del navegador y el diseño de permisos determinan el impacto final.

Por eso, un clasificador perfecto no resolvería todo el problema. Los clasificadores también procesan lenguaje ambiguo, y los atacantes pueden probar nuevas variantes. Los defensores necesitan varios controles independientes para que un juicio equivocado no desbloquee toda la sesión de navegador del usuario.

Las defensas de Amazon y Google optan por el control en lugar de una detección perfecta

Amazon y Google están construyendo defensas por capas porque ninguna de las dos empresas puede depender de un único filtro de prompt injection.

Google ha descrito una arquitectura que verifica las acciones de los agentes antes de que lleguen al navegador. Su User Alignment Critic es un componente independiente diseñado para evaluar si una acción propuesta coincide con el objetivo declarado por el usuario. La separación ayuda a evitar que el agente principal apruebe su propia interpretación arriesgada.

Google también utiliza información de origen, confirmaciones de acciones, entrenamiento de modelos y sistemas de detección. Las operaciones sensibles pueden requerir aprobación explícita del usuario. El navegador puede restringir qué información llega al agente y preservar las fronteras de seguridad en torno a las credenciales.

En su diseño de Chrome agéntico, Google reconoce que la exposición a contenido web no confiable crea un riesgo inherente de prompt injection indirecta. Esa formulación es significativa. La empresa presenta el problema como una amenaza arquitectónica que requiere mitigación continua.

La confirmación de acciones es útil porque restaura el juicio humano antes de un paso con consecuencias. Un usuario puede rechazar una compra, mensaje, inicio de sesión o transferencia de datos inesperados. Sin embargo, las solicitudes frecuentes también pueden volverse rutinarias y generar la misma fatiga observada con los avisos de cookies y los diálogos de permisos.

Por tanto, las confirmaciones deben centrarse en transiciones significativas. Enviar datos a un dominio nuevo merece más escrutinio que desplazarse por una página. Abrir un gestor de contraseñas conlleva mayor riesgo que extraer un titular público. Un modelo de aprobación uniforme trata acciones desiguales como si fueran equivalentes.

Amazon hace hincapié en la aplicación de políticas en torno a su entorno de navegador administrado. Los desarrolladores que utilizan Bedrock AgentCore pueden aplicar políticas empresariales de Chrome que restringen dónde navega un agente. Estas reglas operan en la capa del navegador, independientemente del prompt o razonamiento del agente.

La distinción es importante. Un modelo puede ser manipulado, pero una política determinista de red o de navegador sigue bloqueando un destino prohibido. Los controles de políticas de navegador de Amazon permiten a los creadores definir ubicaciones permitidas y bloqueadas antes de que el agente comience su trabajo.

Una lista de permitidos puede reducir drásticamente la exposición en flujos de trabajo empresariales acotados. Un agente de compras podría necesitar acceso a un pequeño conjunto de portales de proveedores aprobados. Un agente de atención al cliente podría requerir únicamente la plataforma de soporte y un sistema interno de conocimiento.

Esos límites se vuelven más difíciles de mantener en la investigación general. Un agente encargado de comparar productos o seguir noticias necesita un amplio acceso a la web. Cuanto más abierta es la tarea, menos útil resulta una lista estricta de destinos permitidos.

El aislamiento aporta otra capa. Una sesión de navegador administrada puede separar la actividad del agente del perfil de navegador cotidiano del empleado. Si el agente se ve comprometido, no debería heredar automáticamente cada cookie, pestaña abierta, credencial guardada y extensión disponibles para el usuario.

El aislamiento no determina si una instrucción es maliciosa. Limita los recursos disponibles después de una mala decisión. Esta es la misma lógica práctica detrás de los contenedores, las máquinas virtuales y las cuentas de servicio restringidas.

El principio de mínimo privilegio extiende ese enfoque a las herramientas y los datos. Un agente que solo necesita leer páginas públicas no debería recibir permiso para enviar correo electrónico. Un agente que redacta una transacción no debería poder aprobarla. Un agente que lee documentos no debería obtener automáticamente acceso a todas las carpetas conectadas.

Por tanto, los caminos de defensa de Amazon y Google convergen en un principio compartido. Los modelos seguirán siendo falibles, por lo que la seguridad debe existir fuera del modelo. Las políticas del navegador, los límites de identidad, las puertas de aprobación, el registro y las sesiones aisladas pueden contener un error que la detección no logró detener.

La verdadera disyuntiva es capacidad frente a contención

Toda defensa que reduce de forma fiable el impacto de la inyección de prompts también limita alguna parte de la autonomía del agente.

Un agente de navegador se vuelve más útil cuando puede moverse libremente entre servicios, recordar el contexto y completar tareas de varios pasos. Esas mismas capacidades aumentan el número de decisiones que un atacante puede influir. La disyuntiva de seguridad está incorporada en la propuesta de valor del producto.

Pensemos en un agente al que se le pide organizar un viaje. Podría buscar vuelos, comparar hoteles, consultar un calendario, recuperar información de fidelización y preparar una reserva. Si contenido externo redirige el plan, el agente podría exponer datos personales o seleccionar un destino controlado por un atacante.

Un sistema estrictamente contenido podría evitar ese resultado limitando al agente a búsquedas de solo lectura. Sin embargo, ya no completaría la reserva. Añadir autoridad de compra restaura la comodidad, al tiempo que incrementa el impacto de una acción equivocada.

El mismo patrón se aplica dentro de las empresas. Un agente de ventas podría investigar una cuenta y redactar un mensaje de contacto sin demasiado riesgo. Darle permiso para enviar mensajes, actualizar registros de clientes y adjuntar documentos internos crea una automatización más valiosa y un radio de fallo mayor.

Por eso la inyección de prompts debe evaluarse como un problema de seguridad de capacidades. Los equipos deberían preguntarse qué puede hacer el agente después de aceptar una instrucción maliciosa. La tasa de éxito de ataque de un modelo importa, pero la consecuencia permitida importa más.

Un resumidor de solo lectura presenta un riesgo diferente al de un agente conectado a sistemas de pago. Ambos pueden producir resultados engañosos. Solo uno puede convertir una mala interpretación en una transacción externa sin otro control.

Los proveedores a veces promocionan mayores tasas de detección como prueba de una seguridad mejorada. Esos resultados pueden ser valiosos, pero dependen del conjunto de pruebas, el conocimiento del atacante, la versión del modelo y las herramientas permitidas. Un ataque adaptativo puede apuntar a casos que un benchmark no incluyó.

Los falsos positivos también generan costes operativos. Un modelo defensivo podría rechazar contenido legítimo que se parece a un intento de inyección. Los equipos de seguridad pueden reducir los fallos aumentando la sensibilidad, pero entonces los usuarios encuentran más tareas bloqueadas y confirmaciones innecesarias.

El problema de diseño no tiene un punto final fijo porque las capacidades de los agentes siguen cambiando. Una salvaguarda probada frente al resumen de páginas no cubre automáticamente la navegación visual, las descargas de archivos, los diálogos del sistema operativo ni las interacciones con un nuevo protocolo de herramientas.

Las actualizaciones de navegador pueden introducir comportamientos adicionales. Las actualizaciones de modelos pueden cambiar cómo el agente interpreta instrucciones ambiguas. Un servicio conectado puede exponer nuevas acciones sin que el proveedor del navegador controle su interfaz. Las pruebas de seguridad deben seguir al sistema completo, no a una sola instantánea del modelo.

Las extensiones e integraciones de terceros complican aún más el panorama. Pueden ampliar el contenido visible para el agente o proporcionar nuevas vías de ejecución. Una empresa podría configurar cuidadosamente el navegador principal y, aun así, pasar por alto una extensión con amplio acceso a páginas.

Por ello, la perspectiva escéptica es necesaria. Las defensas por capas reducen el riesgo, pero las afirmaciones públicas sobre «agentes seguros» no deben interpretarse como inmunidad. Las empresas deberían divulgar el entorno probado, las acciones bloqueadas, las reglas de confirmación de usuario y la superficie de ataque residual.

Al mismo tiempo, declarar que todos los navegadores con IA son categóricamente inseguros simplifica en exceso la decisión. El riesgo depende de los permisos del agente, los datos accesibles, el aislamiento y la tarea. Un asistente de investigación restringido puede encajar en un entorno de menor riesgo incluso cuando un agente de compras no puede hacerlo.

Los equipos de seguridad necesitan clases de despliegue en lugar de una única aprobación general. Los agentes de bajo riesgo pueden operar en sesiones aisladas y de solo lectura. Los sistemas de riesgo medio pueden preparar acciones para revisión humana. Los flujos de trabajo de alto riesgo deberían requerir autorización determinista fuera del modelo.

Esa estructura acepta la disyuntiva central en lugar de fingir que ha desaparecido. Los usuarios siguen obteniendo automatización, pero la autonomía solo aumenta cuando los controles circundantes pueden absorber un fallo del modelo.

Quién está bajo presión por el problema de la inyección de prompts

Los proveedores de navegadores acaparan los titulares, pero los equipos empresariales de identidad y aplicaciones asumen gran parte de la carga práctica.

Google debe proteger a usuarios cuyos perfiles de navegador ya contienen sesiones valiosas. Chrome puede conectar un agente con correo electrónico, calendarios, documentos, cuentas de compras y herramientas de trabajo. Por tanto, una única interfaz puede exponer muchos dominios de confianza distintos.

Los clientes de Amazon afrontan una responsabilidad diferente. Bedrock AgentCore proporciona componentes y controles administrados, pero los desarrolladores siguen decidiendo a qué destinos, identidades, herramientas y datos puede acceder un agente. Un servicio seguro puede respaldar una configuración de aplicación insegura.

Microsoft, OpenAI, Anthropic y Perplexity afrontan la misma presión competitiva. Los usuarios esperan que los agentes de navegador gestionen más trabajo, mientras los investigadores de seguridad prueban cada nueva capacidad. Un diseño restrictivo puede parecer menos útil junto a un rival que permite una automatización más amplia.

Ese ciclo competitivo puede animar a los proveedores a ampliar permisos más rápido de lo que las empresas actualizan su gobernanza. Las nuevas funciones de agentes pueden llegar mediante navegadores y herramientas de productividad conocidos, evitando la revisión de compras requerida para una aplicación independiente.

Los equipos de seguridad deberían inventariar las funciones agénticas como capacidades, no como nombres de productos. Las preguntas relevantes se refieren al acceso a sesiones autenticadas, archivos locales, aplicaciones conectadas, memoria, mensajería, descargas y ejecución de código.

Los propietarios de aplicaciones también deben replantearse el contenido de las páginas web. Un panel interno se diseñaba antes principalmente para lectores humanos. Si los agentes consumen su texto tanto como información como posible instrucción, la procedencia del contenido se convierte en parte de la seguridad de la aplicación.

Los equipos de identidad deben decidir si los agentes comparten credenciales humanas o reciben identidades de servicio distintas. Las sesiones compartidas son cómodas, pero debilitan la rendición de cuentas. Las identidades separadas permiten permisos más estrictos, registros más claros y una revocación más rápida.

Los desarrolladores necesitan registros de eventos que expliquen qué vio el agente y por qué actuó. El historial convencional del navegador muestra las páginas visitadas, pero puede no capturar el contenido exacto, la decisión del modelo, la llamada a herramienta y la autorización detrás de la acción de un agente.

Los equipos de respuesta a incidentes afrontan otra dificultad. Una inyección de prompts exitosa puede parecer actividad normal del usuario porque el agente utiliza credenciales válidas y funciones legítimas del navegador. La detección debe examinar la intención, la secuencia, el destino y el movimiento de datos.

Los empleados también necesitan señales más claras. Deben saber cuándo un agente lee una página, pasa a otro servicio, accede a información privada o prepara una acción irreversible. Un pequeño icono animado no comunica toda la transición de confianza.

Los compradores empresariales deberían preguntar a los proveedores cómo funcionan las defensas cuando el contenido es visual, está ofuscado, es multilingüe o se distribuye en varios pasos. También deberían preguntar si las comprobaciones de seguridad se ejecutan de forma independiente del agente principal y si las políticas siguen siendo aplicables tras cambios en el modelo.

La evaluación más sólida incluye pruebas adversariales contra los flujos de trabajo reales de la organización. Un benchmark genérico no puede reproducir cada aplicación interna, fuente de datos y combinación de permisos. Los equipos de red team deberían probar objetivos realistas variando el contenido malicioso.

Los contratos de compra también necesitan condiciones claras sobre incidentes. Los compradores deberían comprender la retención de registros, la divulgación de vulnerabilidades, las prácticas de actualización de modelos y la responsabilidad por configuraciones inseguras. La inyección de prompts cruza los límites entre el comportamiento del proveedor y el diseño del cliente.

Ninguna empresa puede resolver ese problema de responsabilidad compartida solo con una actualización del modelo. Los proveedores deben ofrecer controles aplicables, mientras que los clientes deben configurarlos en torno a tareas específicas. Ambas partes necesitan pruebas de que los controles funcionan conjuntamente.

Qué observar a continuación de Amazon, Google y los proveedores de navegadores con IA

La siguiente fase se juzgará por pruebas de contención, no por promesas de que la inyección de prompts ha sido eliminada.

La primera señal es si los proveedores publican evaluaciones reproducibles que cubran flujos de trabajo completos del navegador. Las pruebas deberían incluir texto oculto en páginas, imágenes, acciones entre pestañas, memoria almacenada, cuentas conectadas y manipulación de intención en varios pasos. Un único benchmark de rechazos ofrece una visión demasiado limitada.

Los resultados deberían separar la detección del impacto. Un ataque que influye en un resumen difiere de uno que envía datos o completa una compra. Los compradores necesitan saber tanto con qué frecuencia un agente sigue contenido hostil como qué controles detienen la acción resultante.

La segunda señal es un uso más amplio de restricciones deterministas. Las políticas de navegador de Amazon ofrecen un ejemplo porque pueden bloquear destinos independientemente del razonamiento del modelo. Las comprobaciones de acciones y las puertas de permisos de Google cumplen una función relacionada en torno a la alineación con el usuario.

Observe si esos controles se vuelven más fáciles de configurar de forma granular. Las empresas necesitan políticas basadas en destino, sensibilidad de los datos, tipo de acción, identidad y tarea. Un único interruptor de activación o desactivación para todo el navegador no puede representar esas diferencias.

La tercera señal es cómo los proveedores gestionan las cadenas de ataque recién divulgadas. Los parches rápidos siguen siendo importantes, incluso cuando persiste la clase de vulnerabilidad. Las notas de lanzamiento deberían explicar si una corrección cambia la detección, el alcance de los permisos, el aislamiento o la arquitectura subyacente del agente.

Los investigadores seguirán encontrando variantes porque el comportamiento de los agentes no es determinista. Un parche que bloquea una frase o patrón de página web no aborda la colisión de intenciones en contextos distintos. Las mejoras duraderas deberían eliminar capacidades de rutas no confiables o añadir autorización independiente.

El aumento reportado por Google de patrones web maliciosos hace urgente este trabajo. La sofisticación de los ataques aún era limitada en el análisis de la empresa, pero una mayor actividad ofrece a los atacantes más oportunidades para probar productos desplegados. Una adopción más amplia de agentes de navegador hace que las técnicas exitosas sean más valiosas.

La competencia entre Amazon y Google también revelará qué compromisos de seguridad aceptan los usuarios. Google puede colocar confirmaciones directamente dentro de Chrome, donde las personas las ven. Amazon puede proporcionar a los desarrolladores políticas de infraestructura, pero cada cliente debe decidir cuán restrictivas deberían ser esas políticas.

Para los despliegues empresariales, el estándar a corto plazo debería ser sencillo. Aísle al agente, asígnele una identidad distinta, restrinja los destinos, minimice las herramientas y exija aprobación antes de acciones relevantes. Registre cada transición entre contenido no confiable y comportamiento privilegiado.

Los trabajadores del conocimiento deberían mantener las cuentas sensibles fuera de las sesiones experimentales de agentes siempre que sea posible. También deberían revisar los mensajes, transacciones, descargas y transferencias de datos propuestos. Actualizar el navegador es importante, pero no puede eliminar el problema subyacente de interpretación.

Los desarrolladores deberían tratar cada página web, correo electrónico, documento cargado y nota recuperada como una entrada no confiable. Deberían asumir que el modelo principal terminará clasificando erróneamente parte de ese contenido. Los controles externos a ese modelo deben determinar qué sucede después.

La conclusión de que no existe una solución perfecta resulta incómoda porque cambia la cuestión sobre el despliegue. Los equipos deberían dejar de preguntarse si un agente de navegador es inmune a la inyección de prompts. Deberían preguntarse si una sola inyección exitosa puede alcanzar algo que realmente importe.

Antes de habilitar la próxima función autónoma, trace su peor acción permitida y decida si el beneficio justifica esa exposición. Si la respuesta no está clara, mantenga el agente en modo de solo lectura o exija aprobación humana. La carrera entre Amazon y Google producirá mejores defensas, pero una adopción responsable seguirá dependiendo de la contención.