Envenenamiento de memoria de agentes IA en móviles

Qué es el envenenamiento de memoria de agentes IA

El envenenamiento de memoria de agentes de IA es la entrada de instrucciones, preferencias o hechos no fiables en la memoria persistente de un asistente, de modo que conversaciones futuras puedan quedar sesgadas. La clave es la persistencia. Una respuesta mala en una conversación concreta se corrige en ese momento; una memoria manipulada puede reaparecer después como recomendación, preferencia, regla personal o “dato que el asistente recuerda”.

Microsoft usa el término AI Recommendation Poisoning para describir intentos de sesgar recomendaciones futuras. El ejemplo práctico no es entrenar un modelo desde cero ni cambiar todo un sistema de IA. Es más cercano a esto: un sitio, un enlace o un botón empuja al asistente a “recordar” que cierta empresa, producto o proveedor debe preferirse en recomendaciones posteriores. Si esa instrucción entra en una memoria reutilizada, la próxima consulta puede parecer imparcial aunque venga contaminada por una interacción anterior.

En un teléfono, el riesgo se siente más personal. El asistente ve páginas, correos, capturas, documentos, pantallas de apps y preferencias del usuario. Cuando esa información se guarda sin suficiente procedencia, editarla o separarla por contexto se vuelve difícil. Desde FoneClaw miramos la memoria como una capacidad potente que necesita límites: quién aportó el dato, cuándo se guardó, para qué tarea sirve, dónde puede usarse y cómo puede revisarse.

La manipulación de recomendaciones de IA no se mide solo por si una marca aparece en una respuesta. También importa si el asistente puede mostrar por qué la recomienda, qué memoria influyó y cómo eliminar o acotar esa influencia. Esa transparencia es la diferencia entre personalización útil y sesgo persistente opaco.

Cómo un botón Ask AI puede llegar a la memoria

Un camino de ataque plausible empieza con una experiencia aparentemente normal: un botón “Ask AI”, “Summarize with AI” o “preguntar al asistente” dentro de una página, correo o documento. El texto visible promete ahorrar tiempo. Detrás, el enlace puede abrir un asistente con un prompt prellenado. Ese prompt puede mezclar contenido legítimo para resumir con una instrucción diseñada para influir en memoria o recomendaciones futuras.

Microsoft describió intentos basados en URL construidas con parámetros de prompt. La ruta, en términos no operativos, es: etiqueta amigable, destino de IA, texto prellenado, clic del usuario, solicitud al asistente y posible instrucción para recordar o priorizar una empresa. El usuario puede creer que solo pidió un resumen, mientras el texto enviado intenta añadir una preferencia persistente. La eficacia depende de la plataforma, los controles de memoria, los filtros y el estado de las protecciones.

La lección para usuarios móviles es que el botón no revela todo. Una etiqueta bonita no muestra el destino completo ni todo el texto que se enviará. Una vista previa parcial tampoco garantiza que no haya instrucciones incrustadas, codificadas o mezcladas con el contenido. Por eso recomendamos tratar estos accesos como contenido no confiable hasta revisar qué se va a enviar y qué permisos o memoria puede tocar.

El patrón no convierte todos los botones Ask AI en maliciosos. Muchos son accesos útiles. El criterio es procedencia y control: quién creó el enlace, qué texto añade, si el asistente muestra el prompt antes de enviarlo, si la memoria persistente está activada y si el usuario puede revisar lo guardado. En un teléfono, esa revisión debe ser rápida porque el usuario suele tocar desde una pantalla pequeña y con menos contexto visible.

Memoria, prompt injection y datos de entrenamiento

Conviene separar tres riesgos que se mezclan con facilidad. La prompt injection de una sola vuelta intenta influir en la tarea actual: ignorar instrucciones, seguir órdenes ocultas o responder de una forma concreta durante esa conversación. El envenenamiento de memoria busca que algo quede guardado para afectar interacciones futuras. El envenenamiento de datos de entrenamiento pertenece a otra escala: manipular datos usados para entrenar o ajustar modelos.

Una recomendación sospechosa por sí sola no prueba el mecanismo. Puede venir de memoria, de contexto reciente, de una fuente débil, de personalización legítima o de una mala respuesta. Para diagnosticar, busca la procedencia: qué contenido se envió, qué memoria quedó guardada, qué configuración estaba activa y si el resultado se repite en una sesión limpia sin el contexto sospechoso.

En seguridad móvil, esa precisión evita soluciones falsas. Borrar una conversación puede ser útil para limpiar contexto inmediato, pero la memoria persistente puede tener controles separados. Del mismo modo, desactivar una función de memoria no explica una respuesta ya generada. El flujo correcto es identificar la capa afectada antes de corregir.

Qué encontró Microsoft y qué no prueban los números

En su publicación sobre AI Recommendation Poisoning, Microsoft informó que observó más de 50 prompts únicos de 31 empresas en 14 industrias que intentaban sesgar recomendaciones futuras. La técnica, según Microsoft, usaba URL preparadas detrás de botones de IA para prellenar instrucciones de persistencia. El objetivo era lograr que el asistente recordara o priorizara una marca, servicio o empresa más adelante.

Ese hallazgo es importante porque muestra un incentivo real: si un asistente influye en compras, proveedores, herramientas, viajes o servicios profesionales, algunas partes intentarán empujar la memoria. La manipulación de recomendaciones de IA se vuelve más atractiva cuando los usuarios confían en el asistente como filtro de opciones.

Los números también tienen límites. Microsoft distingue intentos observados, diferencias de efectividad entre asistentes y cambios conforme evolucionan las salvaguardas. También indica que despliega mitigaciones en Copilot y que algunos comportamientos anteriores dejaron de reproducirse. Esa precisión importa: el hallazgo no significa que cada prompt persistiera, ni que cada asistente guarde memoria del mismo modo, ni que una protección concreta cubra todas las plataformas.

MITRE ATLAS cataloga Memory Poisoning como AML.T0080, lo que ayuda a ubicar el riesgo dentro de una taxonomía de amenazas a sistemas de IA. Para el usuario de teléfono, la traducción práctica es sencilla: cuando un asistente recuerda cosas para el futuro, la memoria necesita revisión, alcance y procedencia.

Por qué importan procedencia, versiones y alcance

La memoria útil debe responder preguntas de control: de dónde salió, cuándo se guardó, quién la posee, para qué agentes o tareas aplica, qué versión está activa, qué estado tiene y cuántas veces se usó. Sin esa procedencia, una recomendación futura puede sonar personalizada sin que el usuario pueda distinguir entre preferencia real, contexto legítimo y sesgo introducido por un enlace.

TencentDB Agent Memory sirve como ejemplo arquitectónico de memoria gobernada. Su documentación modela Chat Memory, Skills, Wiki y CodeGraph como activos con propiedad, versiones, estado, visibilidad, uso y vínculos con agentes. También describe capas donde las conversaciones crudas se conservan en L0 y se derivan átomos, escenarios y núcleo o persona en capas superiores. No lo citamos como defensa para teléfonos; lo usamos como señal de diseño: la memoria seria necesita trazabilidad.

En un asistente móvil, una memoria sobre “prefiero hoteles baratos” puede tener sentido en viajes y ser irrelevante para salud. Una memoria sobre “prioriza cierta empresa” debería mostrar su origen, especialmente si nació de un botón externo. Una memoria sobre identidad, trabajo, familia o ubicación requiere ámbito todavía más estrecho. La seguridad no está solo en guardar menos; también está en guardar con etiquetas claras y controles de edición.

Para quien quiera profundizar en el equilibrio entre memoria híbrida, servidor y agente local, mantenemos el análisis en Estado del servidor Hy-Memory vs memoria local del agente: guía para usuarios de teléfono. En esta guía, el criterio práctico es directo: toda memoria que pueda cambiar recomendaciones debe tener origen, alcance y posibilidad de revisión.

Checklist antes de enviar contenido a un asistente

La seguridad de botones Ask AI empieza antes de tocar enviar. En el teléfono, el usuario suele ver menos URL, menos parámetros y menos contexto que en escritorio. Por eso conviene crear un hábito breve: revisar la fuente, abrir vistas previas cuando existan, observar el texto prellenado y separar el contenido que quieres resumir de las instrucciones que autorizas al asistente a seguir.

• Revisa el origen: un botón dentro de una página, anuncio, correo o documento hereda la confianza de quien lo colocó allí.
• Mira el destino: si el enlace abre un asistente con texto ya escrito, trata ese texto como una propuesta, no como una instrucción aprobada.
• Lee el prompt prellenado: busca frases que pidan recordar, priorizar, preferir, recomendar siempre o ignorar alternativas.
• Reduce el alcance: pide resumen del contenido, no actualización de memoria, preferencias o reglas futuras.
• Evita contenido sensible: si la pantalla incluye cuentas, mensajes, datos médicos, trabajo o ubicación, recorta o reformula antes de compartir.
• Verifica recomendaciones importantes: compara con fuentes independientes cuando la decisión afecte dinero, salud, seguridad, empleo o datos personales.

Este checklist también aplica a capturas, correos, documentos, texto copiado y páginas abiertas. El contenido que parece pasivo puede incluir instrucciones dirigidas al asistente. La inspección visual ayuda, aunque no descubre todos los formatos ocultos o codificados. Lo que sí cambia es la postura: el usuario decide qué entra al asistente y con qué propósito.

Si tu caso usa mucho contexto personal en el móvil, la guía Agente de IA con contexto personal en el teléfono explica cómo convertir contexto en utilidad sin perder de vista el alcance de cada dato.

Cómo contener y recuperar una memoria sospechosa

La recuperación empieza reduciendo el alcance del posible sesgo. Si sospechas que una recomendación o preferencia quedó contaminada, pausa el uso de esa memoria para decisiones importantes. Anota el disparador: página, botón, enlace, correo, documento o pantalla que precedió al cambio. Esa nota evita depender solo de la memoria humana cuando revises ajustes después.

1. Detén decisiones sensibles: evita compras, contrataciones, recomendaciones profesionales o cambios de cuenta basados en esa salida hasta verificar.
2. Revisa memorias guardadas: busca entradas sobre preferencias, empresas, proveedores, temas o instrucciones nuevas. Cada asistente ubica esos controles de forma distinta.
3. Elimina o edita entradas sospechosas: cuando la plataforma lo permita, quita memorias sin procedencia clara o con lenguaje promocional.
4. Empieza una sesión limpia: prueba la misma pregunta sin el enlace, documento o pantalla sospechosa.
5. Compara con fuentes independientes: usa documentación oficial, reseñas verificables, datos de precio o referencias externas según el caso.
6. Repite con una pregunta neutral: evita mencionar la marca sospechosa y observa si el sesgo reaparece.
7. Ajusta la memoria futura: limita qué se guarda automáticamente y revisa con más frecuencia si usas asistentes para decisiones repetidas.

Los controles de memoria cambian entre asistentes. Borrar el historial de chat puede limpiar contexto visible, mientras que una memoria persistente puede vivir en otra sección. Desactivar personalización puede reducir reutilización futura, pero conviene comprobar con una sesión nueva. La recuperación buena termina con una prueba, no con una suposición.

Para decisiones de confianza entre procesamiento local, nube y servicios online, desarrollamos el marco en Confianza en agentes de IA: control local en Android frente a seguridad en la nube. Aquí la prioridad es contener, revisar, limpiar y retestar.

Límites de contexto de FoneClaw en Android

La base actual de FoneClaw es la referencia de producto para esta guía. Añade asistente flotante movible y adjunto deliberado de pantalla actual, excluyendo superficies de overlay de FoneClaw en esa captura. Para el usuario, eso crea una frontera visible: el contexto de pantalla entra cuando se adjunta de forma intencional, no como una lectura continua de todo lo que ocurre en el teléfono. La ruta pública para probar las capacidades actuales es la página localizada de descarga de FoneClaw.

En nuestra arquitectura, un modelo configurado razona y planifica, mientras FoneClaw suministra ejecución Android compatible mediante herramientas gobernadas. Las acciones soportadas conservan límites de permiso, aprobación, resultado y recuperación. Esa separación ayuda a distinguir tres cosas: contenido que el usuario adjunta, razonamiento que puede ocurrir en un modelo configurado y acción Android que FoneClaw ejecuta dentro de contratos visibles.

También tratamos la información de cuenta gestionada localmente como un área con controles del usuario. Al mismo tiempo, si el usuario configura modelos online o servicios externos, el contexto relevante puede enviarse a esos servicios según la configuración y el flujo. Por eso enlazamos las decisiones de privacidad a la página localizada de privacidad de FoneClaw y las capacidades a funciones de FoneClaw.

Presentamos estos controles como fronteras de uso, no como detector automático de envenenamiento de memoria. FoneClaw ayuda a que el usuario vea qué pantalla adjunta y qué acción Android se prepara. La auditoría de memoria guardada, la limpieza de preferencias persistentes y la verificación de recomendaciones siguen dependiendo del asistente, modelo o servicio que conserve esa memoria. Esa honestidad de límites es parte de cómo construimos confianza: contexto deliberado, acciones gobernadas y decisiones revisables.

Checklist de seguridad de memoria para un phone agent

Evalúa la seguridad de memoria con contenido de bajo riesgo antes de usar un asistente para compras, salud, finanzas, trabajo o seguridad personal. Crea una preferencia de prueba, revisa si se guarda, observa dónde aparece después y comprueba si puedes editarla o borrarla. Luego introduce un documento con una recomendación promocional y verifica si el asistente la trata como contenido a resumir o como instrucción futura.

• Procedencia: ¿la memoria muestra origen, fecha o conversación?
• Alcance: ¿la memoria aplica a una tarea concreta o a todas las recomendaciones?
• Control: ¿puedes ver, editar, desactivar o borrar la entrada?
• Separación: ¿el contenido resumido queda separado de instrucciones para el asistente?
• Retest limpio: ¿la recomendación cambia al preguntar desde una sesión nueva sin el material sospechoso?
• Verificación externa: ¿las recomendaciones importantes se contrastan fuera del asistente?

La memoria vuelve útil a un agente de teléfono cuando respeta procedencia, alcance y revisión. La misma memoria se vuelve riesgosa cuando una instrucción externa puede permanecer invisible. Nuestro trabajo en FoneClaw avanza hacia experiencias Android donde el contexto sea deliberado y la acción sea verificable; la seguridad de memoria exige esa misma claridad.

Si el riesgo viene de Skills, instalaciones o permisos de tiempo real, el análisis específico está en Seguridad de habilidades de agentes de IA: por qué el móvil necesita permisos en tiempo real. La regla final de este playbook es práctica: antes de confiar en una recomendación persistente, verifica quién la sembró, dónde vive y cómo se elimina.