Seguridad en AI Coding: Buenas Prácticas para Claude Code (2026)

verifica los nombres de los comandos y los modos de permiso en la documentación de Claude Code antes de confiar en ellos.

Por qué el AI coding necesita una mentalidad de seguridad distinta

El autocompletado de antes solo sugería texto. Un agente de AI coding como Claude Code es una criatura radicalmente distinta: lee todo tu repositorio, ejecuta comandos de shell reales, edita archivos y llama a herramientas externas (MCP, web fetch, GitHub). Junta esas tres capacidades y tienes una superficie de ataque que el linting y el code review tradicionales nunca se diseñaron para atrapar.

La forma más fácil de imaginarlo —tomada de un análisis de Backslash Security (18 de septiembre de 2025)— es tratar al agente como «un becario muy rápido con acceso root». Este becario escribe código diez veces más rápido que tú, pero también puede hacer un rm -rf en el directorio equivocado, pegar una clave de API en un commit o seguir obedientemente un «comando» escondido dentro de una issue de GitHub que acaba de leer. No es malicioso; simplemente no tiene contexto sobre lo que es peligroso.

La idea clave: el riesgo no es que «la IA escribe código malo». El riesgo vive en los privilegios (lo que el agente puede hacer en tu máquina) y en la confianza en la entrada (en quién cree el agente). Así que la estrategia de seguridad correcta no es «leer con cuidado cada línea sugerida»: es construir guardarraíles sistemáticos: limitar privilegios, aislar el entorno, controlar los datos que entran y salen, y mantener siempre a una persona en la decisión final. El resto de este artículo trata de cómo hacer cada capa, una a una.

Los 6 principales riesgos de seguridad del AI coding

Antes de parchear nada, necesitas saber contra qué te defiendes. Aquí están las seis categorías de riesgo que más te encuentras en la práctica, cada una con un escenario concreto:

Estos seis riesgos se corresponden casi uno a uno con las seis buenas prácticas de abajo. No tienes que hacerlo todo de golpe, pero si te saltas una capa, ten claro exactamente qué riesgo estás aceptando.

Buena práctica 1 - Gestionar secretos y datos sensibles

Principio raíz: un secreto no debería existir en ningún lugar donde el agente pueda leerlo en texto plano. Hay cuatro capas de defensa, de la más barata a la más sólida:

1. Mantén los secretos fuera del repositorio. Deja el .env fuera de Git con el .gitignore y prefiere un gestor de secretos (Vault, Doppler, 1Password CLI, las variables de entorno de tu CI) antes que archivos sueltos. Deberías hacerlo incluso sin IA; la IA solo hace peores las consecuencias.

2. Mantén los archivos sensibles fuera del contexto del agente. El enfoque de la documentación de seguridad de Claude Code es usar permissions.deny con una regla Read() en .claude/settings.json: el agente no tendrá permiso para leer los archivos que coincidan con el patrón:

{
 "permissions": {
 "deny": [
 "Read(./.env)",
 "Read(./.env.*)",
 "Read(./**/secrets/**)",
 "Read(./**/*.pem)",
 "Read(./**/*.key)"
 ]
 }
}

(Algunas guías más antiguas mencionan un archivo .claudeignore. Si tu versión de la CLI todavía lo soporta, genial, pero permissions.deny con Read() es el enfoque que recomienda la documentación oficial.)

3. Escaneo automático de secretos. No confíes en el ojo humano. Integra gitleaks (o git-secrets, TruffleHog) en un hook de pre-commit y en la CI para bloquear cualquier commit que contenga una clave antes de que salga de tu máquina:

# pre-commit: block the commit if a secret is detected
gitleaks protect --staged --redact --verbose

4. Rota cuando algo se filtre. Si una clave ha llegado al contexto o a un commit, trátala como comprometida de forma permanente: borrar el commit no basta, porque la clave puede estar ya en logs/modelo/historial. El procedimiento correcto: revocar la clave antigua -> emitir una nueva -> actualizar el gestor de secretos -> revisar los logs de acceso en busca de anomalías. Prepara un runbook de rotación antes de necesitarlo.

Buena práctica 2 - Controlar permisos y ejecutar en un sandbox

Esta es la capa de mayor ROI. Claude Code tiene varios modos de permiso que deciden qué puede hacer el agente por su cuenta:

Una advertencia sin rodeos: bypassPermissions (y la flag --dangerously-skip-permissions) es exactamente lo que parece: peligroso. La palabra «dangerously» en el nombre es deliberada. Nunca lo actives donde tengas secretos reales, acceso a producción o repositorios de clientes. Si necesitas ejecutar el agente sin supervisión (trabajos por lotes, CI), hazlo dentro de un sandbox, no en tu máquina principal.

En settings.json, aplica el mínimo privilegio: permite lo seguro por defecto, pregunta por cualquier cosa arriesgada y niega de plano lo que nunca debería ejecutarse solo. Una plantilla lista para pegar:

{
 "permissions": {
 "allow": [
 "Read(./src/**)",
 "Bash(npm run test:*)",
 "Bash(git status)",
 "Bash(git diff:*)"
 ],
 "ask": [
 "Bash(git push:*)",
 "Bash(npm install:*)",
 "Write(./src/**)"
 ],
 "deny": [
 "Bash(rm -rf:*)",
 "Bash(curl:*)",
 "Bash(sudo:*)",
 "Read(./.env)",
 "Read(./.env.*)"
 ]
 }
}

Aísla con un contenedor. La forma más potente de limitar el radio de daño es ejecutar el agente dentro de un devcontainer/Docker: monta solo los directorios que necesita, corta el acceso de red innecesario y deja fuera las credenciales de producción. Aunque el agente sufra una prompt injection y ejecute un mal comando, solo puede destrozar la caja, no tu máquina. Para profundizar en la configuración de permisos, mira la guía sobre cómo configurar los permisos de Claude Code de forma segura.

O usa el sandbox nativo (más ligero que Docker). Claude Code tiene un comando /sandbox: aislamiento a nivel de SO, sin imagen que construir ni devcontainer que configurar: Seatbelt integrado en macOS, bubblewrap + socat en Linux/WSL2. Aísla el sistema de archivos y la red de forma parecida a un contenedor, pero arranca más rápido y no necesita instalar Docker: una buena opción cuando quieres aislamiento rápido para una sola tarea (auditar un repositorio desconocido, ejecutar código no confiable) sin levantar un devcontainer completo. Nota: esta es una capa distinta de los modos de permiso: un modo de permiso controla sobre qué se le pregunta al agente antes de actuar, mientras que el sandbox controla lo que el agente puede hacer de verdad aunque ejecute un mal comando. Ambos se complementan, no se sustituyen. Un contenedor sigue siendo la opción más potente para un entorno de desarrollo duradero y de configuración compleja; el sandbox nativo encaja con el aislamiento rápido y temporal. Mira la configuración completa en sandboxing de Claude Code.

Buena práctica 3 - Bloquear la prompt injection y el contenido no confiable

La prompt injection es el riesgo más característico y más infravalorado. El mecanismo: el agente no distingue con claridad entre tus instrucciones y los datos que lee. Si esos datos contienen una frase imperativa, el agente puede tratarla como una tarea que ejecutar.

Fuentes habituales de contenido no confiable:

• Issues / PRs / comentarios en GitHub escritos por gente de fuera.
• Páginas web que el agente busca cuando le pides que «lea la doc en esta URL».
• Salida de un servidor MCP o de una herramienta de terceros.
• Archivos de un repositorio que acabas de clonar pero que aún no has leído.

Cuatro principios de mitigación, sin teoría rebuscada:

1. Nada de auto-aprobar al manejar entrada externa. En el momento en que el agente empieza a leer una issue/página web/salida de MCP, vuelve a preguntar paso a paso; no dejes acceptEdits/bypass en marcha.
2. Usa el modo plan con fuentes desconocidas. Deja que el agente lea y proponga, pero bloquea la ejecución hasta que lo apruebes.
3. Aísla. Maneja los datos no confiables en un sandbox sin secretos, como en la buena práctica 2.
4. Desconfía de los «comandos educados». Si de repente alguna salida «sugiere» que el agente ejecute un comando, instale un paquete o lea un archivo desconocido, para y léelo con atención. Esa es una señal clásica de injection.

La documentación de seguridad de Anthropic tiene una sección dedicada a defenderse de la prompt injection; el principio general es mantener al agente en el modo de menor privilegio posible siempre que toque datos que no controlas.

El modo auto tiene su propia defensa contra injection. Desde 08/2026, el modo auto es el modo inicial por defecto en los planes Pro/Max/Team, lo que ahora hace esto directamente relevante para la mayoría de los lectores, y no un caso aislado. El mecanismo: el clasificador que revisa las acciones en el modo auto lee solo tus mensajes, las llamadas a herramientas y CLAUDE.md: nunca lee los resultados de las herramientas. Una capa aparte, del lado del servidor, escanea los resultados de las herramientas en busca de contenido hostil antes de que Claude pueda leerlos. Esta es una defensa parcial, no una garantía absoluta: no tomes el modo auto como excusa para saltarte los cuatro principios de mitigación de arriba.

Buena práctica 4 - Revisar siempre el código generado por IA

La regla innegociable: nunca hagas merge de código de IA sin una persona en el bucle. La gran velocidad de generación de código hace fácil caer en el «merge a ciegas», y ahí es donde la mayoría de las vulnerabilidades llegan a producción.

El problema sutil es el AI slop: código que parece pulido, tiene nombres de variables bonitos, tiene comentarios y funciona en el happy path, pero se salta la validación de entrada, deja una SQL injection abierta, deja valores hardcodeados o maneja mal un caso límite de seguridad. «Parece correcto», así que se cuela ante un revisor apurado. Para saber cómo detectarlo y evitarlo, mira cómo evitar el AI slop al revisar código.

Activa security-guidance para que Claude revise su propio código mientras lo escribe. Es un plugin nativo que se ejecuta automáticamente, sin nada que tengas que acordarte de invocar: 3 capas se disparan solas: (1) coincidencia de patrones instantánea cada vez que Claude edita un archivo (sin llamada al modelo, gratis, atrapa patrones claros como eval(, os.system, dangerouslySetInnerHTML); (2) una revisión en segundo plano al final del turno, por defecto en Opus 4.7; (3) una revisión agéntica más profunda en el momento del commit/push, que también lee los callers y sanitizers relacionados. Instálalo con /plugin install security-guidance@claude-plugins-official; personaliza tus propias reglas mediante .claude/claude-security-guidance.md y .claude/security-patterns.yaml. No bloquea escrituras ni commits: solo saca a la luz los hallazgos para que Claude los corrija. A diferencia de /security-review (punto 2 más abajo), que es un escaneo puntual bajo demanda, security-guidance es una capa continua que corre en segundo plano durante toda tu sesión. Para un escaneo profundo, gratuito y con múltiples agentes, mira el plugin claude-security en nuestro artículo de auditoría de seguridad.

Un flujo de revisión práctico:

1. Lee el diff, no la descripción. Que el agente diga «añadí validación» no significa que lo hiciera bien. Verifícalo en el diff.
2. Ejecuta /security-review, el comando de revisión de seguridad integrado en Claude Code, para escanear rápido las vulnerabilidades comunes (injection, secretos hardcodeados, falta de auth) antes de revisar a mano.
3. Prioriza las áreas sensibles: autenticación, autorización, manejo de la entrada del usuario, queries a la base de datos, comandos de shell, operaciones de archivos.
4. Ejecuta los tests y tu linter/SAST como en cualquier otro PR: la IA no te exime de la CI.

Para proyectos que necesitan más rigor, monta un flujo completo de auditoría de seguridad para Claude Code que corra según un calendario, no solo de forma puntual.

Buena práctica 5 - Evaluar servidores MCP, plugins y usar hooks como guardarraíles

Cada servidor MCP o plugin que habilitas es código de terceros ejecutándose con los privilegios del agente. Un servidor «cómodo» pero malicioso puede leer archivos, hacer llamadas de red y exfiltrar datos sin que lo veas. Los principios:

• Habilita solo servidores de confianza: prefiere fuentes oficiales con código público que puedas leer.
• Lee el código antes de instalar los servidores menos conocidos, sobre todo los que tienen amplio acceso a red o archivos.
• Mínimo privilegio para MCP igual que para Bash: concede solo el alcance realmente necesario.

Para entender cómo funciona MCP antes de evaluarlo, lee qué es MCP y cómo funciona.

Un hook PreToolUse como guardarraíl de última línea. Esta es una capa infrautilizada pero muy potente: el hook se ejecuta antes de que el agente ejecute una herramienta y puede bloquear de plano. Por ejemplo, bloqueando patrones de comandos peligrosos:

#!/usr/bin/env bash
# .claude/hooks/pre-tool-use-guard.sh
# Read the JSON payload from stdin, block dangerous commands
input=$(cat)
cmd=$(echo "$input" | jq -r '.tool_input.command // ""')

if echo "$cmd" | grep -Eq 'rm -rf|curl .*\| *(ba)?sh|:\(\)\{|dd if='; then
 echo "Blocked: dangerous command rejected by guardrail." >&2
 exit 2 # a non-zero exit code => Claude Code cancels the action
fi
exit 0

Registra este hook para el evento PreToolUse en settings.json. La ventaja frente a depender solo de deny: un hook permite lógica dinámica (regex, comprobación de variables, logging) y es una red de seguridad aunque actives sin querer un modo permisivo.

El checklist de seguridad del AI coding (cópialo y úsalo ya)

Todas las buenas prácticas condensadas en una lista accionable. Imprímela o pégala en el README de tu proyecto:

1. [ ] Secretos: .env en .gitignore, usa un gestor de secretos, sin claves en texto plano en el repositorio.
2. [ ] Denegar lecturas: permissions.deny bloquea Read() para .env, *.pem, *.key y los directorios de secretos.
3. [ ] Escaneo: gitleaks (o equivalente) corre en el pre-commit y en la CI.
4. [ ] Rotación: existe un runbook para revocar + reemitir claves cuando una se filtra.
5. [ ] Permisos: el settings.json sigue el mínimo privilegio (allow/ask/deny), sin bypassPermissions fuera de un sandbox.
6. [ ] Sandbox: las tareas arriesgadas corren en Docker/devcontainer sin credenciales de producción.
7. [ ] Prompt injection: cambia al modo plan/ask al manejar issues, búsquedas web o salida de MCP.
8. [ ] Revisión: lee el diff + ejecuta /security-review + CI/SAST antes del merge, nunca hagas merge a ciegas.
9. [ ] MCP/plugin: habilita solo servidores de confianza cuyo código hayas leído, con el alcance mínimo concedido.
10. [ ] Hooks: un guardarraíl PreToolUse bloquea los comandos destructivos.
11. [ ] Revisión automática: el plugin security-guidance está activado y revisa automáticamente cada vez que Claude edita un archivo.
12. [ ] Sandbox: /sandbox está activado para tareas que necesitan un aislamiento más ligero que Docker.

Los límites reales, y cuándo NO dárselo a la IA

Siendo honesta: cada guardarraíl de arriba reduce el riesgo, no lo elimina. Algunos límites que vale la pena decir con claridad.

La IA no sustituye el modelado de amenazas humano. No entiende tu contexto de negocio, cuán sensibles son tus datos ni las consecuencias legales de una fuga. La decisión «¿es seguro automatizar esto?» sigue siendo tuya.

No dejes que el agente toque producción ni secretos reales. No conectes el agente a una base de datos de producción, no le des credenciales con acceso de escritura a la infraestructura y no lo dejes desplegar a su antojo. Los errores aquí no tienen vuelta atrás.

La fatiga de aprobación es un riesgo real. Cuando las preguntas de permiso aparecen demasiado a menudo, la gente empieza a pulsar «permitir» por reflejo, derrotando justo la defensa que montaron. La solución: ajusta allow para las operaciones que son genuinamente seguras, de modo que las preguntas solo aparezcan para lo que merece considerarse, en vez de desactivarlas todas para que dejen de molestar.

En resumen: usa la IA para ir rápido, pero mantén las decisiones irreversibles en manos humanas. Los guardarraíles existen para que puedas ir rápido con confianza, no para que dejes de pensar.

Estandariza la seguridad con un kit prefabricado

Escribir cada hook PreToolUse, cada plantilla de settings.json y cada skill de revisión desde cero para cada proyecto se vuelve tedioso, sobre todo cuando quieres a todo un equipo en el mismo estándar. Una forma de ahorrar tiempo es un kit prefabricado que empaqueta skills de revisión de seguridad y flujos de guardarraíl para Claude Code. El kit AgentKit para Claude Code reúne un conjunto de skills de revisión/flujo para que no reconstruyas desde cero; si quieres ver si te encaja, puedes consultar los precios de AgentKit (20% de descuento por el enlace) (Engineer Kit $99, el sitio no indica cuota recurrente, con actualizaciones de por vida). Aun así, deberías leerlo y adaptarlo a tu proyecto: ningún kit sustituye entender tu propio modelo de amenazas.

Preguntas frecuentes (FAQ)

¿Es seguro usar AI coding en proyectos reales?

Sí, si montas los guardarraíles correctos: mantén los secretos fuera de alcance, aplica permisos de mínimo privilegio, ejecuta en un sandbox y revisa todo el código antes del merge. El riesgo viene de privilegios demasiado amplios y de entrada no confiable, no de usar IA en sí. Sin guardarraíles el riesgo es alto; con ellos, es controlable.

¿Claude Code envía mi código a algún lado?

Claude Code envía el contexto que necesita a la API de Anthropic para procesarlo: así es como funciona. Para limitar la exposición, usa permissions.deny para bloquear la lectura de archivos sensibles, revisa la política de retención de datos en la documentación de Anthropic y, para código extremadamente sensible, aíslalo en un entorno dedicado.

¿Cómo evito que las claves de API se filtren por el agente?

Tres capas: (1) nada de claves en texto plano en el repositorio, usa un gestor de secretos; (2) permissions.deny para bloquear Read() en .env y en los archivos de clave; (3) gitleaks en el pre-commit y en la CI para bloquear commits que contengan secretos. Si una se filtra, revócala y rótala de inmediato: borrar el commit no basta.

¿Debería activar bypassPermissions?

Casi nunca, en una máquina de trabajo de verdad. bypassPermissions y --dangerously-skip-permissions quitan todas las capas de aprobación: úsalos solo en un sandbox aislado, sin secretos ni acceso a producción. Para el día a día, quédate en default; ajusta allow para reducir las preguntas en vez de desactivarlas todas.

¿Cuánta revisión es suficiente para el código de IA?

Lee el diff en vez de fiarte de la descripción del agente, ejecuta /security-review, corre CI/SAST y tests como en cualquier PR, y examina a fondo las áreas sensibles (auth, entrada, base de datos, shell). Ojo con el AI slop: código que parece correcto pero se salta la validación o falla en un caso límite de seguridad.

¿Está bien usar AI coding en proyectos de cliente (con NDA)?

Solo si el contrato lo permite y aíslas bien: un workspace separado por cliente, nunca abras el agente sobre un directorio que guarde el código de otro cliente, sin credenciales reales en el alcance, y revisa las cláusulas del NDA sobre el envío de datos a servicios de terceros antes de empezar.

¿El modo auto se defiende solo contra la prompt injection?

En parte. El clasificador que revisa las acciones en el modo auto lee solo tus mensajes, las llamadas a herramientas y CLAUDE.md; nunca lee los resultados de las herramientas; una capa aparte, del lado del servidor, escanea los resultados de las herramientas en busca de contenido hostil antes de que Claude los lea. Esta es una defensa parcial, no una garantía absoluta: aún deberías aplicar los cuatro principios de mitigación (nada de auto-aprobar con entrada desconocida, usa el modo plan, aísla, desconfía de los «comandos educados») al manejar contenido no confiable.

Conclusión y próximos pasos

La seguridad en AI coding no es una función que enciendes o apagas: son seis capas de guardarraíles: secretos, permisos, sandbox, bloqueo de prompt injection, revisión de código y evaluación de MCP + hooks. Empieza por las dos capas de mayor ROI —permissions.deny para los secretos y un settings.json de mínimo privilegio— y luego añade el resto con el tiempo. Pega el checklist de arriba en el README de tu proyecto para que todo el equipo siga un único estándar.

Lee a continuación: cómo configurar los permisos de forma segura y una auditoría de seguridad completa. Si quieres un conjunto de skills de seguridad listo para todo el equipo, puedes probar AgentKit (20% de descuento por el enlace), pero siempre léelo y adáptalo a tu propio modelo de amenazas.