Guía · Intermedio · 12 min
Cómo proteger un agente de IA: permisos, secretos, entorno aislado, aprobación humana y registros
Proteger un agente de IA exige limitar permisos, resguardar secretos y controlar sus acciones. Aprenda a aislar tareas, aprobar cambios y registrar operaciones.
Proteger un agente de IA consiste en limitar lo que puede leer, modificar y transmitir, y en controlar sus acciones sensibles antes de ejecutarlas. Las protecciones deben aplicarse mediante las herramientas, las cuentas y el entorno de ejecución: las instrucciones escritas para el modelo no bastan. Los permisos mínimos, la separación de secretos, el aislamiento, la aprobación humana y los registros son capas de protección complementarias.
Parta de las posibles consecuencias
Un agente que prepara una respuesta comercial no necesita los mismos accesos que uno que modifica un servidor. Empiece por describir la tarea, los datos necesarios y las consecuencias de un error: divulgar un documento, elegir un destinatario incorrecto, sobrescribir un archivo, generar un gasto o dejar un servicio fuera de funcionamiento.
Distinga también las fuentes consultadas. Una solicitud del usuario autorizado, un archivo adjunto recibido y la respuesta de una herramienta no tienen la misma autoridad. El contenido encontrado durante una tarea debe tratarse como información que hay que examinar, aunque tenga la apariencia de una instrucción técnica.
OWASP distingue entre exceso de funciones, de permisos y de autonomía al presentar el riesgo de autonomía excesiva. Esta separación permite plantear preguntas concretas: si hace falta ofrecer esa herramienta, concederle esos permisos y dejar que el agente la utilice sin supervisión.
Antes de conectar cuentas, redacte una ficha que delimite el ámbito de actuación:
- objetivo autorizado y resultado esperado;
- carpetas, aplicaciones y categorías de datos accesibles;
- operaciones permitidas, sujetas a aprobación o prohibidas;
- persona responsable y procedimiento de detención;
- condiciones para reanudar la actividad después de un error.
El diagnóstico de seguridad de agentes puede ayudarle a identificar los aspectos que conviene revisar. No sustituye la comprobación de los permisos realmente concedidos en su entorno.
Aplique el principio de mínimo privilegio a cada herramienta
El principio de mínimo privilegio consiste en conceder únicamente los permisos necesarios para la tarea y durante el tiempo que hagan falta. Aplíquelo a los archivos, las cuentas de aplicaciones, los accesos de red y las operaciones disponibles en las herramientas.
Separe la consulta, la preparación y la ejecución. Para gestionar facturas, el agente puede consultar un conjunto limitado de documentos y preparar borradores sin poder modificar los datos bancarios. Una herramienta específica para esa función permite delimitar mejor la tarea que un acceso general a una terminal.
Las restricciones deben comprobarse en el servicio que ejecuta la operación. Un parámetro propuesto por el modelo, como el identificador de un cliente, no demuestra que el usuario tenga autorización para consultar los datos de ese cliente.
| Uso | Lectura autorizada | Escritura autorizada | Aprobación prevista |
|---|---|---|---|
| Resumir documentos | Carpeta seleccionada | Nuevo resumen en un espacio dedicado | Antes de compartirlo fuera de la organización |
| Preparar recordatorios de pago | Facturas y contactos correspondientes | Borradores de mensajes | Antes del envío |
| Corregir código | Copia del repositorio correspondiente | Rama de trabajo dedicada | Antes de publicar o desplegar |
| Analizar un incidente | Registros necesarios | Informe de análisis | Antes de modificar el servicio |
Esta tabla propone una política inicial que deberá adaptar. Compruebe también las vías indirectas: una herramienta de lectura que puede acceder libremente a una dirección externa abre un canal de salida de datos. Una terminal puede eludir la separación entre varias herramientas especializadas si dispone de sus credenciales.
Por último, elimine las conexiones antiguas. Una herramienta que dejó de utilizarse durante una prueba no debe seguir disponible por defecto.
Separe las identidades y proteja los secretos
Utilice una identidad dedicada al agente o una delegación vinculada al usuario que inicia la tarea. Evite proporcionarle una cuenta personal con acceso de administrador. Debe ser posible suspender la automatización sin bloquear toda la actividad de las personas.
Una clave API, un token de acceso, una cookie de sesión o una clave privada son secretos. No los incluya en las instrucciones, los ejemplos ni la memoria del agente. El servicio encargado de ejecutar la herramienta debería obtener la credencial necesaria sin devolver su valor al modelo.
La documentación de OWASP sobre gestión de secretos detalla cómo controlar su acceso, rotarlos y revocarlos. Para su agente, asocie cada secreto a un responsable, un uso, un ámbito de acceso y un procedimiento de sustitución.
Un archivo de configuración excluido del repositorio sigue siendo legible para un proceso que tenga los permisos correspondientes. Del mismo modo, una variable de entorno sigue siendo accesible para el programa que la recibe. Estos mecanismos de distribución no establecen una separación respecto de una terminal ejecutada con la misma identidad.
En un caso de preparación de recordatorios de pago, el servicio de envío puede conservar el secreto del correo y aceptar únicamente una operación estructurada después de su aprobación. El proceso encargado de leer las facturas no tiene entonces ningún motivo para disponer de esa credencial.
Si un secreto aparece en una conversación o un registro, elimine las copias accesibles, pero revoque también la credencial en el servicio de origen.
Elija un entorno aislado según los accesos necesarios
Un entorno aislado o sandbox limita los recursos a los que puede acceder un programa. Su eficacia depende de la configuración: carpetas compartidas, privilegios, red, dispositivos y servicios accesibles desde el entorno.
Prepare un espacio de trabajo desechable que contenga únicamente los archivos necesarios. Monte los archivos de origen en modo de solo lectura cuando la tarea lo permita y reserve una carpeta distinta para los resultados. Excluya los directorios personales, las credenciales de producción y las sesiones habituales del navegador.
| Entorno | Separación obtenida | Aspecto que debe comprobar | Uso posible |
|---|---|---|---|
| Cuenta de sistema dedicada | Permisos y archivos separados | Grupos y recursos compartidos | Tareas locales con límites definidos |
| Contenedor restringido | Entorno delimitado de procesos y archivos | Núcleo compartido, montajes y privilegios | Ejecución reproducible |
| Máquina virtual dedicada | Sistema invitado separado | Carpetas compartidas y red | Código menos fiable o necesidades de mayor aislamiento |
La documentación sobre seguridad de contenedores explica los riesgos asociados al demonio, los montajes y las capacidades del sistema. Un contenedor con privilegios elevados, o capaz de controlar el motor de contenedores del equipo anfitrión, amplía considerablemente los accesos disponibles.
Compruebe los límites desde dentro: intente leer fuera del ámbito autorizado, escribir en una carpeta prohibida y acceder a un servicio no permitido. La prueba debe demostrar que el acceso se deniega de forma efectiva.
El artículo Ejecutar un agente de IA en un entorno aislado desarrolla los aspectos prácticos. Aquí, el criterio sigue siendo la separación conseguida, con independencia del nombre que reciba el entorno.
Controle las comunicaciones salientes y los datos transmitidos
Prohibir la escritura local no protege los datos que el agente puede enviar a otro lugar. Examine los canales disponibles: solicitudes web, mensajería, carga de archivos, navegación, sincronización y recopilación de registros.
Para cada destino, defina qué datos puede recibir. Autorizar la conexión con el proveedor del modelo implica determinar qué fragmentos se incluirán en las solicitudes. El permiso para consultar un sitio no debería permitir transmitirle libremente el contenido de documentos internos.
Dé prioridad a una lista de destinos necesarios, cuyo cumplimiento se imponga fuera del proceso controlado por el agente. Si una herramienta acepta una dirección arbitraria, compruebe también cómo gestiona las redirecciones y las direcciones de la red interna. Una dirección que parece pública no basta para identificar el destino final.
La presentación de Microsoft sobre las responsabilidades de seguridad de los agentes destaca, entre otros, los riesgos del contenido no fiable y de las delegaciones demasiado amplias. Quien opera el agente debe relacionar esos riesgos con las conexiones que realmente autoriza.
Reduzca los datos antes de transmitirlos: elimine campos innecesarios, seleccione los documentos y limite los archivos adjuntos. El enmascaramiento automático puede ayudar, pero compruebe sus resultados con los formatos que utiliza.
En un ejemplo ficticio de atención al cliente, puede bastar con transmitir el mensaje correspondiente y la referencia del caso. Facilitar todo el historial del cliente aumenta la exposición sin mejorar necesariamente la resolución de la solicitud.
Trate la inyección de prompts como un riesgo de actuación
Una inyección de prompts intenta que el agente siga instrucciones incluidas en el contenido que procesa. Pueden aparecer en un correo electrónico, un documento, una página web, la descripción de una herramienta o un resultado de búsqueda.
El riesgo se materializa cuando esas instrucciones provocan una acción: transmitir un archivo, cambiar un destinatario o ejecutar un comando. Por tanto, completar correctamente una tarea habitual no demuestra que sus límites resistan un contenido malicioso.
El glosario de OWASP sobre inyección de prompts describe las inyecciones directas e indirectas y las limitaciones de las protecciones. Las instrucciones explícitas y los filtros pueden reducir el riesgo, pero no garantizan que el modelo ignore todos los intentos.
Establezca varias barreras independientes. Un documento puede solicitar un envío, pero la herramienta de envío sigue sin estar disponible. Un resultado puede proponer otra carpeta, pero el servicio rechaza las rutas ajenas al ámbito autorizado. Una página puede anunciar una urgencia, pero no puede conceder nuevos permisos.
Examine también los resultados que se muestran. Un enlace o un recurso remoto generado a partir de datos sensibles puede convertirse en un canal de filtración según el comportamiento de la interfaz.
El artículo Seguridad de los agentes de IA: riesgos y protecciones ofrece una visión transversal. Para el funcionamiento diario, vincule cada riesgo a un control observable y a una persona capaz de intervenir.
Controle los servidores MCP, las extensiones y las dependencias
Conectar un conector incorpora código, dependencias y, en ocasiones, un servicio remoto al conjunto de elementos en los que se confía. Antes de instalarlo, compruebe su procedencia, quién lo mantiene, sus funciones y los permisos que solicita.
Deje constancia de lo aprobado: origen del paquete, revisión elegida, configuración, herramientas disponibles y destinos contactados. Cada actualización debe permitir revisar estos elementos. Los cambios en el código pueden alterar el ámbito de acceso aunque el nombre del conector siga siendo el mismo.
Para un servidor local, examine los permisos del proceso que se inicia. Para uno remoto, revise también la autenticación, los datos transmitidos y la separación entre usuarios. En ambos casos, ocultar una herramienta en la interfaz no sustituye su control de acceso.
Las buenas prácticas oficiales de seguridad de MCP abordan, entre otros aspectos, la validación de tokens, el servicio al que están destinados y los riesgos de delegación. Un servidor no debe aceptar sin comprobarlo un token destinado a otro servicio. El acceso a una sesión o a un estado también debe permanecer vinculado a la identidad autorizada.
La guía Elegir un servidor MCP amplía estos criterios, y el directorio de servidores MCP facilita la búsqueda de proyectos. Una ficha o una gran popularidad no equivalen a una auditoría.
Si una extensión destinada a leer documentos solicita también una terminal o acceso completo a la cuenta, pida que se justifique. Si no es posible reducir esos permisos, elija otra integración.
Diseñe una aprobación humana vinculada a la acción exacta
Una solicitud de aprobación útil muestra qué va a ocurrir: operación, objeto de la acción, datos afectados, destino y efecto esperado. Una petición general de permiso para continuar la tarea aporta muy poca información para decidir.
Para un mensaje, muestre el contenido final, los destinatarios y los archivos adjuntos. Para una modificación de archivos, presente las diferencias y las rutas afectadas. Para una operación de negocio, exponga los parámetros que determinan sus consecuencias.
La aprobación debe quedar vinculada a esa propuesta concreta. Si el agente modifica después el destinatario, el archivo adjunto o la operación, será necesaria una nueva aprobación. El servicio que ejecuta la acción debe comprobar esa correspondencia.
La guía de OWASP sobre seguridad de agentes recomienda, entre otras medidas, separar la decisión de la ejecución en las operaciones irreversibles. Organice esa separación dentro de la aplicación y deniegue la operación por defecto cuando falte una aprobación obligatoria o haya caducado.
Evite también la fatiga de aprobación. Reserve las solicitudes para las transiciones que cambian el riesgo: publicar, enviar información al exterior, eliminar, modificar accesos o asumir un compromiso financiero. Las lecturas habituales pueden seguir siendo automáticas dentro de un ámbito ya definido.
Por último, prevea cómo continuar cuando se rechace una acción. El agente debe poder guardar un borrador, explicar el bloqueo o solicitar un dato que falta. No debería buscar otra herramienta para realizar la operación denegada.
Registre las operaciones sin acumular secretos
Los registros deben permitir reconstruir las acciones relevantes para una investigación: solicitud inicial, identidad, herramienta utilizada, decisión sobre los permisos, aprobación si corresponde, resultado y error. Distinga entre una acción propuesta y otra realmente ejecutada.
Utilice un identificador de tarea común a los distintos componentes. Conserve las referencias de los objetos afectados y los parámetros necesarios para comprender lo sucedido, ocultando los valores sensibles. El texto generado por el modelo no constituye por sí solo una prueba de ejecución.
La documentación de OWASP sobre registros especifica qué información registrar, cuál excluir y qué protecciones aplicar. Evite, en particular, los tokens de acceso y las contraseñas. La conservación de documentos completos y datos personales también requiere una justificación.
Proteja los registros para que el agente no pueda modificarlos. Defina quién puede consultarlos, cuánto tiempo se conservan y cómo se eliminan. Pruebe también el comportamiento del sistema cuando falle la recopilación: una acción sensible debe seguir una política explícita.
Configure alertas para eventos comprensibles: denegaciones repetidas, un nuevo destino, cambios de permisos o actividad que continúa después de una orden de detención. Cada alerta debe tener un destinatario y un procedimiento de atención.
La guía Supervisar un agente de IA en producción profundiza en la organización de registros y alertas. La recopilación solo aporta protección si alguien puede utilizarla.
Despliegue de forma gradual y pruebe las denegaciones
Antes de poner el agente en marcha, disponga de un entorno de pruebas, datos ficticios, una persona responsable y un mecanismo para interrumpir las tareas. Las pruebas deben comprobar tanto los límites como los resultados esperados.
- Empiece en modo de solo lectura. Compruebe los objetos consultados y la información transmitida a servicios externos.
- Autorice la preparación. El agente genera borradores o modificaciones en un espacio separado.
- Pruebe los bloqueos. Introduzca un documento que solicite filtrar datos, una ruta prohibida y un destino no autorizado.
- Añada una ejecución controlada. Compruebe que se deniega la acción sin aprobación y que se bloquea si los parámetros cambian después de aprobarla.
- Amplíe los accesos tras revisarlos. Conceda un permiso adicional para una necesidad identificada y repita las pruebas correspondientes.
Pruebe también la cancelación durante una tarea, la revocación de una cuenta y el aislamiento entre usuarios. Un agente no debe poder recuperar documentos de otra sesión debido a una memoria compartida mal delimitada.
Para las operaciones que puedan repetirse después de un error, prevea una protección contra duplicados. Que se haya superado el tiempo de espera no demuestra que un envío o una modificación hayan fallado.
Conserve los resultados esperados de estas pruebas. Repita los escenarios afectados después de cambiar el modelo, las instrucciones, un conector o los permisos. Una configuración validada sigue siendo un estado que hay que mantener, con sus dependencias y sus limitaciones conocidas.
Problemas frecuentes y preparación ante incidentes
El agente pide cada vez más permisos. Revise la necesidad de negocio y la herramienta utilizada. Una denegación puede revelar que falta un permiso, pero también un intento de actuar fuera del ámbito autorizado. Amplíe únicamente el acceso que haya identificado como necesario.
El entorno aislado permite ver archivos personales. Examine los montajes, los directorios heredados y las credenciales disponibles. Vuelva a crear un entorno mínimo y compruebe, desde el proceso del agente, que no tiene acceso a esos archivos.
Las solicitudes de aprobación resultan difíciles de entender. Reduzca el tamaño de las operaciones presentadas y muestre sus consecuencias concretas. Una cadena larga de acciones debería permitir identificar los pasos sensibles antes de dar el consentimiento.
Los registros contienen información confidencial. Corrija la recopilación en su origen y gestione las copias existentes. Añadir un filtro a la interfaz de consulta no elimina los datos que ya están almacenados.
Prepare un procedimiento de respuesta a incidentes accesible sin recurrir al agente. Debe permitir suspender tareas, cortar conexiones, revocar accesos y conservar las pruebas útiles. Asigne cada operación a una persona responsable.
Después de un incidente, compruebe las acciones realmente ejecutadas y los datos que estuvieron accesibles durante el periodo afectado. Restaure a partir de una fuente conocida, corrija el control que falló y repita el escenario antes de reanudar la actividad. El resumen redactado por el agente puede ayudar a orientar la revisión, pero debe contrastarse con los registros de los servicios.
Antes de poner el agente en servicio, compruebe lo siguiente:
- Los permisos efectivos corresponden al ámbito definido por escrito.
- Los secretos y los datos innecesarios no aparecen en el contexto.
- Se han probado las restricciones de archivos y de red.
- Las aprobaciones corresponden a los parámetros que realmente se ejecutan.
- Los registros permiten investigar sin exponer credenciales.
- La detención, la revocación y la reanudación tienen una persona responsable designada.
Páginas relacionadas
Preguntas frecuentes
¿Es seguro un agente de IA que se ejecuta en local?
La ejecución local reduce ciertas transferencias a un proveedor de alojamiento, pero no determina los permisos del programa. Un agente local puede seguir leyendo sus documentos, utilizando sus sesiones abiertas o transmitiendo datos mediante sus herramientas. Revise por separado dónde se aloja el modelo, los conectores y los accesos al sistema.
¿Se puede incluir una clave API en las instrucciones de un agente?
Evite hacerlo: las instrucciones se convierten en una copia adicional del secreto que puede acabar en historiales y registros. Deje que el servicio que ejecuta la herramienta utilice la credencial. Si una clave ha quedado expuesta, revóquela en el servicio del proveedor.
¿Hay que aprobar cada acción de un agente de IA?
Exigir aprobación para todo puede hacer que la supervisión resulte difícil de mantener. Defina operaciones habituales permitidas dentro de un ámbito concreto y exija aprobación para los cambios sensibles. Una autorización general para terminar una tarea no debe interpretarse como consentimiento para todas sus consecuencias.
¿Un entorno aislado impide las filtraciones de datos?
Puede limitar los archivos y procesos accesibles, pero sigue siendo posible filtrar información por un canal autorizado. Un entorno aislado que contiene datos privados y puede comunicarse libremente mantiene un riesgo de exfiltración. También es necesario filtrar las comunicaciones salientes y limitar los datos disponibles.
¿Qué hacer si un agente ha enviado información confidencial?
Suspenda su ejecución y bloquee los accesos afectados antes de retomar la tarea. Conserve los registros útiles, identifique la información transmitida y revoque las credenciales expuestas. Después, encargue la revisión del incidente a los responsables correspondientes según la naturaleza de los datos.