$ man how-to/team-security-cloud-guardrails

Los agentes de IA con acceso a sistemas de produccion necesitan barreras de proteccion. No restricciones paranoicas que los hagan inutiles, sino limites practicos que prevengan errores catastroficos. La arquitectura tiene tres capas. Primero, que se ejecuta localmente vs que se ejecuta en la nube. Las operaciones sensibles - gestion de API keys, migraciones de base de datos, rotacion de secretos - se quedan en maquinas locales donde tienes control fisico. Las cargas de trabajo de agentes que procesan datos y generan salida se ejecutan en la nube donde escalan. Segundo, protecciones a nivel de repositorio. Las reglas de proteccion de ramas previenen que los agentes hagan push directamente a main. Las revisiones requeridas aseguran que un humano vea cada cambio antes de que llegue a produccion. Los hooks pre-push escanean secretos, API keys, y datos identificables de partners antes de que nada salga de tu maquina. Tercero, barreras de ejecucion en Claude Code mismo. Las reglas del CLAUDE.md definen lo que el agente puede y no puede hacer. El agente respeta estas reglas porque se cargan en el contexto al inicio de la sesion.

PATTERN

Mantener local: archivos .env, rotacion de API keys, credenciales de base de datos, SSH keys, datos de partners, cualquier cosa que seria catastrofica si se filtra. Enviar a la nube: codigo de agentes, definiciones de flujo de trabajo, datos procesados (anonimizados), contenido generado, artefactos de despliegue. La regla: si los datos existen en un solo lugar (tu maquina) y filtrarlos significa llamar a cada cliente, mantenlos locales. Si los datos son generados o derivados y perderlos significa re-ejecutar un script, pueden ir a la nube. Para agentes en Railway o similar: pasa secretos como variables de entorno en el dashboard del hosting. Nunca los hagas commit. Nunca los registres en logs. Nunca los incluyas en mensajes de error. El codigo del agente referencia process.env.API_KEY, no la clave real.

CODE

Configuraciones de proteccion de ramas en GitHub para equipos con agentes de IA: 1. Requerir revisiones de pull request antes de fusionar a main. Incluso si el agente escribio el codigo, un humano lo revisa. 2. Requerir que los status checks pasen. Ejecuta tu suite de tests y escaneo de seguridad antes de cualquier merge. 3. Requerir que las ramas esten actualizadas antes de fusionar. No fusiones de ramas obsoletas que crean conflictos. 4. Restringir quien puede hacer push a main. Los agentes hacen push a ramas de feature. Los humanos fusionan a main. Los hooks pre-push agregan otra capa. El hook pre-push de Husky escanea cada commit buscando patrones que nunca deberian enviarse: API keys (cadenas que coinciden con patrones de claves), nombres de partners (de una lista de bloqueo local), contenidos de archivos .env, y archivos binarios grandes. El push falla si cualquier patron coincide.

PRO TIP

Claude Code mismo aplica seguridad a traves de reglas CLAUDE.md. Esto esta subestimado. Agrega reglas como: "Nunca hagas commit de archivos .env. Nunca registres API keys en logs. Nunca incluyas nombres de partners en mensajes de commit. Siempre verifica .gitignore antes de agregar archivos. Ejecuta el escaneo de lista de bloqueo pre-push antes de cada push." El agente sigue estas reglas porque estan en su contexto. Se convierte en un colaborador consciente de la seguridad. Cuando le dices que haga push de codigo, ejecuta el escaneo primero. Cuando le dices que agregue un archivo, verifica .gitignore primero. Cuando le dices que registre informacion de depuracion, redacta valores sensibles. Esto no es infalible. Es una capa en una estrategia de defensa en profundidad. Combinado con proteccion de ramas, hooks pre-push, y gestion de secretos, cubre los modos de fallo comunes donde los equipos accidentalmente filtran credenciales o envian datos sensibles.