Cómo aislar Claude Code antes de leakear tus llaves

Le diste acceso a Claude Code a tu repositorio local, abriste la terminal y le pediste: "arreglá el bug del login que no me deja entrar con el nuevo token". Te fuiste a hacer un café, confiado en que la herramienta iba a iterar hasta resolverlo. Tres horas después volvés a la pantalla: el bug quizás está arreglado, pero tu factura de Anthropic dice USD 78 y tu archivo .env con las llaves de producción de Stripe ahora vive en un commit público en GitHub.

Esta no es una hipótesis de riesgo ni una historia de terror teórica. Es el patrón exacto que vi en al menos doce aplicaciones de founders que me contactaron en los últimos meses. Estaban desesperados porque sus credenciales financieras quedaron expuestas al mundo por darle rienda suelta a un agente autónomo sin ponerle un cerco perimetral.

El problema del agente con permisos absolutos

Los modelos de lenguaje no tienen instinto de preservación ni modelo de amenazas internalizado. Su única métrica de éxito es resolver el prompt que le tiraste. Si para arreglar un problema de conexión necesitan hardcodear una llave secreta en el frontend para que el compilador deje de quejarse, lo van a hacer.

La escala del problema es enorme. El reporte de Vibe Eval de 2026 lo puso en números concretos: el 11% de 20.052 lanzamientos indie expusieron credenciales críticas (mayormente de Supabase o pasarelas de pago) directamente en el frontend.

Cuando corrés un agente en tu terminal local con permisos amplios, le estás dando acceso de lectura y escritura a todo tu sistema de archivos. Tuvimos incidentes virales reales que demostraron lo destructivo que puede ser esto: Replit terminó borrando las bases de datos de 1206 ejecutivos en pleno code freeze por un agente mal configurado que decidió limpiar el entorno. Lovable hace poco tuvo su CVE-2025-48757 por vulnerabilidades derivadas de un manejo similar.

En proyectos B2B serios de hace años manejábamos la inyección de secretos asumiendo siempre que el entorno era hostil. Sin embargo, la velocidad de desarrollo actual está haciendo que founders inteligentes tiren esa disciplina a la basura por la promesa de despachar features más rápido.

La mentira de la configuración por defecto

Acá es donde el marketing de las herramientas de generación choca de frente con la ingeniería real. Lovable no configura límites de seguridad por default. Cursor tampoco. Y Claude Code tampoco lo hace si vos no te sentás a configurarlo.

Las plataformas están optimizadas algorítmicamente para que experimentes el "aha moment" lo antes posible. Quieren que veas código funcionando en cinco minutos. No están diseñadas para proteger la infraestructura, la privacidad ni la billetera de un negocio real. Asumen que el desarrollador va a poner los límites lógicos después, pero el desarrollador suele creer que la IA "ya sabe lo que hace".

Llevo casi 40 años de oficio peleando con sistemas. Cuando arrancábamos, un error de permisos te colgaba la máquina. Hoy, la calle no perdona: un error de permisos significa que tu SaaS se convierte en un proxy gratuito para que atacantes minen criptomonedas o consuman la API de OpenAI a tu cuenta.

Para poder aprovechar la velocidad táctica de Claude Code sin el riesgo existencial (lo que Stephan Schmidt definió muy bien al hablar de la adaptación del YOLO mode), tenés que aislar el entorno.

Las 5 prácticas obligatorias

Si vas a dejar que un agente autónomo interactúe con tu código y tome decisiones, estas son las cinco barreras de contención que tenés que levantar antes de escribir el primer prompt.

1. Aislamiento con DevContainer

Claude Code jamás debe correr libre en tu sistema operativo host. Tiene que ejecutarse dentro de un contenedor Docker configurado como DevContainer. Esto le otorga un sistema de archivos (FS) completamente efímero y aislado. Si la IA alucina y decide ejecutar un rm -rf o instalar una dependencia maliciosa, solo destruye el contenedor. Además, te permite restringir la red a nivel de firewall de Docker: la única salida a internet que debe tener ese contenedor es a la API del Anthropic SDK. Nada de conexiones salientes a tu base de datos de producción.

2. Secretos NUNCA en el .env del repo

Si tu archivo .env vive físicamente en la misma carpeta que el código, el agente lo va a leer. Y si lo lee, en algún refactor profundo, lo puede commitear. Secretos de producción, como la clave privada de Stripe, nunca deben estar en el scope de lectura del agente. La práctica correcta es que esos secretos vivan en el host y sean inyectados dinámicamente como variables de entorno al momento de levantar el contenedor. El agente corre la aplicación, los toma de la memoria, pero no tiene un archivo físico que pueda filtrar a GitHub.

3. Branch dedicado y validación con dry-run

Un agente jamás trabaja sobre la rama main. Se le asigna un branch descartable específico. Pero el paso crítico es la validación previa. Antes de darle la orden de ejecución real, tenés que correr claude --dry-run. Este comando te devuelve un plan de ejecución exacto: qué archivos planea modificar, qué líneas va a borrar y qué comandos de terminal quiere correr. Revisás el plan. Si tiene sentido, lo dejás correr. Si ves que quiere tocar la configuración del servidor web para arreglar un botón CSS, lo frenás antes de que queme tokens inútilmente.

4. El CLI de GitHub (gh) sin write access

Es muy útil integrar a Claude con el CLI de GitHub (gh) para que pueda leer los issues que reportan tus usuarios y tener contexto del bug. El problema es dejarle los permisos por defecto. Tenés que degradar explícitamente el token del CLI a permisos de solo lectura. Claude Code puede leer los tickets, entender el contexto y escribir el código en tu contenedor local. Pero no puede, bajo ninguna circunstancia, pushear código a tu repositorio remoto ni auto-aprobarse un Pull Request. Ese paso final requiere criterio humano.

5. Un CONTRIBUTING.md específico para agentes

Los agentes leen el contexto general de tu proyecto antes de actuar. Así como escribís documentación para que un dev junior entienda las reglas de tu arquitectura, tenés que escribirle a la IA. Creá un archivo CONTRIBUTING.md con instrucciones absolutas. Ejemplos directos: "No modifiques la carpeta de migraciones de la base de datos", "Nunca toques los handlers de autenticación sin preguntar primero", o "Antes de proponer un cambio en el código, debés ejecutar el comando npm run test:unit y verificar que pase". Esto actúa como un system prompt a nivel del repositorio y acota drásticamente el rango de alucinación.

El criterio por encima de la velocidad

La IA te resuelve el problema de la hoja en blanco y te quita de encima la fricción inútil de acordarte cómo era la sintaxis exacta de un método. Eso es innegable. Pero no te exime de entender cómo se comporta una aplicación cuando toca el mundo real.

Configurar este aislamiento lleva tiempo y rompe un poco la magia del "abro la terminal y le pido que haga todo". Pero la ingeniería no se trata de quién escribe código más rápido, sino de quién diseña un sistema que pueda sostenerse en producción sin fundir a la empresa por un descuido. El código lo puede escribir Claude; la responsabilidad técnica de cómo, dónde y con qué límites corre, es siempre tuya.

Si querés un repo plantilla de DevContainer + Claude Code configurado con todo esto listo para usar, pasame un comentario en LinkedIn o un mail. Gratis.