Un agente personalizado en GitHub Copilot CLI es un perfil configurado con un rol, un conjunto acotado de herramientas y reglas de permisos que decide qué puede ejecutar sin supervisión y qué debe pedir aprobación. Para auditorías de seguridad, el objetivo es que el agente pueda escanear código o infraestructura y generar hallazgos, pero sin capacidad de leer secretos, variables de entorno completas o credenciales almacenadas en el sistema. Esto se consigue combinando alcance de herramientas, aislamiento de sistema de archivos y separación de red, no solo con una lista de comandos permitidos.
Qué es realmente un agente personalizado en Copilot CLI
Copilot CLI permite definir agentes con un nombre, una descripción de propósito y un conjunto de herramientas asociadas: ejecución de comandos, lectura y escritura de archivos, acceso a servidores MCP (Model Context Protocol) para integraciones externas, y en algunos casos acceso a un modelo distinto según la tarea. La diferencia frente a usar Copilot CLI en modo genérico es que el agente queda encapsulado: no hereda automáticamente todo el contexto ni todos los permisos de la sesión del desarrollador que lo invoca. Esto es exactamente lo que necesitas para tareas repetitivas y sensibles como un barrido de dependencias vulnerables, una revisión de cabeceras HTTP o un chequeo de exposición de puertos, porque limitas el radio de acción a lo estrictamente necesario para esa tarea. El error más común que vemos en equipos que empiezan con esto es tratar el agente como un asistente genérico al que se le da acceso amplio "por si acaso", en lugar de diseñarlo para una función concreta desde el primer momento.
Los campos que definen el rol del agente
Un agente de auditoría bien definido especifica al menos cuatro cosas: el rol (qué tipo de revisión hace y sobre qué activos), las herramientas permitidas (comandos de shell concretos, no shell libre), el alcance del sistema de archivos (directorios de solo lectura frente a directorios donde puede escribir informes) y el modelo o nivel de razonamiento asignado a la tarea. Cuantos más de estos campos dejes en valores por defecto, más amplio es el permiso implícito que el agente termina teniendo. La práctica que recomendamos es escribir primero la lista de lo que el agente necesita tocar y, solo después, la lista de herramientas que lo permiten, en ese orden y no al revés.
- Rol: qué audita (dependencias, configuración, superficie de red) y sobre qué repositorio o entorno
- Herramientas: comandos de shell explícitos, no acceso genérico a terminal
- Filesystem: rutas de solo lectura para el código, ruta separada de solo escritura para informes
- Red: acceso deshabilitado salvo a los endpoints estrictamente necesarios (registro de CVEs, APIs de escaneo)
El permiso de herramienta no es lo mismo que aislamiento real
Aquí está el mecanismo que casi nadie explica bien: restringir herramientas una a una no elimina el riesgo si esas herramientas se pueden combinar. Un agente con permiso de "leer archivos" y, por separado, permiso de "hacer peticiones HTTP" a un servidor MCP no tiene individualmente ningún permiso peligroso, pero la combinación de ambas sí permite leer un archivo .env o una clave privada y enviarla a un destino externo en una sola cadena de acciones. La seguridad de un agente no se evalúa herramienta por herramienta, se evalúa por las rutas de datos que su conjunto de herramientas hace posibles. Esto es idéntico al problema clásico de exfiltración en pipelines CI/CD, solo que ahora el agente decide la secuencia de pasos de forma autónoma en lugar de seguir un script fijo.
Por qué la lista de "allowed tools" no es un guardrail suficiente por sí sola
Muchos equipos asumen que declarar una lista de herramientas permitidas en el archivo de configuración del agente ya es el control de seguridad. En la práctica, esa lista es una capa de intención, no un aislamiento reforzado a nivel de sistema operativo: si el agente corre con el mismo usuario y los mismos permisos de filesystem que tu sesión de desarrollo, un fallo de diseño en el prompt o una herramienta MCP mal acotada puede saltarse la intención declarada. El estudio de fatiga de seguridad del NIST (Stanton et al., 2016) documentó un patrón que aplica directamente aquí: cuando un sistema pide aprobación repetidamente para acciones similares, las personas empiezan a aprobar por costumbre en lugar de evaluar cada solicitud, lo que anula el propósito del control. Un agente de auditoría que pide permiso para cada comando de escaneo entrena al equipo a pulsar "permitir" sin leer, exactamente el mismo mecanismo que erosiona los diálogos UAC de Windows o las peticiones de permisos en apps móviles.
Cómo evitar exponer credenciales al automatizar auditorías
La forma correcta de blindar esto no es confiar en que el agente "decida bien", es eliminar la posibilidad de que llegue a ver el secreto. Ejecuta el agente en un usuario o contenedor sin acceso a las variables de entorno de producción, monta solo los directorios de código que necesita auditar como solo lectura, y saca cualquier credencial real de ficheros locales hacia un gestor de secretos (Passbolt, Vault, o el que use tu organización) al que el agente no tiene acceso directo. Si el agente necesita autenticarse contra una API externa para el escaneo, dale un token de servicio con el mínimo alcance posible y con caducidad corta, nunca las credenciales personales del desarrollador que lo lanza. Esto convierte cualquier fuga de contexto del agente en un secreto de bajo valor y con ventana de explotación mínima, en vez de en una credencial de producción.
- Ejecutar el agente en usuario/contenedor separado, sin variables de entorno de producción
- Montar el código como solo lectura; separar la carpeta de salida de informes
- Sustituir credenciales personales por tokens de servicio de alcance mínimo y caducidad corta
- Auditar la combinación de herramientas permitidas, no solo cada herramienta por separado
- Registrar y revisar periódicamente qué acciones aprobó el agente sin intervención humana
Cuándo NO conviene automatizar la auditoría con un agente
Aquí conviene ser honestos: si tu equipo es pequeño, tiene dos o tres repositorios y hace una auditoría de dependencias una vez al trimestre, montar un agente personalizado con guardrails de aislamiento de filesystem y gestión de tokens de servicio puede ser más esfuerzo de mantenimiento que el problema que resuelve. La automatización de auditorías aporta valor real cuando hay repetición: varios repositorios, cadencia semanal o integración en CI, y un volumen de hallazgos que ya no es manejable revisando manualmente. Si no se dan esas condiciones, un script de escaneo programado más una revisión manual del informe sigue siendo la opción más simple y con menos superficie de riesgo. No siempre la respuesta correcta es "más automatización"; a veces es acotar el problema antes de construir infraestructura para resolverlo.
El fallo que más veces reparamos no es un agente mal configurado, es un agente configurado para un caso que no lo necesitaba: se hereda el mismo nivel de acceso amplio de una sesión normal de desarrollo porque nadie se paró a preguntar qué necesitaba tocar de verdad.
Pasos prácticos para desplegar tu primer agente de auditoría
- Define el rol en una frase: qué audita y sobre qué activo concreto, nada genérico
- Lista las herramientas mínimas necesarias y revisa qué combinaciones de esas herramientas podrían filtrar datos
- Aísla el entorno de ejecución: usuario o contenedor sin acceso a secretos de producción
- Sustituye cualquier credencial personal por un token de servicio de alcance mínimo
- Define qué acciones requieren aprobación manual siempre, aunque generen fricción
- Revisa el log de acciones aprobadas cada cierto tiempo para detectar aprobaciones automáticas por fatiga
Si quieres automatizar auditorías de seguridad con agentes IA sin arriesgar credenciales de producción, en Blurtek diseñamos el aislamiento, los guardrails y el alcance de herramientas antes de escribir una sola línea de configuración.
Solicitar diagnóstico