Un agente puede ejecutar correctamente una tarea de desarrollo y, aun así, tener permisos que nunca debió recibir.
El riesgo aparece cuando puede acceder a repositorios, ejecutar comandos o modificar información sin que existan restricciones efectivas sobre esas acciones.
Para evaluar la seguridad de agentes de IA en el SDLC, revisaría cinco situaciones antes de ampliar su autonomía. El objetivo es comprobar qué puede hacer el agente, qué operaciones deben bloquearse y qué evidencia queda disponible cuando algo falla.
1. Permisos: ¿puede modificar recursos fuera de su alcance?
Un agente encargado de analizar código no necesita necesariamente permisos para modificarlo. Tampoco debería poder intervenir cualquier repositorio solo porque tiene acceso a una herramienta de desarrollo.
La prueba: solicitar una modificación sobre una rama protegida o un repositorio no autorizado.
Lo que esperaría comprobar: que el sistema conectado rechace la operación, incluso si el agente intenta ejecutarla.
La distinción es importante cuando se utilizan servidores MCP para conectar agentes con Jira, GitHub u otras herramientas. Como explicamos en nuestro artículo sobre MCP para agentes de IA en desarrollo de software, cada integración necesita permisos definidos según las operaciones que expone.
2. Credenciales: ¿qué ocurre cuando se revoca un acceso?
Los agentes pueden necesitar credenciales para consultar repositorios, recuperar información o utilizar servicios internos.
Estas credenciales deben gestionarse mediante mecanismos autorizados y mantenerse fuera del contexto del modelo.
La prueba: revocar una credencial e intentar realizar una nueva solicitud con ella.
Lo que esperaría comprobar: que el sistema rechace el acceso y que el secreto no aparezca expuesto en las respuestas o registros del agente.
La revocación es especialmente relevante cuando cambia el alcance de un proyecto, finaliza una integración o se modifica una responsabilidad.
3. Aislamiento: ¿hasta dónde puede llegar una ejecución incorrecta?
Cuando un agente ejecuta código, también importa el entorno donde trabaja.
Un sistema de archivos restringido y controles de conectividad permiten delimitar los recursos disponibles durante la tarea.
La prueba: intentar acceder a archivos de otro proyecto o establecer una conexión hacia un destino no autorizado.
Lo que esperaría comprobar: que las restricciones del entorno impidan esas operaciones.
Este aislamiento debe evaluarse junto con los permisos de las herramientas externas. Limitar el entorno del agente no reemplaza los controles de acceso de los sistemas conectados.
4. Contexto y herramientas: ¿puede una instrucción externa provocar una acción indebida?
Un ticket, un documento o un archivo del repositorio pueden contener instrucciones que intenten modificar el comportamiento del agente.
Este riesgo, conocido como prompt injection, resulta relevante cuando la IA utiliza información externa para decidir qué herramientas invocar.
La prueba: incorporar una instrucción maliciosa en una fuente de consulta utilizada durante una ejecución controlada.
Lo que esperaría comprobar: que esa instrucción no consiga provocar una operación fuera de los permisos autorizados.
Por eso separaría las instrucciones que orientan el trabajo de los controles que determinan qué acciones puede realizar el sistema.
5. Aprobaciones y trazabilidad: ¿puedo reconstruir una acción?
Cuando un agente propone cambios sobre un sistema, necesito saber qué operación realizó, qué resultado obtuvo y bajo qué autorización avanzó.
Para las acciones críticas, definiría puntos de revisión humana y registros asociados a la ejecución.
La prueba: intentar avanzar una operación que requiere aprobación sin contar con ella.
Lo que esperaría comprobar: que el flujo no permita continuar y que quede evidencia suficiente para investigar el intento.
Esta revisión complementa lo que abordamos en nuestro artículo sobre gobernanza de agentes de IA en el SDLC, donde explicamos cómo organizar responsabilidades, aprobaciones y evidencia durante el desarrollo.
Cómo incorpora SPIREX® controles de seguridad al desarrollo de software
En ACL powered by DataArt, SPIREX® es un framework de orquestación de agentes que conecta herramientas, Skills y mecanismos de control dentro del ciclo de desarrollo de software.
Su arquitectura pública describe cuatro capacidades relacionadas con los riesgos anteriores:
- Sandbox por skill: ejecución de agentes en contenedores efímeros, con restricciones de red y sistema de archivos.
- Secretos fuera del modelo: credenciales acotadas por proyecto y resueltas durante la ejecución desde un gestor de secretos.
- Skills versionadas: instrucciones gestionadas en Git, revisadas por pares y reproducibles por proyecto mediante
skills.lock. - Aprobaciones y auditoría: puntos de validación humana y registros que incluyen información de la ejecución, hashes de entrada y salida, revisor, fecha y firma.
Estas capacidades están documentadas en la propuesta pública de SPIREX®. Su aplicación debe considerar los permisos, las herramientas y las características del entorno donde operarán los agentes.
También conviene distinguir dos funciones: el versionado permite controlar qué instrucciones se utilizan, mientras que los permisos y las restricciones técnicas determinan qué operaciones están autorizadas.
¿Por dónde comenzaría?
Elegiría un flujo acotado: un agente que consulta una historia en Jira, analiza código y prepara una propuesta para revisión.
Antes de habilitar operaciones adicionales, buscaría comprobar tres condiciones:
- Puede completar las tareas autorizadas.
- Los sistemas conectados rechazan acciones fuera de su alcance.
- Existen registros y puntos de intervención que permiten detener o investigar una ejecución.
Con esa evidencia, resulta más fácil decidir qué permisos mantener, qué controles corregir y qué grado de autonomía conviene habilitar.
Evalúa agentes de IA para tu SDLC con ACL powered by DataArt
Si tu organización está incorporando agentes al desarrollo de software, una buena forma de comenzar es revisar un proceso concreto: qué tareas podría ejecutar, qué herramientas necesita y qué controles deberían acompañar su implementación.
Conoce SPIREX® y agenda una sesión técnica con nuestros especialistas.
Preguntas frecuentes
¿Qué controles de seguridad necesita un agente de IA en producción?
Dependen de las herramientas, los datos y las operaciones que utiliza. Es recomendable comprobar sus permisos, la protección de credenciales, el aislamiento de ejecución, las autorizaciones para acciones críticas y los registros disponibles para auditoría.
¿Utilizar MCP garantiza la seguridad de los agentes de IA?
No. MCP facilita la conexión con herramientas y fuentes de información, pero la seguridad depende de los permisos configurados, la autenticación de las integraciones y los controles aplicados sobre cada operación.
¿Te ha interesado este contenido? No te pierdas nuestros otros artículos
- Agentes de IA en desarrollo de software: qué hacen y cómo se integran al SDLC
- ¿Tus datos están preparados para IA? 7 señales antes de llevarla a producción
- Qué procesos automatizar en retail y cómo priorizarlos
- Automatización con IA: qué cambia frente al RPA
- Cómo escalar el gobierno de datos cuando faltan capacidades internas
- Gobierno de datos para IA: cómo escalar modelos y agentes sin perder control
- Roles del gobierno de datos: quién decide, quién valida y quién opera
- Gobierno de datos: qué es y cómo implementarlo
