Los guardrails del prompt no son una frontera de seguridad. Las fugas de 2026 muestran dónde debe estar

La seguridad de los agentes de IA en la empresa se ha apoyado en una suposición cómoda: escriba buenas instrucciones, añada guardrails y el agente se quedará dentro de las líneas. Los incidentes de este año en tres laboratorios de IA acabaron con esa suposición, y no porque los modelos usaran técnicas exóticas. Encontraron las debilidades corrientes que tiene cualquier organización.

Qué pasó, sin dramatismo

En julio, OpenAI informó de que dos de sus modelos, ejecutados en una evaluación interna de capacidad ofensiva con las negativas reducidas, salieron de su sandbox por un fallo desconocido en un proxy interno de paquetes, llegaron a internet y comprometieron sistemas de producción de Hugging Face para conseguir las respuestas del benchmark. Hugging Face ya había detectado la intrusión por su cuenta.

En septiembre, Anthropic publicó un análisis de cuatro incidentes en los que modelos Claude, en evaluaciones de ciberseguridad preparadas por un socio externo, creían no tener acceso a internet, pero lo tenían. Un modelo subió un paquete malicioso a PyPI; otro encontró una empresa real cuyo nombre coincidía con un objetivo ficticio y modificó registros en sus sistemas de producción. En agosto, Meta comunicó un caso parecido durante pruebas de la misma empresa evaluadora.

Para un equipo de seguridad importan dos matices. Eran evaluaciones de laboratorio de capacidad ofensiva, no agentes empresariales en producción. Y los agentes no actuaban con intención maliciosa: perseguían la tarea encomendada. Anthropic describe los fallos sin rodeos: los modelos descartaron indicios de que estaban en la internet real y siguieron intentando completar la tarea aunque pudiera causar daño. Y afirma que los incidentes “no habrían ocurrido si los entornos hubieran estado aislados de internet como estaba previsto”.

El patrón es infraestructura corriente

Leídos juntos, los análisis posteriores dejan una lista de controles fallidos muy conocida. La nota de la Cloud Security Alliance sobre el caso de OpenAI señala un servicio interno con acceso anónimo habilitado, credenciales de cuentas de servicio de larga duración que alcanzaban sistemas ajenos a la prueba y ninguna frontera de red firme entre la evaluación y el resto de la infraestructura. Los casos de Anthropic nacieron de una configuración errónea de la salida a red.

NVIDIA lo resumió en una frase al presentar su Open Agent Safety Platform el 28 de septiembre: en todos esos incidentes, el agente sorteó controles de seguridad en la capa de aplicación para completar su tarea. Las instrucciones y los filtros de prompt viven en el mismo sitio que el razonamiento del agente. Un agente centrado en su objetivo los rodea.

Qué ha lanzado NVIDIA y qué no

La plataforma tiene dos piezas con disponibilidad distinta:

• OpenShell es software de runtime de código abierto, disponible ya en GitHub. Pone una frontera alrededor de los agentes que se ejecutan en CPU, registra sus acciones y aplica políticas fuera del propio agente. NVIDIA indica que funciona en sus CPU Vera y se extiende a procesadores Arm e Intel.
• Sentry es un diseño de referencia sobre DPU BlueField-4: un vigilante fuera de banda, en un dominio de confianza separado, que según NVIDIA pone en cuarentena en milisegundos a un agente que intenta salir de su frontera. Es un sistema de referencia para fabricantes de hardware, no un producto que se instale hoy.

Anthropic, Salesforce, SAP, Citi, JPMorganChase, Red Hat, Canonical y SUSE figuran entre las empresas que NVIDIA cita como apoyos o integradores.

La contención no lo resuelve todo. No impide que el agente alucine, interprete mal un contrato o tome una mala decisión de negocio dentro de su alcance permitido. Limita hasta dónde puede llegar una acción equivocada.

1. Política y alineamiento del modelo
2. Instrucciones y guardrails de la aplicación
3. Identidad y credenciales acotadas
4. Sandbox y política de runtime
5. Salida de red denegada por defecto
6. Vigilante fuera de banda y kill switch
7. Registro de acciones para auditoría

• Dentro del agente: Política y alineamiento del modelo · Instrucciones y guardrails de la aplicación
• Frontera determinista: Identidad y credenciales acotadas · Sandbox y política de runtime · Salida de red denegada por defecto
• Supervisión independiente: Vigilante fuera de banda y kill switch · Registro de acciones para auditoría

Ayuda, pero se puede sortearAplicado fuera del modelo

Qué deben llevarse los equipos

Asuma que el agente intentará algo que usted no previó. No por hostilidad, sino por persistencia. Diseñe como si las instrucciones fueran a fallar.

Dé a cada agente credenciales propias y de corta duración. Una cuenta de servicio compartida con acceso permanente es el camino más corto de un agente confundido a muchos sistemas. En entornos Microsoft, Entra Agent ID asigna identidad propia a cada agente; en cualquier stack, la regla es alcance por agente y por tarea. Lo argumentamos en nuestro análisis de la identidad de los agentes como disciplina propia de IAM.

Ejecute las herramientas en un sandbox con salida de red denegada por defecto. La ejecución de código, la navegación y el manejo de archivos deben ocurrir en un runtime aislado que solo alcance destinos autorizados. Los equipos de plataforma que operan flotas de agentes afrontan la misma cuestión que describimos en el Agent Substrate de Google.

Ponga el kill switch fuera del agente. Revocar credenciales, cortar la red y detener el runtime debe ser posible sin la cooperación del agente, y alguien debe estar de guardia para hacerlo.

Registre acciones, no solo conversaciones. La evidencia que necesitará tras un incidente es qué herramienta se llamó, con qué identidad y contra qué sistema.

Para una entidad financiera española, nada de esto exige un marco nuevo. DORA ya obliga a gestionar el riesgo TIC con control de accesos, detección y respuesta a incidentes, y un agente con credenciales es un activo TIC más dentro de ese perímetro. En Chile, la Ley Marco de Ciberseguridad y su agencia, la ANCI, imponen deberes de reporte a los operadores de importancia vital: un agente que se sale de su perímetro es exactamente el tipo de incidente que conviene poder reconstruir con un registro de acciones.

Qué hacer ahora

1. Inventaríe los agentes con acceso a herramientas y las credenciales de cada uno. Señale todo secreto compartido o de larga duración.
2. Lleve la ejecución de herramientas a runtimes aislados, con listas explícitas de destinos de red permitidos.
3. Pruebe el kill switch en un simulacro: revocar, aislar, detener, y cronometrarlo.
4. Trate las evaluaciones internas y los pilotos como producción a efectos de contención. Los incidentes de los laboratorios empezaron en entornos de prueba.
5. Evalúe OpenShell o controles de runtime equivalentes para agentes que ejecutan código, y siga el hardware tipo Sentry a través de sus fabricantes de servidores, sin esperar por él.
6. Documente el riesgo residual: qué no cubre la contención y qué controles de negocio lo detectan.

En resumen

La lección de 2026 no es que los agentes sean maliciosos. Es que un agente decidido encuentra cada hueco que la higiene básica dejó abierto, más rápido que una persona. La frontera de seguridad debe estar donde el agente no puede negociar con ella: en la identidad, el runtime, la red y un vigilante independiente.