La adopción de agentes de IA en empresas avanza a toda velocidad, pero también lo hacen los ataques diseñados para manipularlos. En ese contexto, Zenity —plataforma de seguridad y gobernanza para agentes de IA— ha anunciado protección en tiempo de ejecución para OpenAI AgentKit, con un enfoque determinista y basado en políticas que inspecciona cada interacción antes de que la respuesta llegue al usuario y bloquea comportamientos de riesgo: exfiltración de datos, exposición de credenciales o respuestas que violen políticas internas o regulatorias.
El lanzamiento llega pocos días después de que Zenity Labs publicase investigaciones describiendo brechas en los guardarraíles de AgentKit susceptibles de ser sorteadas con prompt injection, ofuscación de respuestas o filtraciones accidentales de secretos. La propuesta de la compañía no intenta sustituir esos controles, sino cerrar el hueco que dejan las defensas probabilísticas introduciendo una capa de cumplimiento determinista en el endpoint, allí donde el agente ejecuta herramientas, consulta conectores o compone la respuesta final.
Qué aporta la protección en tiempo de ejecución de Zenity
La idea central es sencilla: no fiarlo todo al LLM y añadir un cortafuegos semántico que evalúe la intención y el comportamiento del agente en caliente, con reglas claras y auditables. En la práctica, la nueva capa de Zenity:
- Detecta y bloquea fugas de datos: frena intentos de exfiltración de información sensible o regulada (personal, financiera, sanitaria, propiedad intelectual), tanto en texto como en artefactos adjuntos.
- Previene la exposición de secretos: intercepta claves, tokens o credenciales que pudieran “colarse” en una respuesta o en una traza de depuración.
- Anula respuestas inseguras o no conformes: impide la entrega de salidas que vulneren políticas internas (seguridad, marca, uso aceptable) o normativas aplicables (protección de datos, sectoriales).
- Inspecciona cada interacción: observa el tráfico usuario↔agente, las llamadas a herramientas y el uso de conectores, y aplica reglas deterministas con resolución en tiempo real.
- Deja traza y permite auditoría: registra qué se bloqueó, por qué y con qué regla, facilitando forensia, afinado de políticas y cumplimiento.
El matiz clave está en el determinismo: a diferencia de los guardarraíles probabilísticos (propios del modelado), que pueden fallar ante inputs creativos o adversarios sofisticados, la capa de Zenity aplica reglas explícitas que no fluctúan con el contexto y garantizan un resultado predecible bajo las mismas condiciones.
Por qué hace falta un control “extramuros” del LLM
OpenAI AgentKit ha reducido de forma drástica la fricción para crear, desplegar y operar agentes: Agent Builder para diseñarlos, ChatKit para integrarlos como experiencias conversacionales y Connector Registry para darles acceso a datos y herramientas de terceros (desde Gmail o calendarios hasta CRMs, ERPs, pagos, etc.). Esa capilaridad acelera la innovación… y amplía la superficie de ataque.
Los guardarraíles nativos —evaluaciones, políticas de contenido, validaciones— son necesarios, pero no bastan en escenarios donde un agente ejecuta acciones o toca datos reales. Ahí empiezan vectores como:
- Prompt injection (explícito u “oculto” en datos externos) que fuerza al agente a ignorar instrucciones y revelar información o ejecutar acciones indebidas.
- Ofuscación de respuesta (cadenas codificadas, formatos ambiguos) para burlar filtros estadísticos.
- Exposición incidental de secretos en respuestas, logs o mensajes intermedios del agente.
Al elevar el control a la capa de ejecución —donde se ven las intenciones y se miden los efectos—, la protección en tiempo de ejecución añade un último cerrojo antes de que el contenido cruce la frontera hacia el usuario o hacia un sistema crítico.
Cómo encaja en equipos de seguridad, datos y MLOps
Para CISOs y responsables de seguridad de aplicaciones, el movimiento equivale a incorporar “WAF semántico” y DLP de nueva generación al plano de agentes: controles policy-as-code, listas de permitidos/denegados por tipo de dato, reglas de prevención de pérdida y telemetría para detección y respuesta. Para MLOps y plataformas, significa separar responsabilidades: el LLM sigue haciendo razonamiento y generación, mientras que la capa de seguridad aplica normas estables y audita.
Algunos beneficios operativos que las empresas suelen perseguir con este enfoque:
- Reducción del riesgo operativo: menos probabilidad de que un agente filtre datos sensibles o realice acciones fuera de política.
- Cumplimiento demostrable: posibilidad de enseñar a auditores y reguladores políticas vigentes, evidencias de bloqueo y métricas de eficacia.
- Tiempos de contención más bajos**:** detección y neutralización in-line, sin depender de revisiones posteriores o reportes de usuarios.
- Gobernanza unificada: políticas que se heredan a todos los agentes y entornos (SaaS, nubes propias, endpoints), reduciendo inconsistencias.
Un apunte de arquitectura: qué observa y qué decide
Aunque los detalles de implementación varían por entorno, la lógica suele seguir este flujo:
- Interceptación de eventos en el endpoint del agente (mensajes, llamadas a herramientas, salidas).
- Clasificación del contenido y evaluación de intención (¿hay solicitud de datos sensibles?, ¿intenta enviar secretos?, ¿la acción viola una política?).
- Reglas deterministas (policy-as-code) que permiten, enriquecen (p. ej., redactado de campos sensibles) o bloquean la acción.
- Registro estructurado (qué, cuándo, por qué) y alertas para SecOps o plataformas.
Este patrón complementa, no sustituye, las evals y guardarraíles del LLM. La diferencia es que se decide con políticas fijas y criterios auditables en el último tramo de la cadena.
Qué deberían preguntar los responsables antes de implantarlo
Para evitar falsas expectativas y asegurar encaje con el stack existente, conviene preparar una checklist:
- Cobertura y contexto: ¿qué tipos de datos reconoce (PII, financieros, sanitarios, IP)? ¿cómo detecta secretos en texto y adjuntos?
- Política y excepciones: ¿cómo se definen las políticas (YAML, UI, API)? ¿se permite “masking” selectivo en lugar de bloqueo total? ¿hay listas de permitidos por dominio, conector o acción?
- Latencia y rendimiento: ¿cuál es el coste de inspeccionar cada interacción? ¿hay caché de decisiones seguras?
- Trazabilidad y forensia: ¿qué logs se guardan? ¿se integran con SIEM/SOAR? ¿qué métricas ofrece (incidencias evitadas, falsos positivos, tiempo de respuesta)?
- Privacidad y residencia del dato: ¿dónde se procesan y persisten los eventos y reglas? ¿existen modos on-prem/air-gapped o controles de retención?
- Compatibilidad: ¿cómo se acopla a Agent Builder, ChatKit y Connector Registry? ¿qué conectores o herramientas requieren permisos adicionales?
El momento del mercado: de “probar agentes” a “protegerlos en producción”
La agentificación del software corporativo está entrando en su fase industrial: asistentes internos conectados a ERP/CRM, agentes que orquestan tickets, flujos de atención integrados en web y apps, y copilotos que escriben o actúan sobre datos de clientes. Cada paso hacia producción exige seguridad equivalente a la de cualquier otro sistema crítico.
El hecho de que una parte de los controles clásicos (validaciones, ACL, DLP) no “vea” bien las salidas generativas obliga a poner inteligencia defensiva en la capa donde realmente se materializa el riesgo: el runtime del agente. La apuesta de Zenity va, justamente, en esa dirección.
Disponibilidad, casos de uso y próximos pasos
La protección en tiempo de ejecución de Zenity se orienta a agentes construidos con OpenAI AgentKit y escenarios típicos de empresa:
- Asistentes internos con acceso a documentación y datos sensibles.
- Agentes de atención que escriben a clientes y operan sobre pedidos, pagos o devoluciones.
- Automatizaciones que invocan herramientas (calendarios, correo, repositorios, paneles de operación) y conectores de terceros.
El despliegue práctico suele empezar con un piloto acotado (un agente, un dominio de datos, un puñado de políticas prioritarias), midiendo falsos positivos, latencia añadida y incidentes evitados. A partir de ahí, se industrializa: plantillas de políticas, listas de permitidos, métricas de adopción y playbooks de respuesta.
Lectura estratégica: seguridad “centrada en el agente”
Más allá del titular, el movimiento refuerza una tesis que gana terreno en ciberseguridad: en el mundo de la IA, no basta con proteger usuarios, endpoints o APIs; hay que proteger agentes como sujetos operantes que leen, razonan, deciden y actúan. Eso implica descubrimiento de agentes, gestión de postura, políticas coherentes en todos los entornos y detención en tiempo real cuando algo cruza una línea roja.
La protección en runtime para AgentKit suma un ladrillo importante a esa arquitectura: convierte la intención y la salida del agente en superficie observable y controlable, del mismo modo que el sector hizo en su día con el tráfico web o las llamadas API. Si la agentificación es el nuevo motor del software, su seguridad tendrá que ser igual de sistémica.
Preguntas frecuentes (FAQ)
¿En qué se diferencia esta protección de los guardarraíles nativos de AgentKit?
Los guardarraíles del LLM y de AgentKit son probabilísticos y operan sobre prompts y respuestas en la capa de modelo. La protección de Zenity actúa después, en tiempo de ejecución, con reglas deterministas que permiten/bloquean acciones y redactan contenido antes de que llegue al usuario o a sistemas críticos.
¿Esto ralentiza las respuestas del agente?
Hay coste de inspección, pero la lógica es ligera y se puede optimizar con cachés y políticas por riesgo (p. ej., más estrictas cuando el agente invoca una herramienta sensible). El objetivo es mantener latencias aptas para producción sin perder control.
¿Qué pasa si una política bloquea una respuesta legítima (falso positivo)?
La capa deja traza con el motivo y permite ajustar reglas. En despliegues reales se recomienda un periodo inicial de “alert-only” para calibrar políticas, seguido de modo enforcement progresivo.
¿Se limita a agentes de OpenAI AgentKit?
El anuncio se centra en AgentKit. No obstante, la estrategia de Zenity es multi-entorno (SaaS, nubes propias, endpoints), con la misma filosofía de descubrimiento, postura, prevención y respuesta aplicada al ciclo de vida de agentes.
vía: zenity
