Cómo asegurar un agente de IA: arquitectura, permisos y runtime según NVIDIA
Los agentes de IA ya no solo responden preguntas: pueden ejecutar código, utilizar herramientas, acceder a APIs, consultar archivos y operar durante largos periodos. NVIDIA publicó el 21 de agosto de 2026 una arquitectura de seguridad para este nuevo escenario y sostiene que las barreras realmente exigibles deben vivir fuera del modelo y del harness, principalmente en el runtime y la infraestructura que controlan identidad, permisos, credenciales, aislamiento y auditoría.
Dónde colocar la seguridad en un agente autónomo y cómo evitar que pueda saltarse sus propios controles
Cómo asegurar un agente de IA autónomo sin confiar únicamente en prompts
NVIDIA propone separar el comportamiento del agente de la autoridad real que posee. La clave está en colocar controles exigibles en capas que el propio agente no pueda modificar ni saltarse.
La seguridad de agentes de IA se vuelve más importante a medida que los sistemas dejan de limitarse a generar texto y empiezan a ejecutar código, llamar APIs, utilizar herramientas y modificar sistemas reales.
En un chatbot tradicional, una respuesta incorrecta puede resultar molesta. En cambio, un agente con acceso a infraestructura, CRM, archivos, credenciales o herramientas de desarrollo puede convertir un error de razonamiento en una acción con consecuencias reales.
Por ello, NVIDIA plantea una separación fundamental: los modelos, instrucciones y harnesses pueden orientar el comportamiento, pero las restricciones realmente exigibles deben vivir en una capa que el propio agente no controle.
Por qué asegurar un agente es diferente a asegurar un chatbot
Un agente puede mantener contexto durante sesiones largas, planificar varios pasos y utilizar herramientas para completar objetivos. Además, algunos sistemas pueden crear subagentes, ejecutar comandos o interactuar con servicios externos.
Esa autonomía incrementa la superficie de ataque. Un documento, mensaje, página web o resultado de una herramienta puede contener instrucciones maliciosas capaces de influir en el comportamiento del agente.
Asimismo, cuanto mayor sea la autoridad del sistema, mayor será el impacto potencial. Leer un documento no tiene el mismo riesgo que modificar una base de datos, transferir información o desplegar código en producción.
Datos
El agente puede acceder a documentos, CRM, bases de datos y otras fuentes con información sensible.
Herramientas
APIs, MCP, terminales y herramientas externas amplían lo que el agente puede hacer.
Acciones
Cuando el sistema puede cambiar estado externo, la seguridad deja de ser solamente un problema de texto.
Las capas principales de un AI agent stack
NVIDIA describe el agent stack mediante responsabilidades separadas. Aunque una plataforma comercial puede combinar varias capas, entenderlas de forma independiente ayuda a identificar dónde debería vivir cada control.
En otras palabras, la inteligencia puede estar arriba. Sin embargo, la autoridad efectiva debe quedar limitada por componentes situados debajo de una frontera que el agente no pueda modificar.
Controles de comportamiento vs controles de infraestructura
Una instrucción del sistema puede decir: “nunca accedas a producción”. Además, el harness puede solicitar una confirmación antes de ejecutar determinada herramienta.
Ambos mecanismos son útiles porque orientan al agente. Sin embargo, dependen de software y lógica que forman parte del mismo entorno donde opera el sistema.
Behavioral controls
- System prompts
- Instrucciones del agente
- Reglas dentro del harness
- LLM-as-a-judge
- Planificación consciente de políticas
Infrastructure controls
- Permisos del sistema operativo
- Sandbox de ejecución
- Políticas de red
- Gestión externa de credenciales
- Autorización y auditoría
Los primeros ayudan a prevenir comportamientos no deseados. Los segundos establecen límites técnicos sobre lo que realmente puede ocurrir incluso si el modelo toma una decisión incorrecta.
La frontera de seguridad debe existir antes de lanzar el agente
Un principio importante es que el entorno seguro debe existir desde el momento en que el agente comienza a ejecutarse. No debería ser una herramienta opcional que el propio agente decide utilizar después.
propone acción
decide si está permitida
ejecuta acción autorizada
Por ejemplo, si un agente intenta conectarse a un dominio externo, el runtime puede comprobar una política de red antes de permitir la conexión. Asimismo, una escritura en un archivo sensible puede detenerse aunque el modelo considere que la acción es necesaria.
Por qué el harness no debería ser la última barrera
El harness es una parte fundamental del agente porque controla herramientas, memoria, contexto y ciclo de ejecución. Precisamente por eso suele ser un lugar natural para incorporar reglas de comportamiento.
El problema aparece cuando ese mismo harness puede modificarse, extenderse mediante plugins o ejecutar código generado por el agente. Una capa diseñada para ser flexible no debería convertirse al mismo tiempo en la única frontera de seguridad.
Por ello, una arquitectura sólida combina reglas dentro del agente con controles independientes en runtime, red, identidad y sistemas externos.
Las credenciales no deberían estar disponibles directamente para el agente
Los secretos representan uno de los puntos más sensibles de cualquier agente que utilice APIs o sistemas empresariales.
Una práctica tradicional consiste en entregar API keys mediante variables de entorno. Sin embargo, un agente capaz de ejecutar código podría terminar leyendo esas variables y enviándolas a un destino no autorizado.
Enfoque de mayor riesgo
- API keys permanentes dentro del entorno
- Credenciales compartidas entre agentes
- Acceso más amplio de lo necesario
- Secretos accesibles desde shell
Enfoque recomendado
- Acceso temporal
- Permisos limitados por tarea
- Proxy externo para credenciales
- Revocación rápida
De este modo, el agente puede solicitar una acción autorizada sin necesitar conocer necesariamente la credencial real que permite ejecutarla.
Seis fallos comunes en la seguridad de agentes
Muchos problemas no aparecen porque el modelo sea malicioso. Surgen porque la arquitectura concede demasiado poder o no distingue claramente qué componente tiene autoridad.
Fronteras ambiguas
Las reglas están repartidas entre prompts, herramientas, harnesses y sistemas sin una fuente autoritativa clara.
Permisos excesivos
El agente recibe acceso permanente a recursos que solamente necesita durante una tarea puntual.
Datos convertidos en instrucciones
Documentos o resultados externos pueden influir en decisiones aunque no sean una fuente autorizada de comandos.
Efectos externos sin control
Una API permitida puede generar cambios con consecuencias mucho mayores de las previstas.
Errores que se propagan
Subagentes y herramientas pueden amplificar rápidamente una decisión incorrecta.
Auditoría incompleta
Sin registros claros resulta difícil explicar, revocar o recuperar después de un incidente.
Cinco principios para una seguridad que el agente no pueda saltarse
El agente propone; otra capa decide
Ningún modelo, tool, memoria o harness debería poder concederse autoridad adicional por su propia decisión.
Define una política autoritativa
Las reglas críticas deben aplicarse fuera del proceso controlado por el agente.
Comprueba cada efecto externo
Archivos, procesos, APIs, red, datos y recursos deberían pasar por un punto de autorización cuando puedan modificar estado.
Utiliza acceso justo a tiempo
Los permisos y credenciales deberían ser específicos, temporales y fáciles de retirar.
Diseña aislamiento y recuperación
Cada agente debe poder aislarse, detenerse y recuperarse sin comprometer el resto del sistema.
Cuatro perfiles de seguridad según el riesgo del agente
No todos los agentes necesitan las mismas restricciones. Un agente que experimenta con datos desechables no tiene el mismo riesgo que uno capaz de modificar infraestructura de producción.
Aislado
Adecuado para pruebas y desarrollo con datos desechables. No debería tener credenciales de producción y su red puede mantenerse fuertemente restringida.
Conectado
Puede utilizar servicios autorizados en preproducción, aunque conviene limitar identidad, consumo, acceso a datos y duración de las credenciales.
Producción
Cuando puede cambiar datos o sistemas reales, necesita permisos por tarea y controles adicionales para acciones de alto impacto.
Adversarial
Pruebas de modelos sin guardrails o red-team requieren aislamiento máximo, comunicaciones restringidas y capacidad rápida de cuarentena.
En consecuencia, el objetivo no consiste en aplicar siempre la máxima restricción. Consiste en ajustar autoridad y controles al impacto potencial de cada workload.
Arquitectura práctica para un agente empresarial seguro
Una empresa puede aplicar estos principios incluso sin utilizar exactamente las mismas herramientas de NVIDIA. Lo importante es conservar la separación de responsabilidades.
| Componente | Función | Control recomendado |
|---|---|---|
| Usuario | Solicita una tarea. | Autenticación e identidad. |
| Agente | Razona y propone acciones. | Sin autoridad para concederse permisos. |
| Harness | Administra herramientas, contexto y ejecución. | Reglas de comportamiento y validación. |
| Runtime | Ejecuta procesos del agente. | Sandbox, políticas e aislamiento. |
| Credential proxy | Gestiona secretos. | Credenciales temporales y fuera del alcance del agente. |
| Red | Conecta con servicios externos. | Default deny y allowlists específicas. |
| Auditoría | Registra acciones y decisiones. | Logs independientes e inmutables cuando sea posible. |
Qué cambia cuando el agente utiliza MCP y herramientas externas
Model Context Protocol puede ampliar enormemente la utilidad de un agente al conectarlo con CRMs, bases de datos, APIs y herramientas empresariales. Sin embargo, cada servidor también crea una nueva ruta hacia sistemas externos.
Por eso, permitir un servidor MCP no debería equivaler automáticamente a permitir cualquier acción disponible dentro de ese servidor. Conviene limitar herramientas, datos, recursos y permisos según el objetivo.
Además, los resultados provenientes de herramientas deben tratarse como datos potencialmente no confiables. El hecho de que una API devuelva texto no significa que ese texto deba adquirir autoridad sobre las políticas del agente.
Controlar la salida a Internet puede ser tan importante como controlar las tools
Un agente con acceso libre a red puede enviar información a destinos que no forman parte de la tarea original. Por eso, NVIDIA recomienda aplicar restricciones de egress fuera del control del modelo.
Modelo abierto
El agente puede conectarse a cualquier destino disponible desde su entorno de ejecución.
Default deny
Toda conexión se bloquea por defecto y únicamente se permiten destinos específicamente necesarios para la tarea.
En la práctica, una allowlist puede limitar el agente a dominios concretos, APIs internas o servicios previamente revisados. Así, una prompt injection tendría menos oportunidades de exfiltrar datos.
Checklist antes de poner un agente en producción
Autoridad y acceso
- Identidad separada para el agente
- Permisos mínimos por tarea
- Credenciales temporales
- Sin secretos permanentes accesibles desde shell
- Revocación inmediata disponible
Entorno
- Ejecución dentro de sandbox
- Filesystem restringido
- Red limitada mediante allowlists
- Procesos aislados
- Separación de producción y pruebas
Herramientas
- Tools revisadas individualmente
- Permisos MCP limitados
- Acciones destructivas protegidas
- Validación de datos externos
- Human approval cuando el impacto sea alto
Observabilidad
- Registro de acciones
- Historial de autorizaciones
- Monitoreo de comportamiento anómalo
- Capacidad de cuarentena
- Proceso de recuperación y rollback
Errores frecuentes al asegurar agentes autónomos
Confiar únicamente en el prompt
Las instrucciones ayudan al comportamiento, pero no crean una barrera técnica definitiva.
Entregar una API key maestra
Una sola credencial con acceso amplio incrementa innecesariamente el impacto de cualquier fallo.
Permitir Internet completo
Un egress sin restricciones amplía posibles rutas de fuga de información.
Mezclar pruebas y producción
Un agente experimental no debería compartir automáticamente datos o permisos con sistemas reales.
No registrar acciones
Sin evidencia resulta difícil explicar qué ocurrió o restaurar el sistema después de un incidente.
Dejar que el agente sea su propio guardia
La protección crítica debe ejecutarse fuera del proceso que intenta controlar.
Preguntas frecuentes sobre seguridad de agentes de IA
¿Un system prompt es suficiente para asegurar un agente?
No. Puede orientar el comportamiento, pero un límite crítico debería reforzarse con controles técnicos independientes del modelo.
¿Qué es el harness de un agente?
Es la capa que convierte un modelo en un sistema agentic mediante la gestión del ciclo de ejecución, herramientas, contexto y sesiones.
¿Qué es un secure runtime?
Es el entorno encargado de ejecutar el agente aplicando restricciones de aislamiento, identidad, permisos, credenciales y otras políticas.
¿Por qué las credenciales permanentes son peligrosas?
Porque un agente con capacidad para ejecutar código podría leerlas o utilizarlas fuera del contexto originalmente previsto.
¿MCP hace que un agente sea inseguro?
No necesariamente. El riesgo depende de los permisos y herramientas que exponga cada servidor y de cómo se controle su ejecución.
Más dudas antes de desplegar agentes autónomos
¿Qué significa least privilege?
Significa conceder solamente los permisos necesarios para completar la tarea actual y evitar autoridad adicional que no aporta valor.
¿Qué es just-in-time access?
Es un enfoque donde una capacidad o credencial se concede durante un periodo limitado y se elimina cuando deja de ser necesaria.
¿Debo permitir Internet a un agente?
Depende de su función. Cuando sea posible, conviene restringir la salida de red a servicios y destinos específicamente autorizados.
¿Las acciones importantes deberían necesitar aprobación humana?
En entornos de mayor riesgo, una revisión independiente antes de acciones de alto impacto puede reducir consecuencias de errores.
¿Qué es NVIDIA OpenShell?
NVIDIA lo presenta como un runtime orientado a ejecutar agentes con aislamiento y políticas aplicadas fuera del proceso del propio agente.
¿Se puede construir una arquitectura segura sin OpenShell?
Sí. Los principios pueden implementarse utilizando otros runtimes, sandboxes, proxies, sistemas de identidad y controles de infraestructura.
Conclusión: la seguridad debe estar debajo del agente, no solo dentro de él
A medida que los agentes ganan autonomía, resulta menos razonable depender únicamente de prompts o instrucciones para evitar acciones peligrosas.
La arquitectura propuesta por NVIDIA separa dos responsabilidades: el agente decide qué quiere intentar y una infraestructura independiente determina qué está realmente autorizado.
Además, conceptos tradicionales como mínimo privilegio, aislamiento, credenciales temporales, control de red y auditoría siguen siendo extremadamente útiles. La diferencia es que ahora deben aplicarse a procesos que pueden razonar, generar código y cambiar su estrategia durante la ejecución.
Para empresas de México y Latinoamérica que empiezan a conectar agentes con CRM, WhatsApp, APIs, bases de datos o sistemas internos, este diseño debería considerarse antes de otorgar autonomía real. Cuanto más capaz sea el agente, más importante será que su autoridad permanezca limitada por controles que él mismo no pueda modificar.
Fuentes oficiales
- NVIDIA Technical Blog — Where Security Fits in an AI Agent Stack
- NVIDIA Technical Blog — Four Ways to Deploy More Secure AI Agents
- NVIDIA Technical Blog — How to Govern Autonomous Agents in Enterprise AI Factories
- NVIDIA Technical Blog — Run Autonomous, Self-Evolving Agents More Safely with NVIDIA OpenShell
¿Quieres implementar agentes de IA conectados a tus sistemas?
En Zadrig Technology podemos ayudarte a diseñar agentes, automatizaciones, conexiones MCP y APIs con permisos, herramientas y procesos definidos para que la inteligencia artificial pueda ejecutar trabajo real dentro de tu empresa.
Diseñar mi agente de IA →
