Los agentes de IA pueden razonar, utilizar herramientas y adaptar sus acciones a los datos que encuentran. Esa flexibilidad cambia el problema de seguridad: proteger únicamente el modelo no basta. Las directrices de NVIDIA sitúan los controles en el código, los datos, las identidades, los servicios y la infraestructura que rodean al agente.
Define una identidad y un límite de tareas
Asigna a cada agente una identidad trazable y credenciales limitadas al trabajo que debe realizar. Antes del despliegue, define qué acciones puede ejecutar, qué registros puede actualizar, qué herramientas puede utilizar y a qué destinos puede llegar. El ejemplo de NVIDIA marca una diferencia importante: el permiso para actualizar el registro de un cliente no concede automáticamente permiso para exportar sus datos.
Las solicitudes de acceso adicional deben quedar fuera de la autoridad del propio agente. Puede pedir más permisos, pero no aprobar su solicitud. Las acciones con consecuencias y los cambios de permisos deben seguir sujetos a aprobación humana. El flujo incorpora así un punto de decisión adicional y evita que una identidad creada para una tarea se convierta en una credencial de uso general.
Separa el control de ejecución del razonamiento
El entorno de ejecución debe limitar de forma independiente los archivos, los destinos de red y los procesos. Esas restricciones tienen que mantenerse aunque el agente genere una instrucción insegura o siga contenido malicioso.
En el escenario descrito por NVIDIA, una instrucción maliciosa oculta en un documento adjunto lleva al agente a intentar exportar datos de clientes a un destino no autorizado. Una política de red debe bloquear la transferencia en el límite del entorno de ejecución. El agente no debería poder eludir la restricción cambiando su razonamiento ni solicitando una ruta más amplia.
NVIDIA presenta OpenShell como un entorno de ejecución seguro y de código abierto que aplica políticas fuera del alcance del agente y ofrece ejecución aislada. La misma fuente cita Cisco DefenseClaw para la gobernanza y JFrog para analizar y verificar las habilidades, además de controlar cuáles están disponibles.
Estos ejemplos cubren capas distintas de un mismo principio: el componente que decide una acción no debe poder reescribir el control que la limita. Si puede hacerlo, el límite deja de ser una barrera fiable para el despliegue.
Trata documentos, herramientas y habilidades como superficies de riesgo
Un documento adjunto no es solo contexto cuando el agente puede utilizar herramientas. También puede contener instrucciones que redirijan el flujo de trabajo hacia la exportación de datos u otra acción no autorizada. Mantén alineados el acceso a los datos, las herramientas y la red con la tarea declarada, y haz explícito cada permiso.
Aplica la misma disciplina a las habilidades y los flujos de trabajo. Analiza y verifica las habilidades antes de ponerlas a disposición de un agente, y limita el conjunto accesible a lo que exige la tarea. Cuantas menos rutas pueda activar una instrucción inesperada, menor será el alcance de un fallo.
El compromiso es una flexibilidad menor. Un agente estrictamente delimitado puede necesitar una decisión humana o un cambio en el flujo de trabajo cuando su tarea se amplíe de verdad. Esa interrupción es preferible a permitir que una instrucción nueva se convierta por sí sola en una autoridad más amplia.
Registra las decisiones que cambian el riesgo
Los registros protegidos deben conservar la llamada a la herramienta, la decisión de autorización y el resultado. Registrar únicamente el desenlace deja fuera el momento en que se puso a prueba o se cruzó un límite.
En el escenario del documento malicioso descrito por NVIDIA, los registros deberían mostrar la llamada a la herramienta que se intentó realizar, la autorización bloqueada y la acción resultante. Protégelos frente a modificaciones y asigna la responsabilidad de revisarlos. El objetivo no es guardar una transcripción por sí misma, sino poder responder a tres preguntas operativas: qué intentó hacer el agente, qué política lo permitió o bloqueó y qué ocurrió después.
Prueba los límites antes de producción
Antes del despliegue, comprueba si el agente puede obtener credenciales fuera de su alcance, enviar datos sensibles a un destino no autorizado, modificar permisos o interferir con la supervisión. Estas pruebas examinan la separación entre el razonamiento del agente y el sistema que lo contiene.
- Intenta obtener una credencial fuera del alcance y verifica que la solicitud se deniegue o se remita a aprobación humana.
- Proporciona una ruta hacia un destino de datos no autorizado y verifica que la política de red bloquee la transferencia.
- Intenta cambiar un permiso y confirma que el agente no pueda aprobarlo ni aplicarlo por sí mismo.
- Intenta alterar o eludir la supervisión y confirma que los registros protegidos sigan capturando la llamada, la decisión y el resultado.
Repite estas pruebas después de cambios importantes en el modelo, las herramientas o los flujos de trabajo. NVIDIA también pide designar a un responsable que decida si el agente puede entrar en producción y active la corrección cuando falle una protección. Superar una prueba anterior no demuestra que un agente modificado siga dentro del mismo límite de riesgo.
La gobernanza general no sustituye las pruebas concretas
IBM informó el 8 de junio de 2026 de que el 77 % de los 2.000 líderes tecnológicos encuestados afirmó que la adopción de la IA avanzaba más rápido que la capacidad de sus organizaciones para gobernarla. El mismo estudio señaló que el 59 % consideraba la seguridad y el cumplimiento obstáculos importantes para desplegar agentes, mientras que las organizaciones que integraron controles en sus sistemas registraron un 25 % menos de incidentes, según el informe de IBM.
Estas cifras describen la presión general sobre la gobernanza, pero no sustituyen las pruebas de los permisos y del entorno de ejecución de un agente concreto. IBM también anunció el 15 de abril de 2026 una evaluación de ciberseguridad destinada a descubrir brechas de seguridad, debilidades de las políticas, exposiciones específicas de la IA y vías de explotación. Su servicio IBM Autonomous Security se describe como un servicio multiagente que analiza exposiciones y entornos de ejecución, aplica políticas, detecta anomalías, contiene amenazas y alimenta los sistemas de gobernanza y riesgo.
Ese anuncio conecta los controles de los agentes con procesos de seguridad y gobernanza más amplios. La decisión de despliegue sigue dependiendo de los controles que rigen las acciones reales: identidad, entorno de ejecución, habilidades disponibles, puntos de aprobación e historial de auditoría.
Decide qué puede cambiar antes del lanzamiento
El agente puede adaptar sus acciones a nuevos datos, pero su identidad, sus credenciales, los límites de su entorno de ejecución, los puntos de aprobación y su historial de auditoría deben seguir siendo aplicables mientras cambian esas acciones. Si una tarea requiere un acceso más amplio, detén el proceso y revisa la política u obtén la aprobación humana necesaria; no permitas que el agente amplíe su propia autoridad.
Promueve el agente solo cuando sus límites bloqueen los casos de fallo definidos, sus registros conserven las pruebas y un responsable designado acepte el resultado. Cuando un modelo, una herramienta o un flujo de trabajo cambie de forma sustancial, vuelve a ejecutar las pruebas de límites antes de devolverlo a producción.