La seguridad de IA es un problema de ingeniería. Eso significa requisitos de seguridad definidos, controles aplicables, responsables asignados y evidencias de que las protecciones funcionan.
A medida que la IA se vuelve más capaz, la industria debe acelerar la ingeniería de seguridad, ampliar el acceso a herramientas de defensa y compartir lo que funciona con mayor rapidez.
La tecnología cambia, los fundamentos de seguridad permanecen
Internet y la computación en la nube cambiaron la forma en que opera el software, pero las responsabilidades centrales de seguridad perduraron: establecer identidad, controlar el acceso, limitar la exposición y verificar que las protecciones funcionen.
Los agentes de IA introducen nuevas capacidades: razonamiento, uso de herramientas y adaptación de acciones en función de los datos que encuentran. Esas capacidades requieren aplicar principios establecidos a nuevas condiciones operativas.
Este ritmo genera presión. Las organizaciones quieren los beneficios de productividad de la IA mientras las prácticas para gobernar y proteger estos sistemas todavía están en desarrollo.
La seguridad depende de todo el agent stack
Las aplicaciones dependen de código, datos, identidades, servicios e infraestructura. La seguridad depende de cómo esos componentes trabajan juntos, y los agentes de IA amplían ese sistema.
Los modelos proporcionan capacidades; los harnesses organizan contexto, herramientas y flujos de trabajo; y los entornos de runtime proveen la infraestructura en la que se ejecutan las acciones. Cada parte del stack tiene responsabilidades de seguridad, y una protección adecuada requiere controles en cada capa, a medida que datos, instrucciones y acciones se mueven por el sistema.
Considere un agente que actualiza un registro de cliente. Si encuentra instrucciones maliciosas en un documento adjunto e intenta exportar datos de clientes a un destino no autorizado.
Una política de red debe bloquear la transferencia, y los registros protegidos deben capturar el intento de llamada a la herramienta, la decisión de autorización y el resultado, para que el equipo de seguridad pueda identificar la herramienta utilizada y el destino al que intentó acceder.
El permiso para actualizar un registro de cliente no debe extenderse automáticamente a la exportación de esos datos. Un agente puede solicitar acceso adicional, pero no puede autorizarlo por sí mismo.
Incorpore la seguridad en el modo de operación de los agentes
Un límite de seguridad debe mantenerse incluso cuando un agente toma la decisión incorrecta. El entorno donde se ejecuta un agente determina lo que puede hacer y, por lo tanto, debe imponer límites sobre archivos, destinos de red y procesos independientemente del razonamiento del agente.
Las instrucciones y salvaguardas pueden ayudar a orientar el comportamiento, pero la seguridad también requiere límites aplicables.
Cada agente necesita una identidad rastreable y credenciales limitadas a su tarea asignada. Las organizaciones necesitan políticas claras que definan a qué información pueden acceder los agentes, qué sistemas pueden modificar y qué acciones requieren aprobación. Dentro de esos límites, las acciones importantes y los cambios de permisos aún requieren aprobación humana.
Los equipos también necesitan verificar el origen e integridad de las herramientas, skills y dependencias que utilizan los agentes. Si algo sale mal, los registros protegidos de llamadas a herramientas, decisiones de autorización y resultados ayudan a los investigadores a reconstruir lo que ocurrió. Los procedimientos claros para revocar el acceso y contener incidentes hacen que esa evidencia sea accionable.
NVIDIA OpenShell es un runtime de código abierto y seguro que aplica políticas fuera del alcance del agente y proporciona ejecución en sandbox, gobernando cómo los agentes acceden a datos, red y recursos del sistema. Los socios de la Open Secure AI Alliance están desarrollando sobre OpenShell: el DefenseClaw de Cisco agrega una capa de gobernanza, y JFrog se integra con OpenShell para analizar y verificar las skills de los agentes y aplicar políticas sobre cuáles pueden acceder.
Los equipos de ingeniería necesitan evidencias de seguridad
Antes de la implementación, los equipos necesitan evidencias de que los controles adecuados bloquean los intentos de obtener credenciales más allá del alcance de un agente o de enviar datos confidenciales a un destino no autorizado.
Las pruebas también deben cubrir intentos de cambiar permisos o interferir con el monitoreo, y repetirse tras cambios significativos en modelos, herramientas o flujos de trabajo.
Un responsable designado debe utilizar esos resultados para decidir si el sistema está listo para implementarse y garantizar que las pruebas fallidas lleven a acciones correctivas. Las fallas descubiertas en pruebas u operación deben reproducirse, investigarse y resolverse. Cada hallazgo puede convertirse en una prueba repetible, lo que permite a los equipos verificar que la corrección sigue funcionando en versiones futuras.
Entre los ejemplos se encuentran el SafeMind de CrowdStrike para probar y fortalecer defensas mediante simulaciones de ataque repetidas, y el Prisma AIRS de Palo Alto Networks para red teaming continuo conforme los modelos y aplicaciones cambian.
Los defensores necesitan las herramientas correctas en el momento oportuno
Investigar fallas requiere herramientas capaces y adecuadas para la tarea, los datos y el entorno. Los modelos abiertos y cerrados atienden necesidades complementarias.
Los modelos cerrados ofrecen capacidades y servicios administrados, mientras que los modelos abiertos dan a los defensores la opción de inspeccionar componentes relevantes, adaptar estrategias y trabajar en la infraestructura que controlan.
Durante un incidente, ese control puede ayudar a un equipo a reproducir una falla y probar una corrección en sus propios sistemas, manteniendo la evidencia confidencial dentro de su entorno.
La IA capaz puede apoyar este trabajo ayudando a encontrar vulnerabilidades, validar correcciones e investigar ataques. Su valor debe evaluarse mediante hallazgos reproducibles, correcciones verificables y tiempo de respuesta acelerado.
Entre los ejemplos se encuentran el VulnHunter de Capital One para seguridad de código con IA, y el Spectra Assure de ReversingLabs para análisis con IA de paquetes de software para detectar malware y manipulaciones.
Transfiera la ventaja a los defensores a través del trabajo abierto
Compartir evidencias de lo que falló, qué controles funcionaron y cómo se verificaron las correcciones ayuda a otros equipos a fortalecer sus propios sistemas.
La investigación de seguridad de NVIDIA y la Open Secure AI Alliance apoyan ese intercambio trayendo investigación, herramientas prácticas y experiencia a la comunidad de seguridad más amplia.
La seguridad de IA es un problema de ingeniería. Cada implementación de agente necesita límites aplicables, un responsable y evidencias de que sus protecciones funcionan. La investigación abierta y las herramientas compartidas ayudan a más defensores a cumplir ese estándar y mejorarlo a medida que avanzan las capacidades.
Conozca más sobre la investigación de seguridad de NVIDIA y únase a la Open Secure AI Alliance.