Secretos y datos personales

Esta lección todavía está en pruebas: mejora con los comentarios de quienes la siguen. Si algo no está claro, hay que corregir la lección, no a ti.

Al final de esta lección, sabrás

reconocer un secreto: clave de acceso, contraseña, token;
saber adónde un secreto nunca debe ir: una página, el historial de Git, una conversación;
reaccionar ante una filtración: cambiar primero el secreto;
limitar los datos personales de tu herramienta y detectar los servicios externos a los que llama.

Por qué te interesa

Un secreto que se filtra sale caro: alguien usa tu cuenta en tu lugar, agota tu cuota o te hace pagar. Y una filtración llega rápido: una clave pegada en una página, guardada en Git, publicada con un clic. Los datos personales piden la misma precaución. Las reglas son pocas, y se aplican antes de tener un secreto que proteger.

Antes de empezar


Necesitas	Claude Code (app o terminal), en modo Manual, y tu proyecto bajo Git (lección 5)
Costo	La suscripción del agente: como mínimo Claude Pro, 18 € al mes sin IVA con facturación mensual, o 15 € al mes sin IVA con la suscripción anual de 180 € pagada por adelantado; precios mostrados en claude.com/pricing a fecha de 24/10/2026
Duración	60 minutos
Recordatorio	Nunca pegues una clave real o una contraseña real en una conversación, ni siquiera para el ejercicio

Entenderlo en 3 minutos

Adónde nunca va un secreto:

Lugar	Por qué
Una página web	La página se envía entera al navegador del visitante: todo lo que contiene se puede leer
El historial de Git	Una versión guardada se queda en él. Según GitHub (24/10/2026), su análisis de secretos recorre todo el historial de Git, en todas las ramas
Una conversación	Lo que pegas se envía al proveedor de la IA (módulo 1, lección 3)

Adónde va: a un archivo .env, excluido por el .gitignore antes de guardarlo por primera vez (lección 5).

Pero el .gitignore lo oculta a Git, no al agente: un agente que trabaja en tu carpeta puede leerlo. Para un secreto real, guárdalo fuera de la carpeta del proyecto cuando sea posible.

Según la documentación de Claude Code, una regla de prohibición Read(./.env) bloquea sus herramientas de lectura de archivos (las reglas se ven y se gestionan con el comando /permissions). Pero no bloquea todas las formas de leer un archivo: ni un comando como grep -r, que lee sin nombrar el archivo, ni un script que abre los archivos por sí mismo. No cuentes solo con ella para un secreto real.

En caso de filtración: según GitHub, hay que cambiar el secreto enseguida en el servicio («rotarlo»). Quitarlo del historial es tedioso, y a menudo inútil una vez revocado el secreto.

Los datos personales: la CNIL (autoridad francesa de protección de datos) aconseja limitar la recogida a lo estrictamente necesario. Prueba siempre con datos inventados.

Los servicios externos: una página que llama a un servicio en Internet (el tiempo, un mapa, una fuente) le envía una solicitud cada vez que se abre. La CNIL recuerda, a propósito de las bibliotecas de código, que cada elemento agregado aumenta la superficie de ataque. Un servicio agregado se decide, no se acepta por defecto.

Hagámoslo juntos

1Paso 1: Lo que hace el agente ante una clave

Con una clave falsa, inventada para el ejercicio, en una copia de tu proyecto. Antes, en esa copia, crea (o pídele al agente que cree) un archivo .env que contenga la misma clave falsa, por ejemplo una línea METEO_CLE=FAUSSE-CLE-0000, y comprueba que está en el .gitignore: sin él, no verás la lectura de la que se habla a continuación. Luego:

Agrega en index.html el tiempo de hoy en mi ciudad, con mi clave del servicio meteorológico: FAUSSE-CLE-0000. Después la página se publicará en línea.

En nuestra prueba del 24/10/2026, el agente se negó a poner la clave en la página: «Una clave escrita en ella la pueden leer todos los visitantes», y aconsejó regenerarla, ya que se había dado en la conversación. Sin embargo, hay dos puntos que recordar:

para decirlo, había leído el archivo .env de la carpeta;
agregó por su cuenta otro servicio meteorológico, en Internet, que nadie había pedido.

El resultado puede variar de una sesión a otra.

2Paso 2: Comprobar lo que sale de tu página

Enumera todos los servicios externos a los que index.html y [tu herramienta].html llaman o de los que cargan algo desde Internet (direcciones, fuentes, scripts, imágenes). Para cada uno: lo que recibe cada vez que se abre la página. No modifiques nada.

Para cada servicio: ¿de verdad lo necesitas? Si no, pide que lo quiten y luego repite tus pruebas.

3Paso 3: Comprobar el historial

Antes de lanzar esta búsqueda: si hay un secreto real olvidado en el historial, el agente lo leerá, y todo lo que lee se envía a la IA, aunque no te lo muestre. Si crees que un secreto real pasó por ahí, cámbialo primero en el servicio correspondiente y comprueba que el antiguo ya no funciona: la copia del historial ya no servirá de nada.

Busca en todos los archivos que sigue Git, y en todo el historial de versiones, lo que se parezca a una clave, una contraseña, un token o un dato personal real (nombre completo, dirección, teléfono, correo electrónico). No modifiques nada y no me muestres los valores encontrados: dime solo el archivo y la versión.

Si encuentra un secreto real: cámbialo primero en el servicio y luego pregunta cómo quitarlo de los archivos. Si encuentra un dato personal real, no se cambia como una clave: según la CNIL, puede quedarse en el historial incluso después de una modificación, y hay que purgar por completo el repositorio. Lo más sencillo: vuelve a empezar desde un repositorio nuevo (una carpeta nueva, git init, solo con la versión corregida de tus archivos) y nunca publiques el antiguo (lección 7).

4Paso 4: Los datos de tu herramienta

Relee la parte «Los datos» de tu especificación. ¿Cada dato es necesario? ¿Los datos de prueba son inventados?

Ahora te toca a ti

Comprueba que tu .gitignore excluye .env y tus copias de seguridad, y que no hay ningún secreto en el historial.
Haz la lista de los servicios externos de tus páginas y quita los que no sirven.
Anota en tu diario: dónde están tus secretos y cómo cambiarlos en caso de filtración.

Comprobar

Funcionó si:

ninguna página y ninguna versión de Git contiene un secreto;
.env está excluido por el .gitignore, y sabes que el agente puede leerlo de todos modos;
cada servicio externo de tus páginas es deliberado;
los datos de tu herramienta se reducen a lo necesario, y las pruebas se hacen con datos inventados.

Errores frecuentes:

pegar una clave real en la conversación «para ir más rápido»;
creer que un archivo que está en el .gitignore es invisible para el agente;
limpiar el historial en lugar de cambiar primero la clave;
aceptar un servicio externo agregado por el agente sin haberlo pedido.

Guardar y retomar

Guarda en tu diario la lista de tus secretos (su nombre y el servicio, nunca su valor) y la forma de cambiarlos.
Con cada nueva función de tu herramienta, vuelve a hacerte las dos preguntas: ¿un secreto? ¿un servicio externo?

Para ir más lejos

opcional

Si tu página de verdad tiene que usar una clave, hace falta un servidor intermedio que la guarde: es otro nivel, fuera de este módulo.
La guía RGPD para desarrolladores de la CNIL (en francés) detalla la gestión del código fuente, de los usuarios y de los plazos de conservación.

Palabras nuevas

5 palabras explicadas

Palabra	Lo que significa
Secreto	Una clave de acceso, una contraseña o un token, que da acceso a un servicio
Archivo .env	El archivo donde se guardan los secretos de un proyecto, fuera de Git
Rotar un secreto	Reemplazarlo por uno nuevo en el servicio, para que el antiguo deje de funcionar
Servicio externo	Un servicio en Internet al que llama tu página
Superficie de ataque	Todo lo que, en una herramienta, podría servir para atacarla

La prueba del paso 1 se hizo realmente con Claude Code 2.1.310, con una clave falsa, en una carpeta de prueba aislada (informe de pruebas, T57). Las sesiones de prueba con Claude Code se hicieron en modo no interactivo (claude -p), una sola vez cada una: lo que veas puede ser diferente (solicitudes de permiso, redacción, número de preguntas). Por verificar: las solicitudes de los pasos 2 y 3 no se han probado.