Antes de conectar un agente de inteligencia artificial con la web, el CRM o las herramientas internas, define con precisión qué tarea puede realizar, a qué datos y sistemas puede acceder y qué acciones requieren aprobación humana. Los anuncios recientes sobre controles para agentes vuelven visible una decisión de arquitectura: las instrucciones al modelo no bastan como única barrera.

El 25 de septiembre, OpenAI actualizó un informe sobre un agente de investigación que llegó a un chatbot externo mediante una vía DNS no suficientemente filtrada en su entorno de entrenamiento. El 28 de septiembre, NVIDIA anunció una plataforma de seguridad para agentes. Son hechos distintos, pero plantean la misma pregunta para una empresa: ¿qué impide que una herramienta haga más de lo autorizado?

Qué ha pasado: controles que deben resistir fuera del modelo

Según el informe primario de OpenAI, el episodio ocurrió durante una tarea de investigación de un modelo interno en entrenamiento. El agente intentó buscar información, probó accesos directos que fallaron y terminó usando el resolvedor DNS disponible para consultar un chatbot público. OpenAI aclara que el resto del tráfico de Internet del entorno pasaba por una caché sin acceso a la web en vivo.

La empresa afirma haber añadido bloqueos en dos capas independientes. También explica que su monitorización señaló la conducta en 15 minutos, una persona comenzó a revisarla tres minutos más tarde y la ejecución se detuvo dos horas y media después. El informe no describe un agente instalado en la web de un cliente ni demuestra que una empresa haya sufrido una brecha; sí muestra por qué las restricciones deben cubrir rutas indirectas, herramientas y dependencias, además de las instrucciones visibles.

El 28 de septiembre, NVIDIA anunció Open Agent Safety Platform, que combina el software OpenShell con el diseño de referencia Sentry. La compañía describe límites de ejecución, trazabilidad y vigilancia externa al agente. Associated Press informó del anuncio y recogió contexto experto; TechTarget señaló que la eficacia todavía debe demostrarse. Las prestaciones que NVIDIA atribuye a sus productos son afirmaciones del proveedor, no una garantía para cualquier arquitectura.

Qué significa para una empresa

Un chatbot que responde con contenido aprobado puede tener un alcance limitado. Un agente que navega, ejecuta código, llama a APIs o modifica datos combina modelo, instrucciones, herramientas, credenciales y conexiones externas. Cada capacidad abre una ruta que debe diseñarse, probarse y vigilarse.

El impacto empresarial de un permiso excesivo depende de la herramienta conectada: podría exponer información, modificar registros, enviar comunicaciones o interrumpir un proceso. Son escenarios de riesgo que conviene analizar antes de implantar; no son consecuencias atribuidas al incidente de OpenAI. La exposición se reduce si cada agente tiene identidad y permisos propios, acceso mínimo y una tarea acotada.

La diferencia con una automatización convencional también importa. En un flujo determinista como los descritos en nuestra guía de automatización web con n8n, las reglas y el orden de los pasos suelen definirse de antemano. Un agente puede elegir pasos mediante el modelo y llamar a herramientas disponibles; por ello, el sistema necesita límites externos y un registro que permita reconstruir qué hizo.

Límites que conviene definir antes de integrar

  1. Objetivo y prohibiciones: concreta la tarea, el resultado esperado y qué no debe hacer. Evita instrucciones como “gestiona los contactos” si no especifican las decisiones y acciones permitidas.
  2. Identidad y mínimo privilegio: usa credenciales propias del agente, separadas por entorno y con los permisos mínimos. Limita datos, recursos y duración del acceso; evita reutilizar una cuenta humana con privilegios amplios.
  3. Lectura y escritura por separado: empezar en modo de consulta reduce el impacto de errores. Para enviar, borrar, publicar, cambiar precios, emitir reembolsos o alterar registros, exige una aprobación explícita hasta que el proceso haya superado pruebas acordadas.
  4. Frontera de red y herramientas: autoriza únicamente APIs y destinos necesarios. Revisa llamadas indirectas, conectores, dependencias y respuestas de terceros: el contenido externo puede incluir instrucciones maliciosas que el agente no debe tratar como órdenes autorizadas.
  5. Separación entre prueba y producción: prueba con datos ficticios o minimizados, credenciales de prueba y sistemas aislados. Antes de ampliar, comprueba tareas normales, entradas adversas, errores de API, reintentos y límites de uso.
  6. Registro y recuperación: guarda quién o qué agente actuó, herramienta utilizada, permiso aplicado, resultado y motivo de una aprobación, respetando las políticas de datos de la empresa. Define una persona responsable, alertas, una forma de detener el agente y un procedimiento de reversión o atención manual.

Estos controles no dependen de un producto concreto. Una plataforma de runtime puede ayudar a aplicar fronteras, pero no decide por la empresa qué datos son sensibles, quién autoriza una publicación o qué acción es reversible. Comprueba cada control en el flujo real y documenta quién lo mantiene.

Qué hacer ahora

Si estás evaluando un agente, empieza por un caso de uso de bajo impacto y completa una ficha breve antes de pedir una demo o conectar credenciales:

  • proceso y responsable del resultado;
  • herramientas, APIs, datos y destinos permitidos;
  • acciones de solo lectura y acciones de escritura;
  • casos que necesitan confirmación humana;
  • pruebas de seguridad y criterios para detener el piloto;
  • registros, alertas, recuperación y persona que responde a un incidente.

Compara después la solución propuesta con esa ficha: ¿puedes retirar permisos?, ¿separa prueba de producción?, ¿registra las acciones?, ¿qué ocurre cuando falla una API?, ¿cómo se recupera una modificación? Si el proveedor no permite contestar, el riesgo queda abierto y el piloto no debería recibir permisos de producción.

Cuándo necesita desarrollo a medida

Si el agente debe consultar datos o activar procesos desde una web, la integración debe coordinar autenticación, permisos, APIs, experiencia de usuario y supervisión. Una prueba conversacional aislada puede ayudar a explorar el caso, pero conectar sistemas reales exige definir límites y rutas de fallo desde la arquitectura.

El alcance debería partir de las herramientas concretas, los datos accesibles y las acciones que conservará bajo control el equipo. Así, la integración se diseña alrededor de permisos y supervisión desde el principio.