Los agentes de codificación con IA ya se están ejecutando en entornos de producción. No en sandboxes aislados, sino en los mismos pipelines que manejan datos de clientes, credenciales internas y bases de datos de pre-producción que nadie limpió adecuadamente.



Claude Code es actualmente el más capaz de estos agentes. Esto no es una crítica, pero la capacidad es un arma de doble filo: cuanto más contexto puede consumir un agente, más superficie de ataque estás exponiendo sin darte cuenta.



Este artículo analiza esa superficie: los riesgos en seguridad de datos, los vectores de ataque y qué es lo que realmente cambia tu perfil de riesgo.




Qué hace realmente Claude Code dentro de un pipeline



Antes de analizar los riesgos, conviene ser precisos sobre lo que hace el agente, ya que la mayoría de las conversaciones de seguridad sobre IA lo tratan como una caja negra.



Claude Code opera como un bucle agéntico. Recibe una tarea, la divide en pasos, ejecuta esos pasos mediante herramientas (comandos bash, lectura de archivos, peticiones web, llamadas a servidores MCP), observa el resultado y decide qué hacer a continuación. Continúa así hasta que completa la tarea o choca con un límite de permisos.



En un flujo de trabajo típico, esto significa que el agente lee código en todo el repositorio, ejecuta suites de pruebas, inspecciona esquemas de bases de datos, consulta APIs, lee salidas de logs y modifica archivos. En configuraciones más avanzadas, lo hace incluso mientras el desarrollador está lejos de la terminal.



La clave es entender que Claude Code no es un chatbot con acceso a un archivo. Es lo más parecido a un ingeniero junior con acceso sudo que trabaja más rápido que cualquier humano y no siempre sabe qué información es sensible.



Ese modelo mental cambia por completo la percepción del riesgo.




Vector 1: Bases de datos de no-producción con datos reales



Este es el problema más antiguo del sector, y los agentes de IA lo agravan significativamente.



Los entornos de desarrollo y staging suelen contener copias de datos de producción. Nombres reales, correos electrónicos, historiales de transacciones... datos que están ahí porque el script de exportación era más fácil que configurar un conjunto de datos sintéticos.



Cuando Claude Code consulta esa base de datos para entender esquemas o generar casos de prueba, procesa esos datos y los introduce en su ventana de contexto. Esto puede derivar en que los mencione en el código generado o los escriba en archivos de configuración que terminan en el repositorio.



Esto no requiere una brecha de seguridad tradicional; los datos simplemente viajan por una ruta no gobernada. Bajo el GDPR, "estábamos depurando" no es una base legal válida si tus agentes de IA acceden libremente a datos personales reales.




Vector 2: Logs y trazas de error en la ventana de contexto



Claude Code lee registros de errores para depurar, una de sus funciones más útiles pero también una de las rutas de exposición más ignoradas.



Los logs suelen estar mal gobernados y frecuentemente contienen datos que nunca debieron estar allí: IDs de usuario, tokens de sesión o claves API impresas por error. Al ingerirlos, estos datos entran en el prompt. Si la sesión es remota o se persiste para observabilidad, la retención de esos datos sensibles se vuelve un problema legal que la mayoría de los equipos aún no está cuestionando.




Vector 3: Inyección de prompts a través del código fuente



A diferencia de los anteriores, este es un ataque deliberado. Si un atacante logra introducir texto malicioso en cualquier archivo que el agente lea, puede manipular su comportamiento.



Por ejemplo, un comentario malicioso en una dependencia podría instruir al agente para que exfiltre variables de entorno. Aunque Anthropic ha invertido en resistencia contra la inyección de prompts, la superficie de ataque crece con cada archivo que el agente lee en un monorepositorio. La defensa práctica es aplicar el principio de mínimo privilegio a los permisos del agente.




Vector 4: Servidores MCP e integraciones de terceros



Claude Code soporta el Model Context Protocol (MCP), permitiéndole conectarse a herramientas externas como bases de datos o Slack.


Cada conexión MCP es una vía potencial de datos. Si un desarrollador instala un servidor MCP sin escrutinio, el agente puede convertirse en un conducto involuntario para la exfiltración de datos. Bajo normativas como NIS2, las herramientas que usan los desarrolladores forman parte de la cadena de suministro de la que la organización es responsable.




Vector 5: Persistencia de contexto y datos de sesión



Las funciones de ejecución remota permiten que el contexto viva fuera de la máquina local. Esto genera un vacío en el marco de gobernanza de datos: si una sesión de agente toca datos confidenciales, ¿dónde se guardan y por cuánto tiempo? La falta de trazabilidad en estas sesiones puede ser un problema crítico durante una respuesta ante incidentes.




Vector 6: El código generado como portador de datos



Este riesgo es indirecto: cuando el agente genera datos de prueba, a menudo basa el resultado en patrones que observó en los datos reales. Si un archivo de prueba generado contiene un email que coincide con un usuario real y este se sube a un repositorio público, la exposición es real. Evitar esto requiere asegurar que el agente solo trabaje con datos ya transformados o sintéticos.




Lo que dicen los marcos regulatorios



Normativas como GDPR, NIS2 y DORA tienen implicaciones directas en el uso de agentes de IA:


  • GDPR (Art. 25): Exige protección de datos desde el diseño. La configuración por defecto de las herramientas de IA debe minimizar la exposición, no depender de la memoria del desarrollador.

  • NIS2 (Art. 21): Obliga a gestionar los riesgos de la cadena de suministro, lo que incluye a los agentes de IA y sus integraciones MCP.

  • DORA: Las entidades financieras deben incluir el uso de estas herramientas en su registro de riesgos de TIC.




Cómo cambiar realmente tu perfil de riesgo



La solución no es solo política, es arquitectónica. La intervención principal es garantizar que los agentes de IA trabajen sobre conjuntos de datos que ya han sido transformados.



Acciones clave para que esto funcione:


  • Detección automática de datos sensibles antes de que el agente acceda a ellos.

  • Cumplimiento a nivel de entorno: Asegurar que los datos no anonimizados simplemente no estén disponibles en el entorno de desarrollo.

  • Gobernanza de sesiones: Definir políticas de retención y plataformas permitidas para las sesiones de IA que toquen datos sensibles.




La pregunta de gobernanza que nadie hace todavía



La mayoría de las organizaciones se preguntan qué puede hacer el agente (permisos de ejecución). Pero la pregunta prioritaria es: ¿qué puede ver el agente?



Hoy en día, la respuesta suele ser "más de lo que nadie ha decidido explícitamente". Las herramientas han avanzado más rápido que los marcos de gobernanza. Tratar esto como un problema de arquitectura ahora, en lugar de un problema de cumplimiento después, marcará la diferencia cuando ocurra un incidente o una auditoría.