IA en CLI: cómo Claude Code, Cursor y Copilot CLI exponen sus secretos

Sus ingenieros senior ya escriben claude . en la terminal

Hace tres años, el riesgo de IA para un equipo de seguridad era un desarrollador junior pegando código en ChatGPT. Ese problema está prácticamente resuelto con una extensión de navegador y una política escrita. El problema nuevo es distinto y mucho más difícil: sus ingenieros más senior están ejecutando agentes CLI que leen activamente archivos del disco y los transmiten a un modelo de frontera, a menudo cientos de veces por sesión.

Claude Code refactoriza un servicio. El modo agente de Cursor reescribe un directorio entero. Copilot CLI explica un error de shell. Aider hace pair programming. Codex CLI ejecuta una tarea larga. Todas estas herramientas hacen lo mismo por debajo: leer archivo, enviar al modelo, aceptar llamada a herramienta, leer más archivos. El desarrollador nunca ve cómo los bytes salen de la máquina.

No hay problema, salvo cuando una de esas lecturas es .env, ~/.aws/credentials o ~/.ssh/id_rsa. En ese momento, su clave root de AWS, su clave Stripe de producción o su identidad SSH de producción están en la caché de contexto de un proveedor de LLM, posiblemente en logs elegibles para entrenamiento, posiblemente en la tabla de auditoría de un servidor MCP de terceros.

La nueva norma: agentes que leen archivos en portátiles de desarrolladores

Mire lo que un ingeniero típico de una startup en serie B tiene corriendo ahora mismo:

• Claude Code abierto en la raíz de un proyecto, con permiso para leer cualquier archivo del workspace.
• Cursor con modo agente habilitado, indexando todo el repositorio para contexto.
• GitHub Copilot CLI respondiendo preguntas sobre comandos de shell, lo que significa que lee lo que el error referencie.
• Aider en una terminal lateral, a veces apuntado a ~/scripts o ~/dotfiles.
• Un servidor MCP conectando alguno de los anteriores con Postgres, GitHub, Linear o una herramienta interna a medida.

Cada uno es un multiplicador real de productividad. Cada uno es también un cable entre su sistema de archivos local y un LLM en la nube. Sus controles existentes — gitleaks en CI, secret scanning al push, una extensión DLP de navegador — están al lado equivocado de ese cable.

Cinco vectores de fuga reproducibles en cinco minutos

1. La lectura "servicial" de .env

La fuga más común. Un desarrollador está conectando un servicio nuevo y le pide ayuda al agente:

$ claude
> ayúdame a configurar este webhook de Stripe, las claves están en .env

[Claude Code] Voy a leer su archivo .env para ver la configuración actual.
[leyendo .env]
[leyendo webhook_handler.py]

El .env entero — incluyendo STRIPE_SECRET_KEY=sk_live_…, DATABASE_URL=postgres://user:password@… y la clave de OpenAI que el equipo olvidó que estaba ahí — acaba de viajar en claro a un modelo de frontera, además a la caché de contexto del proveedor, además a cualquier log de auditoría MCP en la ruta.

2. Credenciales AWS durante una sesión de depuración

Un ingeniero depura un script boto3 que devuelve 403 contra S3. El agente pide inspeccionar las credenciales:

$ usted
> este script sigue dando AccessDenied en s3:GetObject

[Claude Code] Déjeme revisar su configuración de AWS.
[leyendo ~/.aws/credentials]
[leyendo ~/.aws/config]
[leyendo deploy.py]

~/.aws/credentials normalmente contiene todos los perfiles que el ingeniero ha usado: sandbox personal, cuenta de staging, a veces un rol break-glass de producción. Todo aterriza en el contexto del modelo.

3. Claves hardcodeadas en código — con todo el contexto alrededor

Este es el peor porque la fuga parece invisible. Un archivo tiene una clave que nunca debió estar ahí:

$ claude
> refactoriza billing_service.py para extraer la lógica de Stripe

[Claude Code] Leyendo billing_service.py (412 líneas)…

La línea 38 de ese archivo contiene STRIPE_KEY = "sk_live_51H…". El agente la ve, refactoriza alrededor y — según el modelo — puede devolverla literalmente en su diff planeado. Aunque no lo haga, el archivo completo con esa clave ya está en los logs del proveedor.

4. Arqueología con git log -p

A los agentes les encanta ejecutar git para entender el historial. Es uno de los patrones más dañinos:

$ claude
> ¿cuándo cambiamos el flujo de autenticación por última vez?

[Claude Code] Voy a revisar el historial de git.
[ejecutando: git log -p --all -- src/auth/]

Ese comando saca a la superficie cada parche aplicado a los archivos de autenticación. La credencial que alguien commiteó en 2022, force-pusheó fuera de main y nunca rotó porque "no está en el árbol actual" — sigue en el reflog. git log -p --all se la entrega íntegra al modelo.

5. Clave privada SSH en una espiral de error de conexión

Un ingeniero no puede hacer ssh a un jumpbox. Le pregunta al agente:

$ claude
> mi ssh a bastion-prod se queda colgado, revisa mi config

[Claude Code] Voy a mirar su configuración SSH.
[leyendo ~/.ssh/config]
[leyendo ~/.ssh/id_rsa]
[leyendo ~/.ssh/known_hosts]

La clave privada misma viaja al modelo. Si el modelo "la recuerda" o no es la pregunta equivocada — los bytes están en logs de tránsito, cachés del proveedor y cualquier proxy de logging por en medio.

Por qué gitleaks y truffleHog no le salvan

Su equipo ya ejecuta gitleaks o truffleHog como hook pre-commit o en CI. Es un buen control. Y está completamente al lado equivocado del problema.

Esas herramientas se disparan cuando usted intenta escribir un secreto en el control de versiones. La fuga del agente CLI ocurre cuando usted lee un secreto del disco y lo transmite a un tercero. Para cuando gitleaks corre, los bytes llevan diez minutos en el contexto de un modelo de frontera. El escaneo pre-commit protege su historial de git. No protege el sistema de archivos de su portátil de ser exfiltrado, una llamada a herramienta servicial cada vez.

La solución: escanear la ruta de lectura, no solo la de escritura

El control que realmente necesita vive entre el agente y el sistema de archivos. Cada archivo que el agente abre y cada comando shell que ejecuta debe pasar por un escáner antes de que los bytes lleguen al proveedor del modelo. Zeuslock CLI lo implementa como un wrapper:

zeuslock cli wrap claude-code -- claude-code .

El wrapper intercepta las lecturas de archivo y las invocaciones de shell del agente, ejecuta la pipeline de detección de tres capas de Zeuslock (regex, NER, heurísticas de contexto) sobre los bytes y aplica el modo de política que usted haya configurado por tipo de hallazgo:

• Monitor — deja pasar la lectura pero registra el hallazgo en la Consola del Operador.
• Anonymize — sustituye el secreto por un falso estructuralmente válido (un stub sk_live_ verosímil) para que la lógica del modelo siga funcionando, pero la clave real nunca sale.
• Block — rechaza la lectura por completo y devuelve un error claro al agente.

El despliegue sigue el mismo patrón que recomendamos siempre: Monitor durante dos semanas para que los ingenieros vean qué han estado haciendo sus agentes, Anonymize tres semanas para retirar los secretos vivos sin romper los flujos, y luego Block a partir de la semana seis.

Tres controles adicionales que combinan bien

Allowlists de directorios

La mayoría de agentes CLI leerá felizmente cualquier ruta que el SO les permita. Configure el wrapper para que el agente solo pueda leer dentro de la raíz del repositorio actual. ~/.env, ~/.aws, ~/.ssh y ~/Documents se vuelven estructuralmente inalcanzables. Esto por sí solo cierra los tres primeros vectores de arriba.

Allowlisting de servidores MCP

MCP es donde la cosa se complica. Un servidor MCP de Postgres mal configurado puede transmitir filas de producción al modelo. Un servidor MCP interno a medida puede exponer Vault. Zeuslock CLI mantiene una allowlist por usuario de servidores MCP e intercepta los payloads JSON-RPC en el cable — misma pipeline de detección, mismos tres modos, aplicados a las respuestas tools/call antes de que lleguen al agente.

Modos de política por herramienta

Probablemente quiera reglas distintas para Claude Code en un portátil de desarrollador que para un job de Aider corriendo en CI. La Consola del Operador permite alcanzar las políticas por binario, por host y por entorno. Un runner de CI puede ir en Block por defecto para todo; una sesión interactiva de Claude Code puede anonimizar secretos y monitorizar datos personales.

Lo que los vendors ya hacen — y dónde queda el hueco

Reconocimiento donde corresponde. Claude Code se sandboxea al directorio del proyecto por defecto, pregunta antes de leer fuera de él y avisa sobre nombres de archivo típicos de secretos. El modo agente de Cursor tiene garantías similares. Copilot CLI delimita sus lecturas con cuidado. Ninguna de estas herramientas quiere filtrar sus secretos.

El hueco es el humano en el bucle. Cuando el agente pregunta "¿puedo leer .env para ayudarle a configurar Stripe?", el ingeniero pulsa Permitir porque la petición es razonable en contexto. Cuando el ingeniero pega un stack trace que casualmente incluye una cabecera Authorization, no salta ningún prompt de permiso. Cuando git log -p hace aflorar una credencial de 2022, el agente hizo exactamente lo que se le pidió.

El sandboxing a nivel de herramienta gestiona los casos obvios. Una capa DLP separada es la que gestiona los casos en los que el ingeniero dijo sí — y no debería.

Qué hacer este trimestre

1. Inventaríe qué agentes CLI usan realmente sus ingenieros. Pregunte en #engineering, no en una encuesta. La respuesta incluirá herramientas de las que seguridad nunca ha oído hablar.
2. Ejecute zeuslock cli scan ~/ en la máquina de un voluntario. Cuente los secretos que serían legibles por cualquier agente con acceso al home. La cifra será incómoda.
3. Wrapee una sola herramienta — empiece por la que más usa su ingeniero con más antigüedad. Póngala en Monitor durante dos semanas.
4. Revise los hallazgos en la Consola del Operador. Comparta el top cinco con el equipo de ingeniería. La conversación sobre Block en la semana seis se escribe sola.
5. Extienda a los servidores MCP, luego a los runners de CI.

El principio cabe en una línea: añada un escáner de secretos a la ruta de lectura, no solo a la de escritura. Todos los demás controles de DLP para IA que su equipo compre este año derivan de eso. Cumple con el RGPD y se alinea con las directrices de la AEPD para el uso profesional de modelos generativos.

El paso a paso de configuración para el wrapper CLI está en la documentación: Envolver agentes de IA con Zeuslock CLI.