Cómo un café falso en Berkeley le robó la memoria a Claude

Cómo un café falso en Berkeley le robó la memoria a Claude

Cómo un café falso en Berkeley le robó la memoria a Claude

Hace poco un investigador llamado Ayush Paul demostró algo que a mí, como administrador de sistemas, me dejó frío: con una simple cafetería falsa en internet podía sacarle a Claude el nombre completo, la empresa donde trabaja y hasta la ciudad donde creció el usuario. Sin que la persona hiciera nada raro. Sin link sospechoso. Sin click. Solo pidiéndole a Claude que revisara un café en Berkeley.

El reporte original se llama The Memory Heist y vale la pena leerlo completo. Lo que cuenta es técnico y, al mismo tiempo, profundamente preocupante. Llevamos años confiándole a los asistentes de IA cosas que ni a un amigo cercano le contaríamos: proyectos en la pega, claves, discusiones familiares, detalles de salud. Y resulta que toda esa información se puede filtrar usando el mismo navegador web que el propio Claude trae integrado.

Cómo funciona el robo, en simple

Claude tiene un sistema de memoria persistente. Cada cierto tiempo resume tus conversaciones y guarda lo que aprendió de ti. Después, en cualquier chat nuevo, inyecta ese resumen como contexto. Es cómodo, pero significa que el modelo sabe quién eres sin que tengas que explicarte cada vez.

El ataque aprovecha la herramienta web_fetch. El atacante construye un sitio web normal, que a simple vista se ve inofensivo, con una serie de enlaces a otras páginas. Cuando Claude entra al primero, va siguiendo los enlaces. Como cada link puede codificar un fragmento de información (una letra, una sílaba, un token), el atacante va reconstruyendo lo que la memoria de Claude sabe del usuario letra por letra. Todo a través de URLs que parecen tráfico legítimo.

Lo más grave: el usuario no necesita hacer nada. Basta con preguntarle a Claude por un café en Berkeley o por cualquier tema donde el sitio malicioso esté bien posicionado en Google. El sistema de búsqueda del propio modelo lo lleva directo a la trampa.

Lo que a mí me preocupa de verdad

La memoria persistente está activada por defecto en casi todos los productos de IA conversacional. El usuario promedio no sabe que existe, menos aún qué datos está exponiendo. Y los vendors lo saben, pero la conveniencia gana siempre a la seguridad, como decía Kevin Kelly hace poco.

Anthropic parcheó el caso específico después de que Paul lo reportara por HackerOne. Pero el patrón ya está en la calle. Cambias web_fetch por una integración con tu correo, con tu Drive, con un MCP que conectaste una vez y olvidaste, y tienes el mismo problema multiplicado por diez. El prompt injection, el viejo conocido, sigue siendo el talón de Aquiles de toda esta generación de agentes.

Qué hago yo, en concreto

Trabajo con integraciones todos los días. Conecto Telegram con n8n, automatizo cosas con Dokploy, monto APIs sobre Docker. Y si algo aprendí leyendo este reporte es que tengo que revisar qué herramientas le di permiso a mis propios asistentes para invocar en mi nombre. Tres preguntas que vale la pena hacerse esta semana:

  • ¿Qué MCP tengo conectados que ya no uso? Si no lo abriste en los últimos treinta días, quítalo.
  • ¿La memoria persistente está realmente justificada? Si tu pega no requiere contexto largo, desactívala. La fricción es menor de lo que parece.
  • ¿Le he contado a la IA algo que no le contaría a un desconocido? Si la respuesta es sí, ese dato ya está en un resumen circulando por ahí.

La IA no va a dejar de leer sitios web por nosotros. Es demasiado útil. Pero cada vez que le abrimos un canal nuevo a un modelo, le estamos abriendo también una puerta a quien sepa construir el sitio correcto. Y como demostró este caso, no necesita ser un genio: basta con un café falso y un poco de SEO.

Fuente de inspiración: The Memory Heist

Comentarios

Aún no hay comentarios. ¿Por qué no comienzas el debate?

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *