Lo local no es más seguro: la inyección indirecta afecta a LLM locales y en la nube

¿Qué es esto?

El 8 de junio de 2026, el equipo de investigación de seguridad y privacidad de Brave (Ali Shahin Shamsabadi, Hamed Haddadi y Artem Chaikin) publicó Indirect Prompt Injection remains a fundamental security challenge for AI, revelando la misma clase de fallo en dos productos situados en extremos opuestos del espectro de despliegue: Mozilla Tabstack, una API en la nube de ejecución web para agentes de IA, y Cotypist, un asistente de autocompletado totalmente en el dispositivo para macOS. Ambos fueron notificados bajo divulgación responsable antes de la publicación; Tabstack confirmó una corrección el 1 de junio de 2026, verificada de forma independiente por Brave.

Lo relevante es la comparación, no cada error por separado. La inyección de prompts indirecta —instrucciones coladas en el contenido que el modelo lee de forma legítima— suele percibirse como un problema de nube y web abierta que los modelos en el dispositivo evitarían. El hallazgo de Brave es que el modelo local también fue secuestrado. La vulnerabilidad no depende de dónde se ejecute el modelo.

Cómo funciona

La inyección indirecta funciona porque un sistema que integra un LLM compone, en una misma ventana de contexto, instrucciones de confianza (del desarrollador/usuario) y datos externos no confiables, sin un mecanismo fiable para preservar la frontera entre ambos. El atacante nunca toca la interfaz del prompt; la carga llega dentro de una página, un documento o el resultado de una herramienta que el sistema ingerirá después.

En el caso de la nube, Brave dio al endpoint de automatización de Tabstack una tarea rutinaria —resume esta página— en una página que controlaba. La página contenía instrucciones en texto invisible (blanco sobre blanco / caracteres de ancho cero): presentes en la capa de texto, invisibles para un humano. El agente nunca resumió la página. Ejecutó los pasos ocultos en orden: navegó a un formulario controlado por el atacante, lo rellenó con el prompt y todo el historial de conversación, y lo envió, exfiltrando esos datos. Su propia traza de razonamiento muestra que trató las instrucciones de la página como una continuación legítima de la tarea; nunca señaló un conflicto ni pidió confirmación. Aquí no se reproduce ninguna carga explotable: lo que importa es el mecanismo.

En el caso del dispositivo, instrucciones incrustadas en un documento local orientaron el autocompletado de Cotypist hacia sugerencias elegidas por el atacante, con riesgo de exponer en línea las credenciales del usuario. El radio de impacto es menor: un autocompletado del sistema no puede ejecutar acciones autónomas, y su diseño de tab-para-aceptar mantiene una pulsación humana entre una compleción inyectada y su realización. El agente en la nube moldea lo que el modelo hace; el asistente local moldea lo que el modelo dice. Consecuencias distintas, fallo estructural idéntico.

Es el mismo patrón que Brave demostró por primera vez contra Perplexity Comet en agosto de 2025, donde un texto oculto en un comentario de Reddit dirigía al agente a través de sesiones autenticadas para exfiltrar un correo y un código de un solo uso. Un año después, la lección se extiende también al despliegue local.

Por qué importa

La conclusión para los profesionales es reformular la pregunta. La pregunta correcta no es «¿este sistema usa una API en la nube?», sino «¿este sistema compone instrucciones de confianza con contenido no confiable en una ventana de contexto compartida?». Si la respuesta es sí, conlleva riesgo de inyección indirecta: la forma del riesgo depende de la arquitectura, pero su presencia, no.

Esto importa porque «ejecutamos el modelo en local» se ofrece cada vez más como garantía de seguridad y privacidad. Frente a este modelo de amenaza, no lo es. Un modelo en el dispositivo, más pequeño, suele ser menos capaz de distinguir una instrucción maliciosa de una de confianza, no más. El alojamiento local cambia el punto de entrada del atacante (un archivo local en lugar de la web abierta) y el radio de impacto (lo que el modelo dice frente a lo que hace de forma autónoma), pero no cierra el agujero. Cabe destacar que el endpoint de automatización de Tabstack expone un parámetro guardarraíl en lenguaje natural no activado por defecto: la configuración habitual es, por tanto, la vulnerable.

Defensas

Brave plantea la mitigación como defensa en profundidad junto con un diseño seguro a nivel de sistema. Los controles concretos, coherentes con las recomendaciones de su investigación sobre Comet:

• Separar instrucciones y datos, y desconfiar de la salida del modelo. Pasar el contenido de páginas/documentos como explícitamente no confiable, distinto de la petición del usuario, y tratar las acciones que propone el modelo como potencialmente inseguras, no como comandos autorizados.
• Verificar el alineamiento de las acciones con el usuario. Comprobar de forma independiente que cada acción propuesta coincide con la petición real del usuario antes de ejecutarla, en lugar de suponer que el plan es benigno porque lo generó el modelo.
• Condicionar las acciones sensibles a una interacción explícita. Navegar a dominios autenticados, enviar un formulario, sacar datos al exterior o enviar un correo: exigir una confirmación humana deliberada justo antes de la acción, sea cual sea el plan previo.
• Aislar el modo agéntico y aplicar mínimo privilegio. No dejar que la navegación corriente derive en un agente con todos los privilegios. Acotar las herramientas, dominios y datos accesibles a la tarea; un asistente que solo resume no necesita acceso a credenciales ni entre sitios.
• No confiar en el alojamiento local ni en guardarraíles opcionales como control. El despliegue en el dispositivo no sustituye estas fronteras, y un guardarraíl que se entrega desactivado por defecto no protege a nadie. Aplicar por defecto separación estructural, mínimo privilegio y control del flujo de información.

Estado

Producto	Alojamiento	Vector de inyección	Impacto	Divulgación	Estado
Mozilla Tabstack	Nube (/v1/automate)	Texto invisible en una página web	Exfiltración del historial de conversación a un formulario del atacante	2026-05-13	Corregido el 2026-06-01 (verificado)
Cotypist	En el dispositivo (macOS)	Texto en un documento local	Autocompletado manipulado; riesgo de exponer credenciales	2026-06-01	Confirmado por el proveedor el 2026-06-02

Ambos hallazgos refuerzan un único punto que los defensores deben asumir: la inyección de prompts indirecta es un problema de composición de contexto inherente a la arquitectura actual de los LLM, y no puede resolverse por completo cambiando dónde se ejecuta el modelo. Los parches cierran instancias; son los controles estructurales anteriores los que reducen la clase.