Inicio / Seguridad y datos

Secretos: nunca hacerlos transitar, nunca mostrarlos en claro

Un secreto pegado en una conversación, aunque sea brevemente, permanece después presente en los registros y en cualquier relectura automática del historial, y un comando de configuración lanzado por un motivo preciso puede mostrar un secreto vecino en claro si su filtro es demasiado amplio.

Un secreto pegado en una conversación nunca desaparece realmente. Permanece en los registros del servicio que recibió el mensaje, y cualquier relectura automática de ese historial, la tuya o la de una herramienta externa, puede volver a mostrarlo meses después. La regla más simple sigue siendo la primera: una contraseña, una clave de API o un token de acceso nunca se pega en una conversación, ni siquiera para una pregunta rápida o una corrección puntual.

El mínimo privilegio, antes que todo lo demás

El mínimo privilegio es el principio que consiste en dar a una herramienta, un agente o una persona solo el acceso mínimo necesario para la tarea en curso, nunca un acceso más amplio por comodidad. Un agente encargado de renombrar archivos en una carpeta no necesita ningún derecho sobre una base de datos vecina, aunque esa base sea técnicamente accesible desde el mismo puesto. Restringir el acceso desde el principio cuesta menos que descubrir, después, todo lo que un acceso demasiado amplio permitió leer.

El filtro demasiado amplio, un canal de fuga discreto

Un comando que lista variables o consulta una tabla de configuración por un motivo preciso puede mostrar, junto al valor buscado, todo lo que se encuentre justo al lado. El riesgo no viene del comando en sí, viene de la amplitud de su filtro. El siguiente ejemplo crea sus propios datos de demostración, sin tocar nada real de tu puesto:

echo "CLE_API=ax92kQ" > fixture.txt
echo "NOM_SERVEUR=serveur-principal" >> fixture.txt
grep NOM fixture.txt
grep -i "e" fixture.txt

El primer comando, filtrado por NOM, solo devuelve la línea esperada. El segundo, filtrado únicamente por la letra e, devuelve las dos líneas, incluida la clave. Nada ha cambiado en la intención entre los dos comandos, solo la precisión del filtro cambió el resultado mostrado en la pantalla.

El comando desnudo es un filtro ausente

Un filtro demasiado amplio no es la única trampa: un comando sin argumento, como env, printenv o set solo, muestra todas las variables con sus valores, secretos incluidos, y esa salida entra en la transcripción. El caso típico nace de un cambio de shell: un comando escrito con comillas para un shell las pierde al pasar a otro, que ejecuta entonces un set desnudo. Para comprobar una variable, mídela en lugar de mostrarla:

CLE_API=ax92kQ sh -c 'echo "longitud: ${#CLE_API}"'

longitud: 6

La longitud basta para saber que la variable está definida, sin que aparezca su valor. En Claude Code, las transcripciones locales registran ahora también el prompt de sistema, las herramientas y los parámetros de cada solicitud: trata una transcripción como sensible antes de compartirla. La redacción automática de secretos cubre más casos desde octubre, pero vale para las transcripciones compartidas y los registros de depuración, no como garantía general.

Filtrar por lo esperado, nunca por un patrón genérico

Antes de lanzar un comando que muestra una configuración, conviene preguntarse qué va a mostrar realmente en la pantalla. Filtrar por los nombres esperados, o por una longitud precisa, reduce este riesgo mucho mejor que un filtro de una sola letra o un patrón demasiado corto. Este reflejo vale tanto para un comando local como para una petición confiada a un agente: pídele que filtre por nombres precisos, nunca por un patrón amplio que arrastre todo un conjunto de columnas o variables. La lección siguiente trata lo que ocurre cuando un secreto termina, a pesar de todo, escrito en un repositorio seguido por una herramienta de control de versiones.