La seguridad vive fuera del prompt

El problema

Un equipo de desarrollo incluye en el CLAUDE.md de su proyecto la siguiente instrucción: "nunca imprimas el contenido de archivos .env ni incluyas claves de API en tus respuestas". Parece una protección razonable. Sin embargo, es una defensa que reside completamente en el texto del prompt — y una instrucción en el prompt no es un límite de control de acceso. Si el modelo lee el archivo .env durante una tarea legítima (como depurar por qué no se carga una variable de entorno), el secreto ya ingresó en el flujo de tokens de la ventana de contexto. A partir de ese instante, evitar su filtración depende exclusivamente de la adhesión probabilística del modelo — sin que exista ninguna garantía real de seguridad.

Esta lección aborda una distinción que separa a los sistemas realmente seguros de aquellos que solo aparentan serlo: la seguridad real ocurre fuera del prompt, mediante controles de acceso, alcances delimitados y políticas de permisos deterministas que no dependen del "buen comportamiento" del modelo.

Los secretos no se protegen mediante instrucciones

La regla práctica es fácil de enunciar y se viola habitualmente bajo presión de plazos: un secreto (clave de API, token, contraseña, cadena de conexión a base de datos) jamás debe ser accesible para un proceso que pueda emitirlo en una respuesta, a menos que exista una razón operativa específica. Las defensas efectivas son estructurales:

• Los secretos deben residir en variables de entorno o en un gestor de secretos dedicado, nunca embebidos en el código fuente o en configuraciones versionadas.
• Las herramientas de inspección de archivos deben estar restringidas para no acceder a rutas con secretos (.env, claves privadas SSH) cuando la tarea no lo justifique.
• Cuando el propio agente necesita utilizar un secreto (para autenticar una llamada a una API, por ejemplo), el secreto se inyecta en la llamada fuera del flujo de razonamiento del modelo — el modelo decide que la llamada debe realizarse, el arnés de ejecución resuelve e inyecta la credencial, y el modelo nunca observa el valor en su contexto textual.

Una instrucción en CLAUDE.md solicitando no divulgar secretos puede reducir fugas accidentales en situaciones cotidianas, pero nunca debe considerarse un control de seguridad arquitectónico.

Menor privilegio aplicado a herramientas, MCP y Claude Code

El principio de menor privilegio — otorgar a cada componente estrictamente el acceso mínimo indispensable para su labor — se aplica en tres niveles fundamentales:

• Herramientas de Claude Code: un comando o Skill que solo necesita leer archivos no debe tener Bash habilitado. Un formateador de texto no debe tener permisos de Write fuera de su directorio de trabajo.
• Servidores MCP: un servidor MCP que provee acceso de lectura a una base de datos no debe exponer herramientas de escritura, salvo que la mutación de datos sea un requisito explícito y auditado.
• Permisos de Claude Code: la configuración en settings.json puede denegar explícitamente comandos de alto riesgo (como rm -rf o git push --force) con independencia de lo que indique cualquier prompt — aplicando en configuración lo que no puede depender de la probabilidad.

El antipatrón más común es conceder permisos amplios "para no bloquear el trabajo futuro" — otorgar más privilegios de los necesarios ante la posibilidad de requerirlos más adelante. Esto amplía innecesariamente el radio de impacto de cualquier fallo de juicio del modelo sin aportar valor presente.

El perfil de riesgo de las herramientas integradas no es equivalente

Las herramientas integradas de Claude Code tienen límites de riesgo sustancialmente diferentes. Elegir entre ellas no consiste en buscar una que "funcione" — varias pueden resolver una misma tarea —, sino en seleccionar la que presente el menor radio de impacto posible:

• Read: siempre segura para inspección no destructiva antes de alterar archivos.
• Edit: requiere coincidencias exactas de fragmentos; la reescritura completa (Write) solo debe usarse cuando una sustitución total resulte demostrablemente más segura que una edición puntual.
• Grep: busca contenido dentro de archivos con bajo riesgo operativo.
• Glob: localiza rutas en el sistema de archivos por patrones, sin leer contenidos a la ventana de contexto.
• Bash: cruza un límite de ejecución con gran potencia en el sistema operativo, requiriendo validaciones estrictas, permisos explícitos y entornos aislados (sandbox).

Utilizar Bash para una búsqueda que Grep o Read resuelven nativamente expande de forma innecesaria la superficie de ataque del sistema.

Ponlo en práctica

En el laboratorio de esta lección implementarás un auditor de configuraciones de permisos: a partir de una lista de herramientas permitidas para un comando o subagente, identificará violaciones de menor privilegio (como habilitar Bash para tareas declaradas de solo lectura) y simulará la inyección de secretos fuera de banda, asegurando que las credenciales nunca se expongan en el flujo de contexto del modelo.