Un agente de IA es tan seguro como el entorno en el que se ejecuta. El modelo de lenguaje propone acciones, pero lo que de verdad decide qué ocurre en tu ERP, tu correo o tus servidores es lo que lo rodea: el harness, que fija qué puede hacer, y los guardrails, que revisan qué entra y qué sale. Entender esta diferencia es la base para desplegar agentes IA con un riesgo controlado.
Qué es el harness de un agente de IA
El harness es el entorno de ejecución que envuelve al modelo y controla todo lo que puede hacer: qué herramientas tiene disponibles, con qué permisos, a qué ficheros y redes accede, cuántas iteraciones o cuánto gasto se le permiten, cuándo debe pedir confirmación y qué queda registrado.
Una forma sencilla de verlo: el modelo es el conductor y el harness es el coche, con sus frenos, su limitador de velocidad y su caja negra. El conductor puede equivocarse o ser engañado; el coche impide que eso acabe en un precipicio.
Por eso se dice que la seguridad está en el harness y no en el modelo. Un modelo puede seguir instrucciones maliciosas escondidas en un correo, inventarse un dato o malinterpretar una petición. Ninguna instrucción en el prompt garantiza que no lo hará. Lo que sí se puede garantizar es que, aunque lo intente, no tenga la herramienta, el permiso o el acceso a red para hacer daño. OWASP lo resume en una de sus recomendaciones contra la agencia excesiva: aplicar la autorización en los sistemas de destino en lugar de confiar en que el modelo decida si una acción está permitida (OWASP LLM06).
Harness y guardrails: en qué se diferencian
El harness controla la capacidad del agente; los guardrails controlan el contenido. Los dos términos se mezclan a menudo, pero responden a preguntas distintas.
| Harness | Guardrails | |
|---|---|---|
| Pregunta que responde | ¿Qué puede hacer el agente? | ¿Qué entra y qué sale del modelo? |
| Ejemplos | Lista blanca de herramientas, permisos, sandbox, red restringida, límites, aprobación humana | Filtros de entrada, detección de prompt injection, moderación, validación de salidas, filtrado de datos personales |
| Cómo actúa | Restricciones deterministas: el sistema no deja hacer lo no permitido | Clasificadores y reglas: detectan y bloquean lo que reconocen |
| Si falla | El daño posible está acotado de antemano | Pasa contenido malicioso o se bloquea algo legítimo |
Un ejemplo con correo: el harness decide que el agente puede leer el buzón de facturas pero no enviar correos. Los guardrails revisan cada correo antes de que lo lea el modelo para detectar instrucciones sospechosas, y revisan la respuesta del agente para que no incluya datos bancarios completos.
Elementos de un buen harness
Estos son los componentes que revisamos en cualquier agente que va a tocar sistemas reales.
Lista blanca de herramientas
El agente solo dispone de las herramientas que necesita, definidas una a una. Nada de «acceso a todo el ERP»: herramientas concretas como consultar_pedido, crear_borrador_factura o buscar_cliente. OWASP recomienda limitar tanto el número de extensiones como su funcionalidad, y evitar las herramientas abiertas, como un intérprete de comandos genérico, cuando basta con una más granular.
Permisos por herramienta
Cada herramienta tiene su propio nivel de permiso: unas se ejecutan sin preguntar, otras requieren confirmación y otras están prohibidas. Y cada una usa una cuenta de servicio con los permisos mínimos en el sistema de destino, con credenciales que el modelo nunca ve. Lo explicamos en detalle en por qué no debes darle tus contraseñas a un agente de IA.
Ejecución aislada
Si el agente ejecuta código o comandos, debe hacerlo dentro de un contenedor o una máquina virtual, sin red o con red restringida a los dominios necesarios. Así, aunque un comando sea malicioso, no puede leer el resto del servidor ni enviar datos a cualquier dirección de internet.
Sistema de ficheros acotado
El agente solo puede leer y escribir en las carpetas de su tarea. Nada de acceso a la carpeta personal del usuario, a las claves SSH o a la configuración del servidor.
Límites de coste, tiempo e iteraciones
Un agente puede entrar en un bucle: reintentar, consultar una y otra vez o generar miles de llamadas. El harness fija un máximo de pasos, de tiempo y de gasto por tarea, y limita la frecuencia de las acciones. OWASP menciona la limitación de frecuencia como medida para detectar un problema antes de que el daño sea grande.
Confirmaciones humanas
Las acciones de alto impacto (pagos, borrados, envíos a clientes, cambios en producción) se detienen hasta que una persona las aprueba. La confirmación debe mostrar exactamente qué se va a hacer, no un resumen redactado por el propio modelo.
Registros y trazabilidad
Cada decisión y cada llamada a herramienta quedan registradas: qué pidió el modelo, con qué parámetros, qué permitió el harness y qué devolvió el sistema. Sin esto no se puede investigar un incidente ni mejorar el agente.
Solo lectura por defecto
El punto de partida es que el agente puede consultar pero no modificar. La escritura se habilita herramienta a herramienta, cuando hay motivos y controles.
Separación de entornos
El agente se prueba contra un entorno de pruebas con datos ficticios o anonimizados, y solo pasa a producción cuando se ha validado. Las credenciales de pruebas no sirven en producción, y al revés.
Cómo lo hacen los agentes de programación de Anthropic y OpenAI
Los agentes de programación son un buen ejemplo de harness bien diseñado, porque ejecutan comandos en máquinas reales y sus fabricantes documentan públicamente cómo los controlan.
Claude Code (Anthropic). Según su documentación de seguridad, en modo manual empieza con permisos de solo lectura y pide autorización antes de editar ficheros o ejecutar comandos; los comandos que no encajan con ninguna regla requieren aprobación por defecto, y los que descargan contenido de internet, como curl o wget, no se aprueban automáticamente. Su sandbox aplica restricciones a nivel de sistema operativo: los comandos solo pueden escribir en el directorio de trabajo y en los que se añadan, y no tienen salida directa a la red, sino a través de un proxy que comprueba cada dominio contra una lista de permitidos que empieza vacía. La propia documentación recomienda usar máquinas virtuales o contenedores para un aislamiento adicional y advierte de que ningún sistema es inmune a todos los ataques.
Codex (OpenAI). Su documentación de aprobaciones y seguridad describe modos de sandbox: solo lectura; escritura limitada al espacio de trabajo, donde pide aprobación para editar fuera de él o para comandos que necesitan red; y un modo sin sandbox ni aprobaciones que marca como no recomendado. Indica que, por defecto, el agente se ejecuta con el acceso a red desactivado.
Las dos herramientas siguen el mismo patrón: mínimo privilegio por defecto, aislamiento a nivel de sistema y ampliación explícita de permisos. Es exactamente lo que hay que trasladar a un agente que trabaja con tu ERP o tu CRM.
Qué son los guardrails de un agente de IA
Los guardrails son controles que revisan el contenido que entra y sale del modelo y bloquean o corrigen lo que no cumple una política. Actúan en varios puntos del recorrido.
Validación y filtrado de entradas
Antes de que la petición del usuario llegue al modelo principal se comprueba si es del tipo esperado y si contiene patrones de ataque conocidos. Anthropic propone usar un modelo ligero como filtro previo, con una salida estructurada que se limite a una clasificación (Mitigate jailbreaks and prompt injections).
Detección de prompt injection
La prompt injection indirecta llega en el contenido que el agente lee: un correo, una web, un PDF o la respuesta de una herramienta. La misma guía de Anthropic recomienda pasar el contenido no fiable solo como resultado de herramienta, indicar su origen, codificarlo en JSON para separarlo de las instrucciones y analizar la salida de cada herramienta con un clasificador antes de que el agente actúe sobre ella. Meta publica Llama Prompt Guard 2, una familia de clasificadores pequeños que etiquetan una entrada como benigna o maliciosa frente a prompt injection y jailbreaks; su ficha técnica señala una ventana de 512 tokens y recomienda ajustarlos con datos de la aplicación para obtener los mejores resultados.
Clasificadores de contenido
Sirven para detectar contenido dañino o fuera de política, tanto en entradas como en salidas. El endpoint de moderación de OpenAI clasifica texto e imágenes en categorías como acoso, odio o violencia, y es gratuito. Llama Guard 4, de Meta, es un clasificador de seguridad que se aplica a entradas y salidas, con categorías que se pueden personalizar; su ficha indica que está optimizado para inglés, así que en español hay que probarlo.
Validación de salidas con esquemas estructurados
Cuando el agente va a llamar a una herramienta o devolver datos, su salida se valida contra un esquema: campos obligatorios, tipos, rangos y valores permitidos. Si el modelo devuelve un importe negativo, un cliente inexistente o un campo de más, la acción no se ejecuta. Guardrails AI es un marco en Python que combina validadores en guardas de entrada y salida y ayuda a obtener datos estructurados de los modelos.
Filtrado de datos sensibles
Antes de mostrar una respuesta o enviarla fuera, se detectan y enmascaran datos personales, números de cuenta o identificadores que no deben salir. En un agente que responde a clientes por WhatsApp, por ejemplo, evita que se cuele el DNI o el IBAN de otra persona.
Políticas antes de ejecutar acciones
Es el punto donde harness y guardrails se tocan: cada llamada a herramienta se evalúa contra reglas antes y después de ejecutarse. El SDK de agentes de OpenAI distingue guardrails de entrada, de salida y de herramienta, y estos últimos se ejecutan antes y después de cada llamada a una herramienta protegida. Su documentación advierte de que, en modo paralelo, el agente puede haber consumido tokens o ejecutado herramientas antes de que el guardrail lo detenga, por eso ofrece un modo bloqueante. NeMo Guardrails, de NVIDIA, es una librería de código abierto que define rieles de entrada, de recuperación (para RAG), de diálogo, de ejecución de herramientas y de salida.
Por qué los guardrails no sustituyen al harness
Los guardrails reducen el riesgo, pero no lo eliminan: son clasificadores y reglas que reconocen lo que conocen. Un ataque nuevo, una instrucción escrita en otro idioma o un texto largo partido en trozos pueden pasar el filtro. OWASP reconoce que no está claro que existan métodos infalibles para prevenir la prompt injection (OWASP LLM01), y Anthropic recomienda, además de los filtros, aplicar mínimo privilegio, ejecutar las herramientas en entornos aislados y no dar al modelo acceso a secretos que no necesita.
La estrategia correcta es la defensa en profundidad:
- El harness acota el peor caso. Si el agente no tiene herramienta para enviar correos, ninguna inyección puede hacerle enviar uno.
- Los guardrails reducen la probabilidad. Detectan la mayoría de intentos antes de que lleguen a una acción.
- La aprobación humana cubre lo crítico. Lo que no puede salir mal pasa por una persona.
- Los registros permiten aprender. Lo que se cuela se detecta, se analiza y se corrige.
Si solo tienes guardrails, tu seguridad depende de que el filtro acierte siempre. Si tienes harness, un fallo del filtro tiene consecuencias limitadas. Si quieres un marco de referencia más amplio, el AI Risk Management Framework del NIST es un marco voluntario para gestionar los riesgos de la IA y cuenta con un perfil específico para IA generativa (NIST-AI-600-1). Para ver todos los riesgos en conjunto, consulta nuestro resumen del OWASP Top 10 para LLM.
Ejemplos de harness y guardrails en una empresa
Agente de facturación conectado al ERP. Harness: herramientas para consultar clientes y crear borradores de factura, sin emitir ni borrar; cuenta de servicio con esos permisos y nada más; límite de borradores por hora. Guardrails: validación del borrador contra un esquema (NIF válido, importes positivos, IVA permitido) y aprobación humana para emitir.
Agente que clasifica el correo entrante. Harness: lectura del buzón y etiquetado, sin envío ni reenvío; sin acceso a otros buzones. Guardrails: cada correo se trata como contenido no fiable, se analiza con un clasificador de inyección y el agente nunca ejecuta instrucciones que vengan en el cuerpo del mensaje.
Agente de operaciones en servidores. Harness: ejecución en un contenedor, solo comandos de diagnóstico de una lista blanca, red restringida a los hosts monitorizados, separación entre pruebas y producción, y confirmación humana para cualquier reinicio. Guardrails: comprobación de que cada comando propuesto encaja con la política antes de lanzarlo.
Asistente con documentos internos. Si el agente busca en tu documentación, los guardrails de recuperación y el control de permisos por documento son clave; lo desarrollamos en seguridad en RAG. Y si conectas herramientas mediante MCP, revisa también la seguridad en MCP: sus buenas prácticas recomiendan ejecutar los servidores locales en entornos aislados y con privilegios mínimos (MCP Security Best Practices).
Checklist: harness y guardrails de tu agente de IA
Harness
- El agente tiene una lista cerrada de herramientas, cada una con una función concreta.
- Cada herramienta tiene su nivel de permiso (libre, con confirmación o prohibida).
- Las herramientas usan cuentas de servicio con mínimo privilegio y el modelo no ve credenciales.
- Si ejecuta código o comandos, lo hace en un contenedor o una máquina virtual.
- La red está desactivada o limitada a los dominios necesarios.
- El acceso a ficheros se limita a las carpetas de la tarea.
- Hay límites de pasos, tiempo, gasto y frecuencia de acciones.
- Las acciones de alto impacto requieren aprobación humana con el detalle exacto de la acción.
- El agente empieza en solo lectura y la escritura se habilita caso a caso.
- Pruebas y producción están separadas, con credenciales distintas.
- Todas las decisiones y llamadas a herramientas quedan registradas.
Guardrails
- Las entradas del usuario se validan y filtran antes de llegar al modelo.
- El contenido externo (correos, webs, documentos, resultados de herramientas) se trata como no fiable y se analiza para detectar prompt injection.
- Las salidas que disparan acciones se validan con esquemas estructurados.
- Se filtran datos personales y sensibles antes de mostrar o enviar respuestas.
- Los clasificadores se han probado en español y con casos reales de tu negocio.
- El conjunto se ha atacado a propósito en un ejercicio de red teaming de IA antes de producción.
Cómo te ayudamos en Hive Mind Solutions
En Hive Mind Solutions diseñamos agentes de IA para empresas con seguridad por diseño: primero el harness (herramientas acotadas, mínimo privilegio, aislamiento, aprobación humana y registros) y, encima, los guardrails que necesita cada caso. Trabajamos con Claude, OpenAI y modelos abiertos, todo alojado en la UE y cumpliendo el RGPD.
Si ya tienes un agente en marcha, podemos revisar su harness y sus guardrails dentro de nuestro servicio de seguridad y cumplimiento de la IA, y completarlo con ciberseguridad para la infraestructura que lo rodea. Trabajamos en remoto con empresas de toda España, con precios muy difíciles de batir y empezando por algo pequeño y medible. Cuéntanos qué agente quieres desplegar y lo vemos juntos.
Fuentes
- LLM06:2025 Excessive Agency (OWASP Gen AI Security Project)
- Claude Code security (Anthropic)
- Configure the sandboxed Bash tool, Claude Code (Anthropic)
- Agent approvals & security, Codex (OpenAI)
- Mitigate jailbreaks and prompt injections (Claude Docs, Anthropic)
- Guardrails, OpenAI Agents SDK
- Moderation (OpenAI API docs)
- NeMo Guardrails overview (NVIDIA)
- Llama Prompt Guard 2 model card (Meta)
- Llama Guard 4 model card (Meta)
- Guardrails AI documentation
- Security Best Practices, Model Context Protocol
- LLM01:2025 Prompt Injection (OWASP Gen AI Security Project)
- AI Risk Management Framework (NIST)
