La mayoría de los consejos sobre seguridad de claves API están pensados para el momento en que una clave acaba en un commit de un repositorio público. Es un problema real y las herramientas para afrontarlo están maduras — pero no es la única forma en que una clave se escapa y, para los desarrolladores que pasan buena parte del día pegando cosas en ChatGPT, Claude, Slack y formularios de soporte, a menudo ni siquiera es la más habitual. Esta es una lista más corta y más cotidiana: hábitos que mantienen las claves fuera de los chats y los tickets, no solo fuera del historial de git.
1. Limita el alcance de las claves
Una única clave API con acceso total a la cuenta es cómoda — hasta el día en que es justo la que pegas por error en algún sitio. Cuando el proveedor lo permita, usa claves por entorno, por proyecto o por servicio en lugar de una sola clave reutilizada en todas partes. La distinción de Stripe entre sk_test_ y sk_live_ es un buen modelo: una clave de prueba filtrada es una molestia, una clave live filtrada es un incidente. Si tu proveedor ofrece claves limitadas a un proyecto o con permisos restringidos, ese ajuste merece los cinco minutos extra de configuración — es la diferencia entre «rotar una clave» y «rotar todo lo que esa clave podía tocar».
2. Rota las claves con regularidad, no solo tras un incidente
La rotación suele tratarse como un paso de respuesta a incidentes — algo que haces cuando ya sabes que una clave se ha filtrado. Tratarla como mantenimiento rutinario (cada trimestre, o con la frecuencia que encaje en tu equipo) hace que una clave filtrada en silencio, sin que nadie lo note, acabe invalidándose igualmente. También mantiene el proceso de rotación bien ensayado, así que cuando tengas que hacerlo con urgencia, no será la primera vez.
3. Mantén los secretos fuera de cualquier texto que podrías seleccionar entero y copiar
Escribir una clave directamente en el código es el caso obvio que todo el mundo ya evita. La versión más sutil es un archivo .env, un volcado de configuración o un print de depuración justo al lado del código que quieres compartir — lo bastante cerca como para que «copiar el archivo relevante» o «pegar toda la configuración para enseñar mi setup» lo arrastre de paso. Si un valor solo necesita existir en una variable de entorno o en un gestor de secretos, déjalo ahí, y desconfía especialmente de cualquier salida de depuración que imprima un objeto de configuración o de entorno completo en lugar del único campo que importa.
4. Trata el chat de IA y los tickets de soporte como un canal que no controlas
La mayoría de los desarrolladores ya tienen el reflejo de no pegar secretos en una issue pública de GitHub. Esa misma prudencia no siempre se traslada a una ventana de chat de IA o al formulario de soporte de un proveedor, aunque en ambos casos el contenido sale de tu máquina y acaba en un sitio regido por la política de datos de otra persona. Una comprobación rápida antes de pegar en cualquiera de ellos: ¿pegaría esto en un gestor de incidencias público? Si no, merece una segunda mirada antes de ir a una ventana de chat.
5. Oculta antes de pegar, no después
La versión más fiable de «tener cuidado» es una comprobación que ocurre automáticamente al pegar, en lugar de un hábito que hay que recordar cada vez — sobre todo en mitad de una depuración, cuando la atención está en el problema y no en el portapapeles. Ya sea revisando a mano cualquier cosa tras un = o : que parezca una clave o una contraseña, o con una herramienta que haga ese análisis por ti, el momento importa más que el método: detectarlo después de copiar, antes de que llegue a otro sitio.
6. Vigila los archivos .env en demos y sesiones de depuración
Las pantallas compartidas, las demos grabadas y las sesiones de «te pego todo mi setup» son una fuente desproporcionada de claves expuestas, precisamente porque son momentos en los que enseñar más parece útil. Un repaso rápido a un archivo .env antes de compartir pantalla — o una herramienta que oculte automáticamente los formatos de secretos conocidos — cuesta poco y cierra un hueco que la higiene del código por sí sola no cubre.
7. Sabe lo que cuesta realmente una clave filtrada y actúa en consecuencia
Si una clave acaba donde no debería — un historial de chat, un documento compartido, un ticket de soporte — la solución no es borrar el mensaje. La mayoría de las herramientas de chat y de tickets no garantizan que los datos desaparezcan una vez enviados, y normalmente no tienes visibilidad de lo que ya se ha leído, registrado o guardado en caché al otro lado. Revoca y rota la clave de inmediato, y trata «no estoy seguro de si esto cuenta como una filtración real» como un motivo para rotarla igualmente, no para esperar a ver qué pasa.
Nada de esto garantiza que nunca vayas a filtrar una clave — ninguna checklist puede hacerlo. Es un conjunto de hábitos que reducen la frecuencia con la que ocurre y limitan el daño los días en que ocurre de todos modos.
