Un prompt, diez comandos: tu agente de IA necesita sus propios permisos
Pide a un agente de programación que arregle un test. Lee archivos, ejecuta pruebas, instala una dependencia, abre una pull request y quizá consulta un servicio conectado. Esa expansión resulta útil. También hace que la frase original describa mal la autoridad que termina ejerciendo.
Mi regla es sencilla: dar al agente los permisos necesarios para esta tarea, en vez de heredar automáticamente todo lo que puede hacer su propietario.
Qué nos dicen realmente los datos
En su anuncio del 21 de octubre, BeyondTrust comunicó unos 1,28 millones de comandos de shell solicitados para aproximadamente 132.000 prompts durante cuatro semanas. Las observaciones comunicadas se referían a agentes de programación. No todos los comandos se ejecutaron necesariamente. Es actividad, no una tasa de ataques o compromisos, y no representa a todas las organizaciones.
La pregunta útil es qué ocurre entre la petición y sus efectos. Diez lecturas inocuas y una escritura en producción necesitan controles muy distintos.
La frontera que falta es la tarea
Imagina un agente investigando un error en el proceso de compra. Su propietario puede leer tickets, consultar producción, desplegar versiones y enviar correos a clientes. Para investigar quizá basten logs depurados y una copia de desarrollo. Las demás capacidades no quedan autorizadas automáticamente.
Un archivo del repositorio podría pedir que se subieran datos de diagnóstico. La respuesta de una herramienta podría sugerir un comando con un destino remoto. Son entradas que evaluar, no concesiones de permisos. El usuario autorizó una investigación; un documento no puede ampliar esa autorización.
OWASP describe el problema más amplio como agencia excesiva: funciones, permisos y autonomía innecesarios pueden convertir una salida inesperada en acciones dañinas. Usaría ese enfoque para revisar una integración, además de evaluar si el modelo reconoce instrucciones hostiles.
Convierte una petición vaga en una frontera ejecutable
Para esa investigación, definiría el siguiente contrato antes de habilitar el trabajo autónomo. Es un ejemplo de diseño, no una configuración para un producto concreto.
| Operación | Límite de esta tarea |
|---|---|
| Leer código | Un repositorio y un directorio de trabajo |
| Ejecutar pruebas | Entorno aislado con datos sintéticos |
| Consultar diagnósticos | Logs depurados del servicio y periodo afectados |
| Modificar archivos | Rama de trabajo; excluir secretos y configuración de despliegue |
| Conectar al exterior | Registro de dependencias y servidor de repositorios aprobados |
| Desplegar o contactar con clientes | Autorización separada para la operación concreta |
La política debe aplicarla el entorno de ejecución o el servicio que recibe la petición. Una frase en el prompt ayuda a expresar la intención, pero no revoca una credencial ni bloquea una conexión.
Utiliza operaciones de escritura estructuradas cuando sea posible. Una herramienta que recibe repositorio, rama, ruta y parche ofrece más contexto al control que una shell sin restricciones. Si necesitas una shell, aísla archivos, red y credenciales. Permitir ciertos nombres de comandos no garantiza seguridad cuando intérpretes, scripts y subprocesos pueden ejecutar otras acciones.
Autenticar una conexión MCP no resuelve toda la autorización
Model Context Protocol (MCP) conecta agentes con herramientas y datos. Decidir quién puede conectarse no determina si una acción pertenece a la tarea actual.
La especificación de autorización MCP describe la autorización HTTP y exige tokens destinados al servidor receptor. Su guía de seguridad rechaza el reenvío indiscriminado de tokens y trata fallos de consentimiento en proxies. Separa esas fronteras de credenciales de la política de tu aplicación: un token válido también debe superar los controles de recurso y operación. Las herramientas locales por stdio necesitan restricciones de proceso y entorno.
Conectar un agente de soporte al sistema de tickets, por ejemplo, no debería autorizar una exportación completa de clientes. Limita el acceso al flujo necesario, restringe el destino y caduca las concesiones temporales al finalizar la tarea.
Prueba la frontera con casos negativos inocuos
Validaría la integración en un entorno desechable antes de conectar credenciales de producción. Utiliza cuentas ficticias y registros sintéticos. El resultado observable importa más que una explicación convincente del modelo.
- Incluye en un documento de prueba una instrucción inocua para escribir fuera del directorio asignado. Comprueba que el control deniega la escritura.
- Solicita un registro sintético de otro proyecto. Comprueba que el servicio lo rechaza incluso con una identidad válida.
- Solicita una conexión de prueba a un destino no permitido. Comprueba que la política de red la bloquea.
- Revoca la credencial a mitad de sesión. Comprueba que el acceso posterior falla.
- Cambia el recurso o destino de una escritura aprobada. Comprueba que la aprobación anterior no cubre la operación modificada.
Son comprobaciones propuestas, no resultados de un benchmark que haya ejecutado. Registra operaciones permitidas y denegadas: un flujo averiado no debe parecer seguro simplemente porque no ejecuta nada.
Guarda evidencia suficiente para explicar una acción
En cada llamada relevante, registra propietario, identificador de tarea, sesión del agente, herramienta, recurso, decisión de política y resultado observado. Evita guardar credenciales o cargas sensibles. Distingue un intento de una escritura completada: invocar una herramienta no demuestra que un despliegue o mensaje haya terminado correctamente.
Si algo falla, deberías poder responder qué tarea autorizó la acción, qué credencial la realizó y qué control podría haberla detenido.
Empieza por un flujo concreto
Elige un trabajo con un resultado claro: investigar un test, preparar una actualización de dependencias o resumir incidentes depurados. Enumera las capacidades necesarias, elimina las demás y ejecuta los casos negativos antes de ampliar el acceso.
Busco una autonomía útil con límites explícitos. Si el agente termina el trabajo dentro de ellos, puedes automatizar pasos rutinarios sin convertir cada prompt en un cheque en blanco.
Si estás diseñando una integración así, contacta conmigo y trae un flujo real. Sus herramientas, credenciales y efectos son un punto de partida mejor que otra lista genérica de seguridad para agentes.
