Seguridad de agentes IA: Guía práctica para developers

Los agentes de IA para programar tienen acceso al sistema de archivos, ejecución de shell y capacidades de red en tu máquina. Claude Code ejecuta comandos. Cursor edita archivos en todo tu proyecto. Devin escribe, testea y despliega código. Cuando algo sale mal, las consecuencias no son hipotéticas. Son fugas de datos reales, exposición de credenciales reales y compromisos de cadena de suministro reales.

Esta guía cubre ataques documentados, el modelo de amenazas relevante para developers y los pasos concretos que deberías tomar hoy.

Qué hace diferentes a los agentes de IA

Un chatbot recibe texto y devuelve texto. Un agente de IA recibe texto, toma decisiones y ejecuta acciones. Esa distinción cambia todo el modelo de seguridad.

Un chatbot que alucina te da una respuesta incorrecta. Un agente que alucina ejecuta el comando incorrecto. Un chatbot que recibe una inyección de prompt dice algo inesperado. Un agente que recibe una inyección de prompt puede exfiltrar tus credenciales, modificar tu código o instalar una dependencia maliciosa.

El cambio de "texto entra, texto sale" a "texto entra, acciones salen" significa que cada input que el agente procesa es un vector potencial para comportamiento no deseado. Y los inputs están en todas partes: archivos en tu repo, respuestas de APIs, salidas de herramientas MCP, incluso mensajes de commits en git.

Ataques reales contra agentes de IA

Estos no son riesgos teóricos. Cada incidente aquí abajo está documentado.

Inyección de prompts en producción

Bing/Sydney (febrero 2023): Usuarios manipularon Bing Chat para que revelara su system prompt y se comportara contra sus directrices. Fue una de las primeras demostraciones públicas a gran escala de que la inyección de prompts funciona en sistemas de producción, no solo en papers de investigación.

Exploit de memoria de ChatGPT (2024): El investigador de seguridad Johann Rehberger demostró inyección de prompts persistente a través de la función de memoria de ChatGPT. Un documento malicioso podía inyectar instrucciones que persistían entre conversaciones futuras, lo que significa que un solo archivo envenenado podía comprometer cada sesión posterior.

Fugas de datos en GPT Store (2024): Múltiples GPTs personalizados en el GPT Store de OpenAI fueron descubiertos filtrando sus system prompts y archivos de conocimiento subidos mediante inyección de prompts. Developers que construyeron GPTs con datos propietarios vieron esos datos extraídos por usuarios con trucos simples de prompting.

Vulnerabilidades en agentes de programación

GitHub Copilot RCE (CVE-2025-53773): Una vulnerabilidad donde un repositorio malicioso podía crear archivos que, al ser procesados por Copilot, ejecutaban código arbitrario en la máquina del developer. Abrir el repo equivocado era suficiente.

Vulnerabilidades de Cursor IDE (CVE-2025-54135, CVE-2025-55284): Archivos de proyecto maliciosos podían activar acciones no deseadas del agente en Cursor. El vector de ataque era el proyecto en sí, lo que significa que clonar un repositorio podía comprometer tu entorno.

Estos CVEs demuestran que el código que tu agente lee es una superficie de ataque.

Ataques a la cadena de suministro MCP

Invariant Labs documentó varios patrones de ataque contra el Model Context Protocol:

Envenenamiento de herramientas (tool poisoning): Los servidores MCP pueden incluir instrucciones ocultas en las descripciones de herramientas. Estas instrucciones son invisibles para el usuario en la interfaz de aprobación pero son procesadas por el agente de IA. Una herramienta descrita como "buscar archivos" podría contener texto oculto indicando al agente que primero lea y exfiltre tu archivo .env.

Ataques rug-pull entre servidores: Un servidor MCP puede cambiar las descripciones de sus herramientas después de que lo hayas aprobado. El agente relee las descripciones de herramientas en cada invocación. Un servidor que era seguro cuando lo instalaste puede volverse malicioso en una actualización posterior, y no se te pedirá que lo vuelvas a aprobar.

Brecha del MCP de Postmark: El servidor MCP oficial de Postmark contenía instrucciones ocultas en las descripciones de sus herramientas que podían exfiltrar contenido de emails procesados a través del servidor.

Inyección en GitHub MCP: Investigadores demostraron que contenido malicioso embebido en issues y pull requests de GitHub podía inyectar instrucciones al ser procesado a través del servidor MCP de GitHub, convirtiendo una revisión de código rutinaria en un vector de ataque.

24.008 secretos encontrados en archivos .mcp.json públicos: Un escaneo de repositorios públicos de GitHub encontró más de 24.000 API keys hardcodeadas directamente en archivos de configuración MCP. Estos archivos fueron commiteados al control de versiones con credenciales reales.

Los cinco riesgos

1. Exposición de secretos

Los agentes de IA leen archivos para entender tu proyecto. Eso incluye archivos .env, archivos de configuración y cualquier cosa que contenga API keys o credenciales. Una vez que un secreto entra en el contexto de la conversación, es parte del historial de la sesión. Dependiendo del proveedor, puede ser registrado, almacenado o usado para entrenamiento.

Los más de 24.000 secretos encontrados en archivos .mcp.json públicos demuestran que esto no es un problema marginal. Los developers rutinariamente ponen credenciales donde los agentes pueden leerlas y las herramientas pueden commitearlas.

Ejemplo real: Un agente lee tu .env para entender la configuración de tu base de datos. Ese archivo contiene tu clave live de Stripe, tu contraseña de base de datos y tu secreto JWT. Todos esos valores están ahora en el contexto de la conversación y potencialmente en los logs del proveedor.

Mitigaciones:

• Usa un gestor de secretos que inyecte valores en tiempo de ejecución sin exponerlos al agente. Consulta gestionar secretos con Claude Code para la configuración completa.
• Bloquea el acceso a archivos de secretos usando permissions.deny en la configuración de Claude Code (más sobre esto abajo).
• Rota cualquier credencial que haya aparecido en una conversación con un agente.
• Usa pre-commit hooks como gitleaks para capturar secretos antes de que lleguen al control de versiones.

2. Inyección de prompts

Si tu agente procesa cualquier input externo, puede recibir una inyección de prompt. Archivos en un repo clonado, respuestas de APIs, páginas web, salidas de herramientas MCP, incluso datos de una consulta a base de datos. El exploit de memoria de ChatGPT demostró que un solo documento envenenado puede comprometer no solo una sesión sino todas las sesiones futuras.

Para agentes de programación específicamente, la superficie de ataque es el propio código fuente. Un contribuidor malicioso puede embeber instrucciones en comentarios de código, archivos markdown o mensajes de commits que el agente procesará como parte de su contexto.

Mitigaciones:

• Trata cada input externo como no confiable, igual que tratas el input de usuario en una aplicación web.
• Revisa los repositorios antes de dejar que un agente los procese, especialmente los de contribuidores desconocidos.
• Mantén las operaciones destructivas en modo permissions.ask para aprobar cada una.
• Desconfía de sugerencias del agente que parezcan no relacionadas con tu petición, como instalar un paquete inesperado o modificar un archivo no relacionado.

3. Permisos excesivos

La mayoría de developers dan a su agente acceso sin restricciones al directorio del proyecto. Eso significa lectura, escritura y eliminación en cada archivo. Si el agente recibe una inyección de prompt o simplemente comete un error, el radio de impacto es todo.

El OWASP Top 10 para Agentes de IA (2025) lista "Excessive Agency" como una categoría de riesgo primaria. El principio de mínimo privilegio aplica a los agentes de IA igual que aplica a los usuarios humanos y las cuentas de servicio.

Mitigaciones:

• Usa el sistema de permisos de Claude Code para denegar acceso a archivos y directorios sensibles.
• Mantén permissions.ask habilitado para operaciones destructivas (escritura de archivos, ejecución de comandos).
• En CI/CD, usa acceso de solo lectura cuando sea posible.
• Separa las credenciales de desarrollo y producción para que un agente trabajando en código nunca tenga acceso a secretos de producción.

4. Cadena de suministro vía MCP

Cada servidor MCP que conectas es una nueva dependencia en tu perímetro de seguridad. A diferencia de los paquetes npm que puedes auditar y fijar a versiones, los servidores MCP pueden cambiar su comportamiento dinámicamente a través de actualizaciones en las descripciones de herramientas.

El patrón de ataque rug-pull es particularmente peligroso: auditas y apruebas un servidor, y luego cambia sus instrucciones. El agente sigue las nuevas instrucciones sin pedir re-aprobación.

Mitigaciones:

• Solo instala servidores MCP de fuentes confiables y reconocidas.
• Lee el código fuente de cualquier servidor MCP antes de añadirlo a tu configuración.
• Revisa qué herramientas expone un servidor y qué permisos solicita cada herramienta.
• Elimina los servidores MCP que no estés usando activamente.
• Nunca hardcodees API keys en archivos .mcp.json. Usa variables de entorno o un gestor de secretos.
• Monitorea Invariant Labs e investigadores similares para vulnerabilidades MCP recién divulgadas.

5. Fuga de datos por contexto

Todo lo que el agente lee pasa a formar parte de la conversación. Datos de clientes, documentación interna, algoritmos propietarios, credenciales. Dependiendo de la política de datos del proveedor, este contenido podría almacenarse, registrarse o usarse para mejorar el modelo.

El OWASP LLM Top 10 (2025) lista "Sensitive Information Disclosure" (LLM02) como el segundo riesgo más alto. Para agentes de programación con acceso al sistema de archivos, este riesgo se amplifica porque el agente puede leer proactivamente archivos que no le compartiste explícitamente.

Mitigaciones:

• Sé deliberado sobre qué directorios y archivos puede acceder el agente.
• Usa permissions.deny para bloquear el acceso a directorios con datos de clientes, credenciales o información regulada.
• Para datos regulados por HIPAA, GDPR o SOC 2, verifica el acuerdo de procesamiento de datos de tu proveedor de IA antes de que el agente acceda a ese contenido.
• Prefiere servicios de IA autoalojados o con retención cero para proyectos sensibles.

La seguridad integrada de Claude Code

Claude Code incluye un sistema de permisos y un sandbox de ejecución. Entender cómo funcionan es esencial para asegurar tu flujo de trabajo.

Modos de permisos

Claude Code usa tres niveles de permisos, evaluados en orden de prioridad:

La prioridad es deny > ask > allow. Si una herramienta coincide con una regla deny, queda bloqueada sin importar las demás reglas.

Configuración

Los permisos se configuran en .claude/settings.json a nivel de proyecto o en tu configuración de usuario:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(**/credentials*)",
      "Read(**/*.pem)",
      "Bash(rm -rf *)"
    ],
    "allow": [
      "Read(src/**)",
      "Read(docs/**)"
    ]
  }
}

Importante: .claudeignore no es un mecanismo oficial de Claude Code. Usa permissions.deny en .claude/settings.json para controlar el acceso a archivos.

Sandbox

Claude Code ejecuta con una capa de sandbox:

• Linux: Usa bubblewrap para aislamiento de procesos
• macOS: Usa el framework de sandbox seatbelt

El sandbox restringe lo que el proceso del agente puede acceder a nivel de sistema operativo, proporcionando defensa en profundidad más allá del sistema de permisos.

Configurar un flujo de trabajo seguro

Un checklist práctico para developers que trabajan con agentes de IA para programar:

Controles de acceso a archivos

• Configura permissions.deny para bloquear .env, .env.*, *.pem y archivos de credenciales
• Bloquea el acceso a directorios con datos de clientes o información regulada
• Deniega el acceso a archivos de configuración de producción

Gestión de secretos

• Nunca pegues secretos directamente en conversaciones con el agente
• Usa un vault que inyecte secretos en tiempo de ejecución sin exponer valores al agente
• Rota cualquier credencial que haya aparecido en un contexto de conversación
• Almacena tokens de servidores MCP en variables de entorno, nunca en .mcp.json

Límites de permisos

• Mantén permissions.ask habilitado para escritura de archivos y ejecución de comandos
• Usa permissions.deny para operaciones conocidas como peligrosas
• Usa API keys separadas para entornos de desarrollo y producción
• En pipelines CI/CD, otorga acceso de solo lectura cuando sea posible

Higiene de servidores MCP

• Audita el código fuente de servidores MCP antes de instalarlos
• Elimina los servidores MCP que no estés usando activamente
• Monitorea cambios en las descripciones de herramientas en servidores de los que dependes
• Nunca commitees archivos .mcp.json que contengan credenciales reales

Revisión de código

• Revisa los commits generados por IA antes de hacer push a ramas compartidas
• Usa pre-commit hooks (gitleaks, detect-secrets) para capturar credenciales filtradas
• Desconfía de cambios del agente en archivos no relacionados con tu petición
• Verifica las adiciones de dependencias buscando paquetes sospechosos o desconocidos

El límite de confianza

El concepto más importante en seguridad de agentes de IA es el límite de confianza (trust boundary). Tu agente de IA está dentro de tu entorno de desarrollo pero procesa inputs externos y se conecta a servicios externos. Tiene más acceso al sistema que un developer junior pero cero criterio sobre qué es sensible.

Traza una línea clara:

• Dentro del límite: Archivos que el agente debería leer, comandos que debería ejecutar, herramientas que debería usar.
• Fuera del límite: Credenciales, datos de clientes, sistemas de producción, repositorios no confiables.

La mayoría de incidentes de seguridad con agentes de IA no ocurren por exploits sofisticados de zero-day, sino porque el límite nunca se definió. El agente tenía acceso a todo, procesó un input que no debería haber confiado y actuó en consecuencia.

Define el límite explícitamente con permissions.deny. Revísalo cuando tu proyecto cambie. Trátalo como infraestructura, no como algo secundario.

Lectura adicional

• OWASP Top 10 for LLM Applications (2025) para la taxonomía completa de amenazas
• Invariant Labs MCP Security Research para patrones de ataque MCP documentados
• Por qué los archivos .env son peligrosos con agentes IA profundiza en el problema de exposición de secretos
• Guía completa de seguridad LLM cubre el panorama más amplio de amenazas
• Gestionar secretos con Claude Code para la configuración práctica del vault
• Prueba SecureCode gratis. Secretos zero-knowledge para agentes de IA para programar.