Seguridad y compliance en desarrollo con agentes de IA

Los agentes de IA para desarrollo de software ejecutan código, acceden al filesystem, interactúan con APIs y modifican repositorios. Eso significa que un agente comprometido o mal configurado puede causar los mismos daños que un desarrollador con acceso a producción y malas intenciones.

La adopción de agentes de IA en equipos de desarrollo ha crecido de forma exponencial en 2025-2026, pero la mayoría de las organizaciones no han actualizado sus marcos de seguridad para contemplar esta nueva superficie de ataque. Siguen aplicando las mismas políticas de seguridad que usaban cuando los desarrolladores escribían todo el código manualmente.

Este artículo analiza los cinco vectores de riesgo principales al desarrollar con agentes de IA, las obligaciones regulatorias actuales (GDPR, EU AI Act), y las contramedidas técnicas para cada uno. No es un documento de compliance genérico: es una guía técnica para equipos de desarrollo que usan agentes de IA en su flujo de trabajo diario.

Inyección de código: el riesgo numero uno

Cómo funciona la inyección en agentes de IA

La inyección de prompts es el equivalente a la SQL injection para agentes de IA. Según el OWASP Top 10 para aplicaciones LLM de 2025, la inyección de prompts es la vulnerabilidad critica numero uno, presente en mas del 73% de los deployments de IA evaluados durante auditorías de seguridad.

Existen dos tipos principales:

Inyección directa: Un usuario malintencionado manipula directamente el input que recibe el agente. En un contexto de desarrollo, esto puede ocurrir cuando:

• Un agente procesa issues o PRs que contienen instrucciones maliciosas en su descripción
• Un agente lee archivos de configuración que han sido modificados para incluir instrucciones ocultas
• Un agente ejecuta tareas basándose en inputs de usuarios externos no validados

Inyección indirecta: El contenido malicioso esta incrustado en fuentes de datos que el agente consume como contexto. Esta variante es mas peligrosa porque el agente no distingue entre datos legítimos e instrucciones inyectadas. Ejemplos en desarrollo:

• Repositorios maliciosos que contienen prompt injections en comentarios de código o archivos README
• Pull requests con instrucciones ocultas en el diff
• Historiales de git con commits que contienen payloads de inyección
• Archivos de configuración (incluyendo configuraciones de MCP) modificados para redirigir el comportamiento del agente

Un estudio publicado en ScienceDirect sobre amenazas en workflows de agentes LLM documenta cómo los ataques han evolucionado desde simples intentos de jailbreak a campañas sofisticadas multi-paso, donde los atacantes diseñan secuencias de prompts que gradualmente modifican la comprensión del agente sobre sus objetivos y restricciones.

Contramedidas técnicas

Validación de inputs:

• Sanitiza todos los inputs que llegan al agente desde fuentes externas
• Implementa filtros que detecten patrones de inyección conocidos
• Separa estrictamente el contenido de usuario del contexto del sistema
• Nunca permitas que inputs de usuario modifiquen el system prompt

Principio de mínimo privilegio:

• El agente solo debe tener acceso a los archivos y sistemas que necesita para la tarea actual
• Revoca permisos cuando la tarea termina
• Usa tokens de acceso con scope limitado y tiempo de expiración
• Nunca le des al agente acceso a credenciales de producción

Sandboxing obligatorio:

• Ejecuta el agente en un entorno aislado (container, VM, sandbox)
• Bloquea la red de salida (egress) para prevenir exfiltración de datos
• Bloquea escrituras fuera del workspace de trabajo
• Bloquea escrituras a archivos de configuración que podrían modificar hooks o configuraciones de MCP

Fuga de datos: cuando el agente sabe demasiado

Vectores de fuga de datos

Los agentes de IA procesan grandes volúmenes de código y datos como parte de su funcionamiento normal. Esto crea múltiples vectores de fuga de datos:

Fuga a proveedores de IA:

• El código que envías al agente puede ser procesado por servidores del proveedor de IA
• Dependiendo de los términos de servicio, ese código puede usarse para entrenamiento del modelo
• Información sensible (claves de API, credenciales, datos de clientes) puede incluirse inadvertidamente en el contexto

Fuga entre sesiones:

• Algunos agentes mantienen estado entre sesiones (memoria, contexto persistente)
• Un agente que trabaja en el módulo de pagos hoy puede retener información sobre la lógica de pagos mañana cuando trabaje en otro módulo
• En equipos donde múltiples personas usan el mismo agente, la información de un proyecto puede filtrarse a otro

Fuga a través de outputs:

• El código generado por el agente puede incluir patrones que revelan información sobre tu arquitectura interna
• Los mensajes de error generados pueden exponer detalles de implementación
• Los logs del agente pueden contener datos sensibles que se almacenan en sistemas de terceros

Contramedidas técnicas

Clasificación de datos:

• Define qué tipo de información puede y no puede enviarse al agente
• Implementa filtros automáticos que detecten y eliminen credenciales, PII y datos sensibles antes de enviarlos
• Usa herramientas de detección de secretos (como git-secrets o trufflehog) en el pipeline

Control de retención:

• Configura el agente para no retener datos entre sesiones cuando sea posible
• Usa modos de privacidad cuando estén disponibles (Cursor y Claude Code ofrecen esta opción)
• Revisa y elimina regularmente historiales de conversación con el agente

Acuerdos con proveedores:

• Verifica que tu proveedor de IA no usa tus datos para entrenamiento (la mayoría ofrece esta garantía en planes enterprise)
• Exige Data Processing Agreements (DPA) conformes con GDPR
• Evalúa opciones de self-hosted para datos altamente sensibles

GDPR y agentes de IA: obligaciones concretas

Qué dice el GDPR sobre el procesamiento de datos por IA

El GDPR no menciona agentes de IA específicamente, pero sus principios aplican directamente:

Artículo 6: Base legal para el procesamiento. Necesitas una base legal para enviar datos personales a un agente de IA. Si tu agente procesa código que contiene datos de clientes (incluso en tests o fixtures), necesitas justificación.

Artículo 25: Protección de datos por diseño y por defecto. Tu sistema de agentes debe implementar protección de datos desde su diseño, no como una capa posterior. Esto incluye minimización de datos (enviar al agente solo lo necesario) y pseudonimización cuando sea posible.

Artículo 35: Evaluación de Impacto en la Protección de Datos (DPIA). Si usas agentes de IA para procesar datos personales a gran escala o de forma sistemática, es probable que necesites una DPIA.

Implementación práctica del GDPR

1. Audita qué datos procesa tu agente: Revisa qué archivos, bases de datos y APIs accede el agente. Identifica si alguno contiene datos personales.

2. Minimiza el contexto: No envíes al agente mas datos de los necesarios. Si necesita trabajar en un módulo de usuarios, no le des acceso al módulo de pagos.

3. Pseudonimiza datos de test: Si tus fixtures de test contienen datos reales de clientes, reemplázalos por datos sintéticos antes de que el agente los procese.

4. Documenta el flujo de datos: Registra qué datos se envían al agente, a qué proveedor, con qué base legal y durante cuánto tiempo se retienen.

5. Garantiza derechos de los interesados: Si un cliente ejerce su derecho al olvido, asegúrate de que sus datos también se eliminan del contexto o historial de los agentes.

EU AI Act: lo que aplica a tu equipo

Clasificación de riesgo

El EU AI Act clasifica los sistemas de IA en cuatro niveles de riesgo. La mayoría de los agentes de desarrollo caen en la categoría de riesgo limitado o mínimo, pero hay excepciones importantes:

Riesgo alto (Anexo III): Si tu agente de IA toma decisiones o asiste en decisiones sobre empleo (por ejemplo, evalúa el rendimiento de desarrolladores basándose en métricas de código), podría clasificarse como sistema de alto riesgo. Las obligaciones del Anexo III para sistemas de alto riesgo entran en vigor el 2 de agosto de 2026.

Riesgo limitado: La mayoría de los agentes de desarrollo de código caen aquí. Las obligaciones principales son transparencia (los usuarios deben saber que interactúan con IA) y documentación técnica.

Plazos clave

• Febrero 2025: Prohibiciones de IA ya en vigor (no aplican a desarrollo de software típico)
• Agosto 2025: Obligaciones de transparencia para IA de propósito general
• Agosto 2026: Obligaciones completas para sistemas de alto riesgo del Anexo III
• Posible extensión a diciembre 2027: La Comisión Europea propuso el paquete “Digital Omnibus” que podría posponer las obligaciones del Anexo III, pero las organizaciones prudentes tratan agosto 2026 como fecha vinculante

Sanciones

Las multas alcanzan los 35 millones de euros o el 7% de la facturación global para violaciones graves. No es un riesgo teórico: la UE ha demostrado voluntad de enforcement con GDPR y aplicará el mismo enfoque con el AI Act.

Acciones concretas para tu equipo

1. Clasifica tus agentes: Determina si alguno de tus usos de IA cae en la categoría de alto riesgo
2. Documenta: Registra qué modelos usas, para qué propósito, qué datos procesan y qué controles tienes
3. Implementa transparencia: Los usuarios (internos y externos) deben saber cuándo interactúan con output generado por IA
4. Mantén registros de auditoría: Logs inmutables de las decisiones y acciones de los agentes

Ejecución en sandbox: arquitectura de contención

Por qué el sandboxing es obligatorio

Según un análisis técnico de NVIDIA sobre sandboxing de workflows agénticos, los controles obligatorios para mitigar ataques serios de inyección indirecta incluyen:

• Controles de egreso de red: Previenen la exfiltración de datos
• Bloqueo de escrituras fuera del workspace: Previenen mecanismos de persistencia y ejecución remota de código
• Bloqueo de escrituras a archivos de configuración: Previenen la explotación de hooks y configuraciones de MCP

La conclusión practica es clara: un agente de IA con capacidad de ejecutar código debe ejecutarse en un sandbox. Sin negociación.

Arquitectura de sandbox recomendada

Nivel 1: Container aislado

• Docker container con solo las herramientas necesarias
• Sin acceso a la red del host
• Filesystem de solo lectura excepto el directorio de trabajo
• Límites de CPU, memoria y tiempo de ejecución

Nivel 2: Network policies

• Whitelist de endpoints permitidos (registry de paquetes, APIs necesarias)
• Bloqueo de todo el tráfico saliente no autorizado
• Logging de todas las conexiones de red intentadas

Nivel 3: Monitorización de actividad

• Logging de todos los comandos ejecutados
• Alertas en tiempo real para actividad sospechosa
• Audit trail inmutable de todas las acciones del agente

Implementación con herramientas existentes

La mayoría de los agentes de desarrollo modernos ofrecen modos de seguridad:

• Claude Code: Ofrece modo de privacidad y control sobre qué comandos puede ejecutar el agente
• Cursor: Permite configurar privacy mode a nivel de organización
• Devin: Ejecuta en entornos cloud aislados por defecto

Para agentes que no ofrecen sandboxing nativo, usa Docker con configuración restrictiva, o soluciones como gVisor o Firecracker para aislamiento mas fuerte.

Audit trails: trazabilidad completa

Por qué la trazabilidad es crítica

Cuando un agente de IA genera código que introduce un bug de seguridad, necesitas responder varias preguntas:

• ¿Qué instrucción generó ese código?
• ¿Qué contexto tenía el agente cuando lo generó?
• ¿Quién aprobó el output del agente?
• ¿Se revisó el código antes de llegar a producción?

Sin un audit trail completo, estas preguntas no tienen respuesta. Y en un contexto regulatorio (GDPR, AI Act), no tener respuestas es un problema de compliance.

Qué registrar

Inputs al agente:

• Prompt completo enviado al agente (incluyendo system prompt y contexto)
• Identidad del usuario que inició la sesión
• Timestamp de cada interacción

Outputs del agente:

• Código generado completo
• Comandos ejecutados y sus resultados
• Decisiones tomadas (y el razonamiento, si esta disponible)

Revisión humana:

• Quién revisó el output del agente
• Qué cambios se hicieron al output antes de integrarlo
• Aprobación explícita o rechazo

Contexto operativo:

• Modelo y versión utilizada
• Configuración del sandbox
• Permisos activos durante la sesión

Implementación práctica

Una práctica emergente es capturar el proceso de pensamiento interno del agente (chain-of-thought) y el log de tool calls. Las organizaciones deben implementar audit trails inmutables para la memoria del agente: cada vez que un agente almacena información en contexto de largo plazo, se registra criptográficamente para que si se encuentra información maliciosa posteriormente, se pueda trazar exactamente cuándo y cómo se introdujo.

Herramientas:

• Git log como audit trail nativo (cada commit del agente es rastreable)
• Logging estructurado con herramientas como structlog o Elastic Stack
• Almacenamiento de logs en sistemas inmutables (append-only)
• Dashboards de auditoría con alertas automáticas

Checklist de seguridad para equipos

Antes de adoptar agentes de IA

• Clasificar los datos que procesará el agente (públicos, internos, confidenciales, PII)
• Definir política de sandbox y aislamiento
• Verificar DPA con el proveedor de IA
• Documentar base legal para el procesamiento de datos (GDPR)
• Clasificar el uso de IA según EU AI Act

Durante el uso diario

• Ejecutar agentes en sandbox con egreso de red controlado
• Revisar todo el código generado antes de integrarlo (code review obligatorio)
• No enviar credenciales, PII o datos de producción al agente
• Mantener logs de todas las interacciones con agentes
• Usar detection de secretos en el pipeline (pre-commit hooks)

Revisión periódica (trimestral)

• Auditar logs de agentes buscando actividad anómala
• Revisar y actualizar políticas de acceso del agente
• Verificar que los controles de sandbox siguen activos
• Actualizar documentación de compliance con cambios regulatorios
• Evaluar nuevas herramientas de seguridad específicas para agentes de IA

Conclusión

La seguridad en el desarrollo con agentes de IA no es un añadido opcional. Es un requisito fundamental que debe diseñarse desde el primer día. Los vectores de ataque son reales, las regulaciones son vinculantes y las consecuencias de ignorar ambos son costosas.

La buena noticia es que las contramedidas son conocidas y aplicables. Sandboxing, principio de mínimo privilegio, audit trails, validación de inputs y clasificación de datos son prácticas de seguridad establecidas que solo necesitan adaptarse al nuevo contexto de agentes de IA.

El error mas común no es fallar en la implementación técnica. Es no empezar. Los equipos que integran seguridad y compliance desde el inicio de su adopción de agentes de IA evitan problemas que son ordenes de magnitud mas caros de resolver después.

¿Quieres asegurar que tu adopción de agentes de IA cumple con los estándares de seguridad y compliance?

En NERVICO ayudamos a equipos técnicos a implementar agentes de IA de forma segura:

• Auditoría de seguridad: Evaluamos tu configuración actual de agentes e identificamos vulnerabilidades
• Arquitectura de sandbox: Diseñamos entornos de ejecución aislados para tus agentes
• Compliance GDPR y AI Act: Te ayudamos a documentar y cumplir las obligaciones regulatorias
• Formación en seguridad: Capacitamos a tu equipo en prácticas de seguridad específicas para desarrollo con IA

Sin alarmismo. Sin soluciones de seguridad genéricas. Solo ingeniería de seguridad pragmática adaptada a tu contexto.

Solicitar auditoría técnica gratuita — Evaluaremos la seguridad de tu setup de agentes de IA y te daremos un plan de acción concreto.

Fuentes

1. NVIDIA: Practical Security Guidance for Sandboxing Agentic Workflows
2. Lakera: Indirect Prompt Injection - The Hidden Threat
3. SecurePrivacy: EU AI Act 2026 Compliance Guide
4. ScienceDirect: From Prompt Injections to Protocol Exploits in LLM-Powered Agent Workflows
5. Wiz: AI Compliance in 2026 - Definition, Standards, and Frameworks