Seguridad de agentes: protege tus agentes de IA

Qué cubre este artículo sobre seguridad de agentes

• Qué riesgos presentan los agentes de IA y cómo minimizarlos
• Cómo trabajan juntos los sandboxes, los permisos de herramientas y los guardrails
• Cuándo tiene sentido usar Human-in-the-Loop y cómo implementarlo
• Cómo hacer que todas las acciones del agente sean rastreables mediante Audit Logs
• Un ejemplo práctico completo para asegurar un agente paso a paso

Introducción: seguridad de agentes explicada

Los agentes de IA son poderosos. Pueden leer archivos, enviar solicitudes de API, ejecutar código y comunicarse con sistemas externos. Precisamente ese poder conlleva riesgos. Un agente que actúa de forma autónoma puede ejecutar acciones no deseadas, enviar datos al lugar equivocado o causar costos en bucles infinitos.

La seguridad de agentes significa reducir sistemáticamente estos riesgos. Le das al agente solo las herramientas que realmente necesita. Monitoreas sus acciones. Implementas procesos de aprobación antes de ejecutar operaciones críticas. De esta forma disfrutas de la autonomía del agente sin perder el control.

Este artículo es parte de la serie Operación segura y se basa en los fundamentos de Sistemas de agentes.

¿Por qué necesito seguridad de agentes?

Imagina que tienes un agente de IA que debe gestionar archivos en tu sistema. Su tarea es limpiar y archivar archivos de registro antiguos. Le das acceso a todo el sistema de archivos.

El agente interpreta su tarea generosamente. Identifica archivos con el prefijo log y los elimina. Desafortunadamente, en un directorio de proyecto había un archivo llamado logic.js que el agente confundió con un archivo de registro. Ya no existe. O el agente envía un correo a todos los clientes porque cree que eso forma parte del archivado.

No son escenarios teóricos. Los agentes actúan según probabilidades, no según sentido común humano. Si les das acceso sin filtrar, cometen errores. La seguridad de agentes es el mecanismo de protección que evita que pequeños fallos se conviertan en grandes desastres.

Seguridad de agentes en pocas palabras

La seguridad de agentes abarca todas las medidas que restringen a un agente de IA para que pueda cumplir su tarea sin causar daño. La idea central es simple: permisos mínimos, control máximo.

Esto incluye:

• Sandbox: El agente se ejecuta en un entorno aislado sin acceso a tu sistema principal.
• Permisos de herramientas: Cada herramienta que usa el agente se autoriza explícitamente y puede estar restringida.
• Human-in-the-Loop: Las acciones críticas requieren aprobación humana antes de ejecutarse.
• Guardrails: Reglas que previenen que el agente realice acciones no deseadas o peligrosas.
• Audit Logging: Cada acción del agente se registra y es rastreable.

¿A quién va dirigido este artículo?

Este artículo está dirigido a desarrolladores que quieren implementar agentes de IA en producción o están considerándolo. Deberías entender cómo funciona Tool-Calling y qué son Sistemas de agentes. Los conocimientos técnicos previos en seguridad son útiles, pero no obligatorios.

Conceptos clave

Término	Explicación
Sandbox	Entorno de ejecución aislado donde el agente no afecta al sistema anfitrión
Guardrails	Reglas de seguridad que mantienen al agente dentro de límites definidos
Tool-Calling	Mecanismo mediante el cual un agente invoca herramientas y funciones externas
Permission	Autorización que determina si un agente puede usar una herramienta específica
Human-in-the-Loop	Principio en el que un humano debe confirmar decisiones críticas
Rate Limiting	Limitación de la cantidad de acciones por unidad de tiempo
Audit Log	Registro de todas las acciones que ha ejecutado un agente
Least Privilege	Principio de otorgar al agente solo los permisos mínimos necesarios
Veto	Capacidad de rechazar una acción planeada del agente
Escalation	Derivación de una decisión a una instancia superior, generalmente un humano

Riesgos de los agentes de IA

Acciones no deseadas

Los agentes no siempre interpretan las instrucciones como esperas. Un agente que puede ejecutar código podría iniciar un script que modifique tu sistema. Un agente con acceso de escritura a una base de datos podría eliminar registros porque los considera acciones de limpieza.

Fuga de datos

Si un agente accede a datos sensibles y al mismo tiempo se comunica con APIs externas, podría enviar datos a lugares donde no deberían estar. Un agente que lee datos de clientes e invoca un webhook podría transferir esos datos sin querer a un servicio de terceros.

Bucles infinitos

Los agentes pueden quedarse atrapados en bucles. El agente invoca una herramienta, recibe un resultado que lo lleva a invocar la herramienta nuevamente. Sin una condición de salida, este bucle se ejecuta indefinidamente. Consume poder de procesamiento, cuotas de API y dinero.

Explosión de costos

Cada invocación de herramienta, cada solicitud de API y cada paso de inferencia cuesta dinero. Un agente que opera sin límites puede generar costos considerables en poco tiempo. Especialmente con modelos basados en la nube como GPT-4, estos costos se suman rápidamente.

Medidas de seguridad

Sandbox

Un sandbox aísla el agente del resto de tu sistema. El agente solo puede acceder a los recursos que explícitamente pones a su disposición en el sandbox. Los archivos fuera del sandbox son invisibles, el acceso de red está restringido y los comandos del sistema solo afectan dentro del sandbox.

Permisos de herramientas

No toda herramienta disponible en teoría debe ser usada en la práctica. Define con precisión qué herramientas necesita cada agente. Un agente que solo debe analizar datos no necesita una herramienta para enviar correos. Un agente que crea reportes no necesita acceso de eliminación en la base de datos.

Approval Gates

Los Approval Gates son procesos de aprobación para acciones críticas. Antes de que el agente ejecute una acción clasificada como crítica, se pausa y espera tu confirmación. Más detalles en la sección Human-in-the-Loop.

Logging

Cada acción del agente se registra: qué herramienta se invocó, con qué parámetros, cuándo y con qué resultado. Así puedes reconstruir qué sucedió y encontrar la causa de los errores.

Rate Limits

Los Rate Limits limitan cuántas veces un agente puede ejecutar una acción en un período determinado. Por ejemplo, máximo 10 invocaciones de herramientas por minuto o máximo 100 solicitudes de API por hora. Esto previene bucles infinitos y explosiones de costos.

Entornos sandbox

Docker

Docker es el método más extendido para aislar agentes. Creas una imagen de contenedor con exactamente las herramientas y permisos que el agente necesita. El contenedor no tiene acceso a tu sistema de archivos anfitrión, a menos que explícitamente montes volúmenes. Puedes controlar el acceso de red mediante reglas de red de Docker. Los fundamentos los encontrarás en Docker Fundamentos.

Máquinas Virtuales

Para un aislamiento aún más sólido, las máquinas virtuales son una opción excelente. Una VM posee su propio kernel y está completamente separada del sistema host. Requiere más recursos que Docker, pero ofrece mayor seguridad, especialmente cuando el agente ejecuta código potencialmente malicioso.

Sistema de Archivos Restringido

Independientemente de Docker o VMs, puedes limitar el acceso al sistema de archivos. El agente opera dentro de un directorio específico y no puede naveguar fuera de él. Combinado con Ollama y ejecución local, esto cubre muchos casos de uso.

Permisos de Herramientas

Qué Herramientas Requieren Aprobación

Las herramientas con efectos irreversibles o externos siempre necesitan aprobación:

• Eliminar o sobrescribir archivos
• Enviar correos electrónicos
• Hacer requests a APIs externas
• Modificar o eliminar registros de bases de datos
• Ejecutar código
• Iniciar pagos

Qué Herramientas son Seguras

Las herramientas que solo leen o calculan se consideran seguras:

• Leer archivos
• Consultas de bases de datos (SELECT)
• Búsquedas
• Cálculos y transformaciones
• Almacenamiento en caché de información

La clasificación depende del contexto. El acceso de lectura a datos sensibles de clientes no es seguro si el agente puede llamar APIs externas simultáneamente. Siempre considera la combinación de todas las herramientas, no cada una de forma aislada.

Human-in-the-Loop

Human-in-the-Loop significa que una persona confirma decisiones críticas antes de que el agente las ejecute. El agente planifica una acción, la presenta para aprobación y se pausa. Solo cuando confirmas, la acción se ejecuta.

Esto funciona en varios niveles:

• Aprobación Completa: Cada acción debe ser confirmada. Es seguro, pero lento.
• Aprobación Categórica: Solo las acciones de categorías específicas, como envío de correos o eliminación de archivos, requieren aprobación.
• Aprobación por Umbral: Las acciones por debajo de cierta puntuación de riesgo se ejecutan automáticamente, las superiores requieren aprobación.

Encontrarás información detallada en el artículo Aprobaciones Humanas.

Audit Logging

Un registro de auditoría documenta cada acción del agente. Para cada entrada se captura como mínimo:

• Marca de tiempo
• Herramienta invocada
• Parámetros de la llamada a la herramienta
• Resultado de la acción
• Estado: exitosa, fallida, abortada

Con un registro de auditoría completo, puedes reconstruir posteriormente qué hizo el agente, por qué lo hizo y dónde algo salió mal. Esto es crucial no solo para la depuración, sino también para cumplimiento normativo y trazabilidad.

Almacena los registros de auditoría en un lugar donde el agente no tenga acceso de escritura. De lo contrario, un agente defectuoso puede borrar sus propias huellas.

Ejemplo: Asegurar un Agente

Imagina que construyes un agente que resume correos electrónicos y reenvía mensajes importantes a un canal de Slack. Así lo aseguras paso a paso.

Paso 1: Configurar la Sandbox

El agente se ejecuta en un contenedor Docker. La imagen del contenedor solo incluye las herramientas necesarias: cliente de correo, cliente de API de Slack y el modelo de IA. Sin acceso a shell, sin programas adicionales.

Paso 2: Definir Herramientas

El agente recibe exactamente tres herramientas:

• read_emails: Lee correos de la bandeja de entrada
• summarize_email: Resume un correo electrónico
• send_slack_message: Envía un mensaje a Slack

Nada más. El agente no puede eliminar archivos, ejecutar código ni enviar correos.

Paso 3: Establecer Permisos

read_emails y summarize_email se ejecutan sin aprobación. send_slack_message requiere aprobación antes de enviar. El agente propone un mensaje, lo confirmas, y solo entonces se envía.

Paso 4: Establecer Rate Limits

Máximo 20 correos por hora, máximo 10 mensajes de Slack por hora. Esto previene que el agente inunde el canal si entra en un bucle.

Paso 5: Activar Audit Logging

Cada llamada de herramienta se registra en una base de datos a la que el agente solo tiene acceso de lectura. Puedes rastrear qué correos fueron leídos y qué mensajes de Slack fueron enviados en cualquier momento.

Paso 6: Definir Guardrails

El agente no puede resumir correos marcados como confidenciales. No puede enviar mensajes a canales que no estén en una lista de permitidos. Estas reglas se implementan como guardrails en el prompt de sistema y en la lógica de las herramientas.

Trampas Comunes

1. Demasiados Permisos: Das al agente “todo” porque es más fácil. Funciona hasta que no funciona. Comienza con permisos mínimos y expande solo cuando sea necesario.

2. Sin Rate Limits: Sin límites, un agente puede ejecutar cientos de llamadas en minutos si entra en un bucle. Siempre establece límites, incluso si estás seguro de que no ocurrirá.

3. Registros de Auditoría en el Mismo Directorio: Si el agente puede escribir sus propios logs y tiene acceso al directorio de logs, puede borrar sus huellas cuando falla. Almacena los logs fuera del alcance del agente.

4. Ignorar Aprobaciones: Cuando se solicitan aprobaciones constantemente, los usuarios tienden a confirmar sin pensar. Esto invalida Human-in-the-Loop. Usa aprobaciones selectivamente, solo para acciones realmente críticas.

5. Guardrails Solo en el Prompt: Los guardrails que solo están en el prompt de sistema no son reales. El agente puede ignorarlos. Implementa restricciones técnicas además en la lógica de las herramientas.

6. Sin Pruebas para Casos de Error: Prueba qué sucede cuando el agente llama una herramienta incorrectamente, cuando una API no está disponible o cuando entra en un bucle. Los errores son precisamente donde la seguridad importa.

7. Acciones de Limpieza Olvidadas: Un agente que crea archivos temporales debe también eliminarlos. Si no es parte de su tarea, los datos se acumulan con el tiempo, llenando la sandbox y ralentizando el sistema.

Hardware, Costos y Seguridad

La seguridad tiene un costo. Los contenedores Docker consumen memoria adicional. Las VMs requieren recursos propios. Los registros de auditoría requieren almacenamiento. Los rate limits pueden ralentizar agentes si necesitan esperar.

Estos costos son mínimos comparados con el daño que causa un agente no asegurado. Una base de datos eliminada, una fuga de datos o una explosión de costos en un proveedor de nube son mucho más caros que la infraestructura para ejecución segura de agentes.

Si trabajas localmente con Ollama, eliminan los costos de API, pero las medidas de seguridad siguen siendo necesarias. Sandbox, permisos y logging son independientes de dónde se ejecute el modelo.

Para entender cómo un agente planifica acciones y reflexiona sobre sus propios pasos, consulta el artículo Planificación y Reflexión.

Enlaces Relacionados

• Operación Segura - Descripción general de artículos sobre operación segura de sistemas de IA
• Aprobación Humana en Seguridad - Puertas de aprobación y derechos de veto
• Configurar Guardrails - Reglas y filtros para agentes
• Protección contra Prompt Injection - Defenderse contra ataques
• Sandbox para Agentes de IA - Aislamiento con Docker, VM y sistema de archivos
• Audit Logging - Rastrear acciones de agentes
• Aprobaciones Humanas - Guía detallada de Human-in-the-Loop
• Tool Calling - Fundamentos de invocación de herramientas externas
• Sistemas de Agentes - Arquitectura de sistemas de agentes
• Planificación y Reflexión - Cómo planifican y reflexionan los agentes
• Fundamentos de Docker - Aislamiento con contenedores
• Ollama - Ejecutar modelos de IA localmente

Preguntas frecuentes

¿Qué es la seguridad de agentes?

La seguridad de agentes incluye todas las medidas que restringen un agente de IA para que pueda cumplir su tarea sin causar daños. Esto abarca entornos sandbox, permisos de herramientas, guardrails, aprobaciones con participación humana y audit logging.

¿Necesito una sandbox para cada agente?

Sí. Incluso un agente simple puede ejecutar acciones no intencionadas. Una sandbox requiere poco esfuerzo y evita que los errores afecten tu sistema principal.

¿Cuál es la diferencia entre guardrails y permisos de herramientas?

Los permisos de herramientas determinan si un agente puede usar una herramienta. Los guardrails determinan cómo se puede usar esa herramienta. Los permisos son un interruptor de sí/no, los guardrails son reglas dentro de ese interruptor.

¿Cuándo necesito participación humana en el bucle?

La participación humana es útil para todas las acciones que son irreversibles, tienen efectos externos o generan costos. El envío de correos, la eliminación de archivos, las llamadas API a servicios externos y los pagos son candidatos típicos.

¿Cómo evito bucles infinitos?

Combina límites de velocidad con un número máximo de pasos por tarea. El agente se detiene cuando alcanza un número específico de llamadas a herramientas, independientemente del resultado.

¿Dónde almaceno los audit logs?

Los audit logs deben guardarse en un lugar al que el agente no tenga acceso de escritura. Puede ser una base de datos separada, un sistema de logs externo o un directorio de solo lectura.

¿Cuánto cuesta la seguridad de agentes?

La infraestructura de seguridad, como contenedores Docker y logging, consume poder de cómputo y almacenamiento. Comparado con los costos de un agente sin protección que cause daños, estos gastos son insignificantes.

¿Puedo asegurar un agente sin Docker?

Sí. Puedes restringir el sistema de archivos, definir permisos de herramientas y activar audit logs sin Docker. Docker proporciona aislamiento adicional, pero no es la única opción.

¿Qué es el principio de menor privilegio?

El principio de menor privilegio significa dar a un agente solo los permisos mínimos necesarios. Si el agente solo necesita leer, no recibe acceso de escritura. Si necesita un archivo específico, no recibe acceso a todo el directorio.

¿Cómo pruebo la seguridad de agentes?

Simula casos de error. Haz que el agente llame a una herramienta de forma incorrecta, corta la conexión a una API, provoca un bucle. Verifica que las medidas de seguridad funcionen y que el agente se comporte de manera controlada.

¿Son los modelos locales más seguros que los modelos en la nube?

Los modelos locales como Ollama reducen el riesgo de fugas de datos, ya que no se envía información a un proveedor en la nube. La seguridad de agentes, es decir, el control de las acciones del agente, es independiente de esto y es necesaria en ambos casos.

Fuentes

• OWASP: Top 10 for Large Language Model Applications
• NIST: AI Risk Management Framework
• Docker: Container Security Documentation
• Anthropic: Responsible Scaling Policies