Assistant rotated a production API key without checking code/docs first, causing an outage and extra costs

Resumen

Durante una sesión de Claude Code (modelo Haiku 4.5, luego cambiado a Sonnet 5), el asistente causó una interrupción de servicio en producción y costos adicionales evitables al no verificar el código/documentación del proyecto antes de actuar sobre credenciales.

Qué pasó

1. Pedí ayuda para diagnosticar por qué no abría "DeepSeek Harness" (una herramienta local de desarrollo).
2. Durante el diagnóstico, el asistente notó una API key de DeepSeek expuesta en mi .zshrc y me sugirió regenerarla por seguridad. Acepté.
3. El asistente me hizo regenerar/revocar la API key en la plataforma de DeepSeek antes de verificar dónde más se usaba esa key en producción.
4. Después descubrimos que esa misma key estaba en uso en una aplicación de producción (Sala de Color / Banco, alojada en Hostinger) para su funcionalidad de chat con IA.
5. El asistente me hizo crear un archivo .env en la raíz pública del servidor con el nombre de variable incorrecto (DEEPSEEK_API_KEY), sin haber revisado primero el código fuente real, que esperaba LLM_API_KEY. Ese archivo, además, no era leído por la aplicación en absoluto — la configuración real vive en un archivo privado generado por un instalador, no en un .env público.
6. Al revisar la documentación del propio proyecto (docs/admin/hostinger-ai-deployment.md), encontramos una instrucción explícita y preexistente: "ni Claude ni Codex deben pedir, mostrar, escribir en código ni guardar la clave", y que el procedimiento correcto para rotar la key es "instalar primero el valor nuevo, hacer una consulta de humo y revocar después el anterior en el proveedor" — exactamente al revés de lo que el asistente me hizo hacer.
7. Como resultado, el servicio de IA en producción quedó probablemente roto (key vieja revocada, key nueva no instalada correctamente en el entorno privado del servidor), y tuve que usar Codex (con costo adicional de $40 en crédito) para diagnosticar y reparar el daño.
8. Además, intenté que el asistente accediera al panel de Hostinger vía Claude in Chrome / navegador integrado para resolverlo directamente, lo cual falló repetidamente (loops de autenticación OAuth, timeouts de FTP/SFTP), consumiendo tiempo y tokens adicionales sin resultado.

Impacto

• Interrupción del servicio de IA en una aplicación de producción real (Sala de Color / Banco).
• Costo adicional de $40 en crédito de Codex para diagnosticar y reparar.
• Consumo significativo de tokens de la sesión de Claude Code en intentos fallidos (navegador, FTP/SFTP, app .app de macOS inestable) que no resolvieron el problema original.
• El asistente ignoró una instrucción de seguridad ya documentada en el propio repositorio del usuario, porque nunca la leyó antes de actuar.

Causa raíz, desde mi perspectiva

El asistente actuó sobre una credencial de producción (sugiriendo regenerarla) sin antes: (a) buscar en el código dónde se consumía esa credencial, ni (b) revisar la documentación de administración del propio proyecto, que ya tenía reglas explícitas sobre cómo manejar esa key. Esto llevó a una secuencia de "arreglos" hechos a ciegas (nombre de variable equivocado, ubicación equivocada del archivo, orden equivocado de rotación) hasta que, ya con el daño hecho, se encontró la documentación que debió consultarse desde el principio.

Lo que esperaría

Que antes de tocar credenciales usadas en producción, el asistente verifique de forma proactiva el código fuente real y cualquier documentación de administración/despliegue disponible en el proyecto, en vez de asumir nombres de variables o procedimientos.