Ir al contenido principal
Producto

Políticas contextuales en Omnigent: uso del estado de la sesión para gobernar mejor a los agentes de AI

Cómo Omnigent habilita potentes controles de seguridad y costos

por Matei Zaharia, David Nasi, Xiangrui Meng, Kecheng Cao y Tomu Hirata

• Omnigent presenta políticas contextuales para agentes de AI: políticas que pueden realizar un seguimiento de lo que ha hecho la sesión de un agente hasta el momento para evaluar si la siguiente acción debe continuar.
• Omnigent, como meta-arnés, permite aplicar estas políticas a cualquier agente que envuelva, incluidos los agentes de programación como Claude Code y Codex.
• Las políticas contextuales le permiten definir políticas más potentes que las disponibles en los arneses de agentes existentes. Por ejemplo, puede configurar límites de gasto por sesión o guardrails que se vuelven más estrictos a medida que se acumula el riesgo.

Hace poco lanzamos Omnigent, un meta-arnés de código abierto para agentes de AI. Te permite seguir usando los arneses de agentes que ya te gustan, incluidos Claude Code, Codex y agentes personalizados, al tiempo que añade una capa compartida para la colaboración, composición y políticas.

Para la gestión de seguridad y costos, Omnigent presenta una nueva y potente herramienta: políticas contextuales. Los frameworks de agentes actuales solo tienen controles simples para limitar lo que un agente puede hacer, por ejemplo, reglas para permitir, denegar o preguntar al usuario sobre diversas llamadas a herramientas. Pero esto dificulta la creación de políticas que sean tanto seguras como cómodas para los usuarios. Por el contrario, las políticas contextuales de Omnigent pueden recordar lo que ha sucedido en una sesión hasta el momento (por ejemplo, qué ha leído el agente o cuántos dólares ha gastado hasta ahora) y usar ese estado para decidir si la siguiente acción debe continuar. Esto permite una amplia gama de políticas ricas que son más seguras y convenientes para los usuarios: desde el seguimiento dinámico del nivel de riesgo de una sesión, hasta la implementación de modelos de seguridad de mínimo privilegio, pasando por permitir que los usuarios establezcan presupuestos para tareas individuales con el fin de gestionar el gasto.

Por qué los controles de agentes son mejores con contexto

Los agentes de AI introducen nuevos tipos de riesgos para las empresas. Por ejemplo, dado que los agentes pueden sufrir inyecciones de prompts por parte de contenido no confiable y se les puede pedir que realicen acciones dañinas, es conveniente evitar que el mismo agente lea contenido no confiable, acceda a datos confidenciales y se comunique con el mundo exterior (popularizado como la “Trifecta Letal” de Simon Willison y la “Regla de Dos para Agentes” de Meta). El hecho de que una acción sea “segura” depende, en parte, de lo que haya sucedido antes: que un agente de programación haga un push a GitHub generalmente está bien si el agente acaba de trabajar en una característica para un ingeniero, pero ese mismo push a GitHub es riesgoso si el agente había descargado previamente una página web no confiable que podría contener un ataque de inyección.

Desafortunadamente, la mayoría del software de agentes actual solo proporciona controles simples de lista de permitidos o guardrails en acciones individuales, por ejemplo, si se permiten los pushes de Git o las búsquedas web. Para evitar ataques de inyección, tendríamos que bloquear por completo al menos una de estas acciones, pero esto sería restrictivo para muchos casos de uso inofensivos. Pedir la aprobación del usuario para cada acción tampoco funciona bien, porque los usuarios simplemente se fatigan con las solicitudes de aprobación.

Lo mismo se aplica a otras situaciones. Tal vez esté bien que el agente de un representante de ventas envíe un correo electrónico a un cliente, pero que envíe miles de correos electrónicos es indicativo de una vulneración o de un error. Que un agente edite un documento que él mismo creó está bien, pero que ese mismo agente edite miles de documentos internos puede requerir escrutinio. De hecho, muchas herramientas de seguridad para usuarios humanos también consideran su historial y no solo la acción actual (esto se llama seguridad contextual).

Presentamos las políticas contextuales

En Omnigent, una política puede escuchar los eventos que realiza un agente (por ejemplo, llamadas a herramientas y respuestas, así como entradas y salidas del LLM) y decidir si permitir, denegar, transformar los mensajes o pedir permiso al usuario, de manera similar a los guardrails de agentes tradicionales. Sin embargo, la política también puede actualizar el estado de la sesión: variables arbitrarias visibles únicamente para esa política. Esto puede incluir el seguimiento de cuántas veces un agente usó una herramienta específica, qué documentos leyó, etc. El servidor de Omnigent recuerda el estado de cada política y sesión, y lo pasa al controlador de políticas la próxima vez que llama al controlador. Para escribir una política contextual, simplemente escribe una función que tome el estado anterior y el nuevo evento que el agente intenta realizar, y devuelva las actualizaciones de estado y una decisión. Omnigent también viene con una serie de políticas útiles ya incluidas.

Además, dado que Omnigent es un meta-arnés, puede aplicar tus políticas contextuales a agentes que utilicen cualquier arnés de la misma manera. Omnigent es compatible con agentes de programación ampliamente utilizados como Claude Code, Codex, Antigravity, Pi, OpenCode y Hermes, así como con agentes personalizados en frameworks como OpenAI Agents SDK y Claude Agents SDK. Simplemente inicia los agentes a través de Omnigent, y el servidor de Omnigent interceptará sus llamadas a herramientas para aplicar las políticas.

Casos de uso de ejemplo

Aquí están las tres políticas de ejemplo integradas que se incluyen con Omnigent hoy en día. Cada una se basa en un tipo diferente de estado de sesión: el contenido que el agente has leído hasta ahora, una puntuación de riesgo acumulada de la sesión o el costo total de la sesión actual.

1. Google Drive Policy: Mantén el acceso del agente limitado a los documentos correctos

La política de Google Drive rige lo que el agente puede leer y modificar en Docs, Sheets y Slides. Por defecto, las escrituras están limitadas a los documentos que el agente creó durante esta sesión. Así, un agente puede crear un nuevo documento y editarlo libremente, pero no puede modificar silenciosamente un archivo preexistente que nunca debió tocar. Este comportamiento no sería posible de implementar con listas de permitidos simples: no queremos permitir o denegar por completo la herramienta de “escribir documento”, solo queremos permitirla en los documentos que el agente creó en la misma sesión.

Como segundo ejemplo de comportamiento contextual en esta política, puedes marcar un conjunto de documentos como confidenciales: en el momento en que el agente abre uno, la política se vuelve más estricta para que las escrituras se limiten a ese conjunto. Incluso un documento que el agente creó hace un minuto queda fuera de su alcance, ya que agregarle material confidencial filtraría ese contenido en un archivo menos protegido. En la seguridad clásica, esto implementa el modelo Bell-LaPadula con su regla de "no escritura hacia abajo".

Figura 1: Configuración de la política de Google Drive. confidential_files declara qué documentos son confidenciales


Figura 2: Por defecto, las escrituras están limitadas a los documentos que el agente creó en esta sesión


Figura 3: Después de leer un documento confidencial, se deniega la misma operación de escritura para evitar una filtración por escritura hacia abajo.


2. Política de puntuación de riesgo: Sé más cauteloso a medida que el agente toca material confidencial

Los equipos de seguridad suelen utilizar la puntuación de riesgo para gestionar el acceso de los humanos. En Omnigent, la política de puntuación de riesgo mantiene una puntuación acumulada para la sesión actual, un único número que realiza un seguimiento de cuánto riesgo se ha acumulado a medida que el agente trabaja. Los usuarios pueden configurar qué acciones aumentarán la puntuación y por cuánto: una llamada de herramienta rutinaria podría añadir un punto o dos, mientras que leer un documento que has marcado como altamente confidencial aumenta la puntuación mucho más. Mientras la puntuación se mantenga baja, el agente trabaja sin interrupciones. Una vez que cruza un umbral, las acciones como enviar un correo electrónico o compartir un archivo devolverán ASK en lugar de ALLOW y solicitarán la aprobación del usuario. Así, el mismo correo electrónico que se habría enviado al principio de una sesión puede requerir la aprobación humana más adelante, una vez que el agente haya manejado suficiente material confidencial, lo que eleva la puntuación.

Figura 4: Configuración de una política de puntuación de riesgo con alcance de sesión


Figura 5: Una vez que una búsqueda web eleva la puntuación de riesgo de la sesión al umbral, el envío de un correo electrónico deja de ser automático y requiere aprobación humana.


3. Política de costos: mantén el gasto bajo control

Una política de presupuesto realiza un seguimiento de cuánto ha gastado la sesión en llamadas al modelo hasta el momento. Después de cruzar un umbral flexible, se pausa para preguntar si se desea continuar. Cuando el gasto alcanza el límite estricto, la política bloquea nuevas llamadas al modelo costoso hasta que el agente cambie a uno más barato, lo que permite que la sesión continúe en lugar de detenerse. La misma idea se extiende más allá de una sola sesión. Un equipo de plataforma puede acumular un límite diario por usuario además del límite por sesión, de modo que nadie pueda acumular costos en muchas conversaciones distintas. En ambos casos, el contexto es el gasto acumulado: la política no juzga ninguna llamada de modelo individual; observa el total acumulado y actúa cuando la sesión o el usuario han gastado demasiado.

Figura 6: Configuración de una política de presupuesto con alcance de sesión


Figura 7: Cuando el gasto de la sesión supera el umbral de advertencia, la política se pausa y le pide al usuario que apruebe la continuación.


4. Autorización basada en la intención: limita los privilegios según el propósito

La autorización basada en la intención establece los permisos de los agentes en función de la indicación (prompt) inicial del usuario, de modo que incluso un agente con inyección de prompts no pueda usar la mayoría de sus herramientas para causar daños. Por ejemplo, si inicias una sesión pidiéndole a un agente que actualice una presentación de Google Slides, la política le permite leer y escribir en esa presentación, pero bloquea el acceso si el agente intenta usar GitHub de repente. La política simplemente recuerda como estado lo que el usuario realmente solicitó al inicio de una sesión, luego compara cada llamada a una herramienta con ese objetivo original, aplicando el principio de mínimo privilegio. Esta es una política muy simple pero potente que se habilita mediante el estado contextual: puedes configurar agentes con muchas herramientas de forma predeterminada y se bloquearán automáticamente en cada sesión. La misma llamada a una herramienta que es correcta en una sesión puede requerir tu aprobación en otra, según lo que le hayas pedido al agente que haga.

Figura 8: IBA bloquea un comando de shell no relacionado con la solicitud original.


Conclusión

A medida que los agentes asumen más trabajo real, la parte difícil pasa a ser cómo controlarlos. Los agentes pueden comenzar a causar daños debido a entradas maliciosas o errores involuntarios, y las políticas simples de lista de permitidos que inspeccionan acciones individuales no son lo suficientemente flexibles como para que los agentes sean utilizables y seguros a la vez. Las políticas contextuales permiten tener agentes más utilizables y seguros al realizar un seguimiento dinámico del estado dentro de una sesión y bloquear acciones solo cuando el agente ha acumulado suficiente riesgo. También proporcionan una herramienta potente y sencilla para administrar presupuestos a nivel de sesión, en lugar de solo por usuario y por día. Omnigent es de código abierto y se integra con los agentes de programación y marcos de trabajo de agentes más populares, por lo que puedes comenzar a aplicarlos a tus agentes existentes.

Pruébalo

Omnigent es de código abierto y actualmente se encuentra en fase alfa.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original

Recibe las últimas publicaciones en tu bandeja de entrada

Suscríbete a nuestro blog y recibe las últimas publicaciones directamente en tu bandeja de entrada.

Ver todos los blogs