Fallo de indexación en Claude: cómo evitar que Google publique tus secretos

El share no era un favor entre colegas

Llevas meses pegando trozos de código, logs y configs en Claude. Un día le das a compartir porque un compañero necesita el hilo. Te olvidas del enlace. Semanas después, alguien escribe site:claude.ai/share en Google y aparecen conversaciones ajenas con historiales médicos, documentos de empresa, código y teléfonos de menores.

Eso no es una hipótesis de paranoia. A finales de julio de 2026, usuarios de Reddit lo pillaron en vivo: miles de conversaciones de Claude compartidas por enlace público estaban en Google y Bing. Lo contaron La Vanguardia, Hipertextual y El Español. Las tres fuentes coinciden en el mecanismo y en el tipo de basura que salió a flote. Difieren en el ángulo: unas ponen el foco en el fallo técnico de indexación; otras, en qué tienes que pulsar ahora mismo para no seguir expuesto.

Esta guía no va de “Anthropic malvada” ni de “la IA te espía”. Va de una verdad de ingeniería que el incidente solo ha puesto de moda: un artefacto de ejecución con secretos dentro no es un borrador inocente. Es el mismo objeto que, si no lo tratas como material sensible, acaba en un buscador, en un log o en un entorno que no toca. El chat compartido es solo la versión visible del patrón.

Qué falló de verdad (y qué no)

El fallo técnico es simple y las tres coberturas lo clavan igual: las páginas de chats compartidos de Claude no llevaban la etiqueta noindex. Los motores pudieron rastrearlas e indexarlas en resultados. Había un robots.txt, pero no bastaba. La URL seguía el patrón https://claude.ai/share/ más una cadena alfanumérica. Buscar site:claude.ai/share en Google sacaba el listado.

Ahí empieza el matiz que mucha gente se salta. Anthropic dijo que no pasa directorios ni sitemaps a buscadores y que los chats privados no se indexan salvo que el enlace se publique en una web abierta. Google, por boca de Ned Adriance, respondió lo de siempre: los dueños del sitio tienen controles claros sobre qué se rastrea e indexa, y ellos respetan esas directrices. Las dos posturas no se contradicen del todo: Google no “robó” nada; Anthropic no “regaló un directorio”. Lo que falló es la configuración de las páginas de share: un artefacto pensado para un tercero concreto se comportó, de cara al crawler, como página pública indexable.

Después del ruido, Anthropic corrigió la config y Google empezó a retirar enlaces. Horas más tarde todavía se podía llegar a conversaciones desde Brave Search o Bing. Eso importa: “lo hemos arreglado” y “ya no está en ningún sitio” no son la misma frase. Cachés, índices secundarios y copias tardan. Si tu enlace estuvo vivo, asume ventana de exposición, no interruptor mágico.

Y no es la primera vez que este tipo de cosa pasa con chats de IA en buscadores: el año pasado ya se reportó una exposición similar con cientos de conversaciones. El patrón se repite porque el producto invita a compartir y la privacidad del share se trata como detalle de frontend.

La tesis que importa: el artefacto sube de entorno tal cual

Antes del paso a paso en la interfaz de Claude, el criterio que ordena todo esto:

Revisas secretos en el artefacto de ejecución, no en la herramienta de turno. El chat exportado, el enlace de share, el log del agente, el JSON de traza, el .env que “solo es para probar”, la imagen Docker con la key horneada. Es el mismo objeto. Cambia la etiqueta del entorno, dev, staging, prod, “se lo mando a María”, y la gente relaja el listón. El artefacto no relaja nada: si llevaba un token, lo sigue llevando.

Ese es el patrón feo de verdad. El mismo bundle asciende por los entornos y solo cambia la configuración. Mismas trazas, mismo prompt con la API key pegada “un momento”, mismo fragmento de docker-compose con la password de la base. En dev nadie se inmuta. En prod es incidente. En un share de Claude indexado por Google es portada. La diferencia no está en el contenido; está en quién puede leerlo.

Por eso esta guía no se queda en “dale al cubo de basura del enlace”. Eso apaga el fuego visible. Lo que evita el siguiente es tratar cada salida de la IA, y cada cosa que le pegas dentro, como material que puede acabar en un índice público sin que tú lo decidas del todo.

Qué es el share de Claude y para qué sirve (sin marketing)

Compartir un chat en Claude genera un enlace público para que otra persona vea esa conversación. Está pensado para mandárselo a un tercero concreto: un compañero, un cliente, un hilo de soporte. No está pensado, por defecto en la cabeza del usuario, como página web eterna e indexable. Esa brecha entre intención y comportamiento real es el agujero.

Si el enlace existe y la página se puede rastrear, el secreto no está “entre tú y Claude”. Está donde llegue cualquiera con la URL o con un buscador lo bastante listo. Tras el arreglo de noindex, el riesgo de indexación masiva baja; el riesgo de “alguien con el enlace lo reenvía, lo pega en un ticket o lo deja en un Notion abierto” sigue igual. La función sigue siendo compartir. Compartir implica superficie de exposición.

Requisitos antes de tocar nada

• Cuenta en Claude (web) con la que creaste o puedes administrar los chats compartidos.
• Lista mental o escrita de lo que no debería haber salido nunca de tu máquina: API keys, tokens, connection strings, historiales clínicos, datos de menores, código con credenciales.
• Acceso al gestor de secretos o a las consolas de los proveedores si tienes que rotar algo (OpenAI, GitHub, AWS, Stripe, lo que uses).
• Media hora sin prisa. Revocar enlaces es rápido; auditar qué había dentro y rotar bien, no.

No hace falta plan de pago concreto para lo que sigue: la gestión de chats compartidos está en la propia cuenta. Tampoco hace falta borrar “todas tus conversaciones con Claude”, nadie ha pedido eso en las fuentes serias, y sería teatro, no contención.

Paso a paso: inventariar y matar enlaces públicos en Claude

Primero el incendio visible. Luego la fontanería.

1. Lista los chats que tienen enlace público

1. Entra en Claude con la cuenta afectada.
2. Ve a Configuración → Privacidad → Chats compartidos (el camino que marcan las coberturas del incidente).
3. Revisa uno a uno. No asumas que “solo compartí dos”: la memoria es basura bajo estrés.

Si no encuentras el menú de privacidad en tu layout, hazlo desde el propio hilo:

1. Abre el chat.
2. Pulsa la flecha de compartir.
3. Elige Mantener privado para revocar el acceso público.

Las dos vías hacen lo mismo: el enlace deja de servir como puerta abierta. Usa las dos si tienes dudas de que el panel liste todo.

2. Revoca con el cubo de basura, no “confíes en que nadie tiene la URL”

En la lista de chats compartidos, elimina el enlace público con el icono de basura. Eso es la acción explícita de “este share muere”. Guardar la URL en un gestor de contraseñas “por si acaso” es reabrir la puerta con otro nombre.

3. Busca tu propia basura en los índices (con realismo)

• Prueba site:claude.ai/share y, si recuerdas fragmentos únicos de tus hilos (un nombre de proyecto interno, un error muy concreto), búscalos entre comillas.
• Mira también Bing y, si puedes, un tercero (en el incidente, Brave y Bing siguieron mostrando cosas cuando Google ya limpiaba).
• Si aparece algo tuyo: captura la URL, revoca en Claude, y no te quedes solo en borrar el enlace. Pasa al inventario de secretos de la sección siguiente.

No vas a obtener una cifra mágica de “cuántos de los míos se indexaron”. Las fuentes hablan de miles en global, sin desglose por usuario. Trabaja con lo que puedas verificar en tu cuenta y en buscadores, no con el miedo abstracto.

4. Avisa a quien tenga el enlace legítimo

Si el share era para un compañero, dile que el enlace viejo muere y que el próximo, si hace falta, va sin secretos o por un canal que no sea página pública (export redactado, ticket interno, llamada). El hábito de “te paso el chat de Claude” es cómodo y es exactamente cómo se industrializa la fuga.

El checklist que de verdad evita el siguiente funeral: secretos en el artefacto

Revocar el share es higiene. La guía de uso que te salva el trimestre es cómo miras un artefacto antes de que salga de tu control. Aplica a un enlace de Claude, a un export markdown, a un log de agente y a un “artefacto de ejecución” que mañana sube a prod con otra config.

Inventario antes que rotación

Monta un inventario fuera de git, en el gestor de contraseñas o en una hoja con acceso cerrado. Una fila por credencial:

Campo	Para qué sirve
Qué es	“API key de proveedor X”, no “clave1”
Qué producto la usa	Servicio concreto
Dónde vive	Gestor, variable de entorno, KMS…
Quién la emitió	Persona o sistema
Radio de daño si se filtra	Lectura, escritura, pasta, datos personales
Pasos exactos para rotarla	El campo que convierte un fin de semana en veinte minutos

Sin ese último campo, “hay que rotar” es teatro de war room. Con él, rotas en orden y sin cortar todo el producto a la vez.

Reglas prácticas, en orden de valor:

1. Un .env por producto, permisos chmod 600, dueño el usuario del servicio. Si corres todo como root, el fallo de cualquiera es root.
2. umask 077 al inicio de todo script que escriba datos o secretos (backups incluidos).
3. Nunca imprimir el valor de un secreto. Un set -x en un script con env sensible lo vuelca al log, el log al backup, y el backup a la eternidad.
4. Linter de .env en el preflight: que falle con líneas no parseables, CRLF o claves obligatorias ausentes.
5. Hook pre-commit anti-secretos: rechaza patrones (sk-, ghp_, AKIA, -----BEGIN) y cualquier fichero llamado .env. Diez líneas; más barato que una rotación de emergencia.
6. Los .env van al backup cifrado. No están en git por diseño; si tampoco están respaldados, el día del incidente pierdes el mapa y las llaves.

Rotación por evento, no por calendario de postureo

Se rota cuando:

• hay sospecha de filtración;
• el secreto apareció en un log, un commit, un chat compartido o cualquier artefacto;
• cambias de proveedor;
• se va alguien con acceso;
• una credencial que nació en desarrollo ha tocado producción.

Lo que sí va por calendario de verdad es lo que limita el radio de daño: topes de gasto en la consola de cada proveedor y claves con el mínimo alcance posible. Un tope de 50 €/mes protege de una clave filtrada mejor que rotarla cada trimestre “porque toca”. Excepciones que se rotan siempre: tokens de consumidor propios (rotación trivial, es config) y cualquier secreto que haya vivido en dev y luego en prod.

Ensayo obligatorio: una vez, rota una clave de principio a fin siguiendo tu propio inventario. Descubrirás el paso que no escribiste. Mejor un martes aburrido que el domingo del incidente.

Un secreto que tocó Git (o un share indexable) está quemado

Nada de secretos en el código, en la imagen Docker ni en una URL (las URLs viven en logs e historiales). .env en .gitignore el día uno. Escáner tipo gitleaks en el pipeline. Si se filtra: se rota, no se disculpa.

En Docker el secreto se inyecta al arrancar, nunca se hornea en la imagen: las capas se inspeccionan. El paralelo con Claude es directo: no “hornees” la key en el hilo que luego conviertes en share. Pega un placeholder, usa el valor real solo en el entorno que lo necesita, y si ya lo pegaste, asume quema.

Redacción en logs: por clave y por valor

Dos comprobaciones, no una. Por nombre de clave y contra los valores reales de las variables sensibles del entorno:

CLAVES = re.compile(r"(token|secret|key|password|authorization|cookie)", re.I)

def redactar(logger, method, event: dict) -> dict:
    for k, v in list(event.items()):
        if CLAVES.search(k):
            event[k] = "***"
        elif isinstance(v, str) and any(
            s and len(s) > 12 and s in v for s in SECRETOS_ENV
        ):
            event[k] = "***valor-de-secreto-redactado***"
    return event

La segunda es la que cierra la fuga. El umbral de longitud evita que un secreto corto o vacío te redacte medio log por casualidad. Test mínimo: assert TOKEN not in caplog.text.

Y una lista corta de lo que no escribes aunque no sea “secreto técnico”:

• Tokens, API keys, cabeceras Authorization, contraseñas, cookies de sesión.
• Cuerpos enteros de peticiones con datos personales: campos escogidos, contadores o hashes.
• Emails y teléfonos en claro en logs de retención larga: enmascara o usa un hash corto para correlacionar.
• Prompts y respuestas íntegras de LLM en el log general: ruido, peso y datos de cliente. Van a su tabla de trazas con retención propia.

Un chat de Claude no es un log… hasta que lo compartes, lo exportas o lo pegas en un ticket. Entonces se comporta igual: texto longevo con valores en claro.

Cómo preparar un chat (o cualquier artefacto) antes de compartirlo

Esto es el ritual de los que ya se han quemado una vez.

1. Copia el hilo a un buffer local (export, pegar en editor). No redactes solo “con la vista” en la UI: se te escapa la key en el mensaje 47.
2. Busca patrones, no solo la palabra “password”:
   • prefijos sk-, ghp_, AKIA, xox, -----BEGIN
   • api_key, token, Bearer , connection strings postgres://, mysql://
   • emails y teléfonos si el destinatario no los necesita
   • nombres de menores, historias clínicas, nóminas, contratos
3. Sustituye por placeholders del tipo {{STRIPE_KEY}} y documenta fuera del artefacto cómo obtener el valor real.
4. Recorta el radio: comparte el tramo del hilo que hace falta, no la autobiografía del debug de tres días.
5. Elige canal: si el destinatario está en tu org, un doc interno o un ticket suele ser menos estúpido que una URL pública eterna.
6. Pon fecha de caducidad mental: si el share ya no hace falta en 48 h, revócalo a las 48 h. No esperes al próximo titular.

El mismo checklist vale cuando el “share” es un agente que escribe a un bucket, un pipeline que publica artefactos de CI o un notebook que se sincroniza a un drive “solo de equipo”. El botón cambia; el artefacto no.

Tokens y sesiones: nace con caducidad y con forma de matarlo

Si además de usar Claude construyes productos que emiten tokens (sesión de usuario, dispositivo, service-to-service), cinco decisiones al emitir:

1. exp obligatorio y corto, 30-60 minutos para persona; dispositivo más largo (30-90 días) pero fechado y anotado, nunca infinito.
2. jti siempre y tabla de revocados o sesiones con estado consultada en el middleware. Es una lectura por clave primaria; es el precio de poder cortar el día D.
3. Alcance mínimo en el payload, sujeto, jti, exp, aud. Roles y permisos que cambian se leen de base en cada petición; si van en el token, un cambio de permisos tarda una caducidad en aplicarse.
4. Un secreto y un aud por servicio. Reutilizar el mismo secreto entre productos convierte cualquier token en pase multipase.
5. Un botón de revocar en el panel, con última vez visto del dispositivo. Un mecanismo de emergencia sin interfaz no se usa el día del incidente.

Tests que casi nadie escribe y que separan el discurso de la realidad: emitir → revocar → la siguiente petición es 401; token con exp pasado → 401; aud de otro servicio → 401; fallar el build si la emisión produce token sin exp o sin jti.

En la nube, el paralelo es aburrido y correcto: mínimo privilegio en IAM, root intocable tras el primer día, base de datos en subred privada, alarma de billing antes que casi cualquier otro recurso, secretos de aplicación en un gestor. No en el prompt. No en el share.

Errores comunes (los que comete casi todo el mundo)

• Creer que “compartir con enlace” = privado entre dos. Es público para quien tenga la URL; y sin noindex, también para el buscador. Las coberturas del incidente lo repiten porque la gente sigue sin creerlo.
• Confiar solo en robots.txt. En este fallo había robots y aun así se indexó lo que no llevaba noindex. Robots es un acuerdo de caballeros con excepciones y matices; no es un ACL.
• Rotar en pánico sin inventario. Tocas la clave del servicio equivocado, dejas la filtrada viva, o tiras prod sin tener los pasos. Inventario primero; rotación después.
• Redactar logs solo por nombre de campo. El token acaba en message, error, debug_dump o en el cuerpo del prompt. Hay que mirar valores.
• Dejar la key de prod en el chat de “pruebas”. Mismo artefacto, otra etiqueta de entorno. El crawler no lee tu etiqueta.
• Dar por cerrado el incidente cuando Google limpia. En julio de 2026 aún quedaban restos en otros buscadores horas después. Amplía la búsqueda y asume cola de caché.
• No ensayar la rotación. El primer run del playbook no debería ser con dinero de verdad en juego.
• Pegar prompts y respuestas completas de clientes en el log general. Además de privacidad, es peso y ruido. Tabla de trazas con retención propia.

Qué hacer si ya pegaste un secreto en un chat (compartido o no)

1. Trátalo como filtración, no como “seguro que no lo ha visto nadie”.
2. Revoca shares de ese hilo y de cualquier export que cuelgue de él.
3. Rota la credencial con el procedimiento del inventario. No “la cambias luego”.
4. Revisa topes de billing y permisos de esa clave mientras tanto: si no puedes rotar en cinco minutos, al menos que no puedan llevarse la cuenta entera.
5. Busca el valor en tus logs, tickets y backups con el redactor y con búsqueda a conciencia. El share de Claude puede ser la puerta de entrada; el eco suele estar en otro sitio.
6. No dependas de una disculpa del proveedor ni de un comunicado. Las fuentes del incidente no hablan de compensaciones épicas ni de confesiones de negligencia: hablan de configuración, de controles del sitio y de usuarios retirando enlaces. La parte que controlas es la tuya.

Cierre sin sermón

El incidente de Claude no inventa un género nuevo de desastre. Pone un buscador delante de un hábito que ya teníamos: tratar los artefactos de la IA como borradores desechables cuando en realidad son documentos con vida propia que ascienden de entorno, de canal y de audiencia sin pedir permiso. El mismo objeto; solo cambia la config.

Abre Claude, limpia los shares, corre el checklist sobre el último artefacto que mandaste y rellena el campo “pasos para rotar” de al menos una clave crítica. Eso es más útil que cualquier hilo de LinkedIn sobre “privacidad en la era de la IA”.

Preguntas frecuentes

¿Por qué salían en Google los chats compartidos de Claude?

Porque las páginas de share no llevaban la etiqueta noindex y los motores pudieron rastrearlas e indexarlas. La URL seguía el patrón https://claude.ai/share/ más un identificador; una búsqueda site:claude.ai/share listaba conversaciones. Había robots.txt, pero no bastó. Lo reportaron medios como La Vanguardia, Hipertextual y El Español a finales de julio de 2026.

¿Cómo quito el enlace público de un chat de Claude?

Desde Configuración → Privacidad → Chats compartidos puedes eliminar el enlace con el icono de basura. También, dentro del chat, en la flecha de compartir, la opción Mantener privado revoca el acceso público. Haz las dos cosas si no estás seguro de que el panel liste todos los shares antiguos.

¿Basta con borrar el enlace o tengo que rotar contraseñas?

Si en el hilo hubo API keys, tokens, contraseñas o datos personales sensibles, borra el enlace y rota esas credenciales. Un secreto que ha vivido en un artefacto accesible se considera quemado. Revocar el share cierra la puerta; no invalida una clave que ya pudo copiarse o cachearse en otro buscador.

¿Los chats privados de Claude también se indexan?

Anthropic afirma que los chats privados no se indexan salvo que el enlace se publique en una web pública, y que no entrega directorios ni sitemaps a buscadores. El problema documentado afectó a conversaciones compartidas por enlace cuando la página era rastreable. Eso no elimina el riesgo de reenvío manual del enlace o de pegar el mismo contenido en otro sitio abierto.