Políticas Contextuais no Omnigent: Usando o estado da sessão para governar melhor os agentes de IA

Recentemente lançamos Omnigent, um meta-harness de código aberto para agentes de AI. Ele permite que você continue usando os harnesses de agentes que já gosta, incluindo Claude Code, Codex e agentes personalizados, enquanto adiciona uma camada compartilhada para colaboração, composição e políticas.

Para segurança e gerenciamento de custos, o Omnigent apresenta uma nova e poderosa ferramenta: políticas contextuais. Os frameworks de agentes atuais possuem apenas controles simples para limitar o que um agente pode fazer, por exemplo, regras para permitir, negar ou solicitar permissão ao usuário para várias chamadas de ferramentas. Mas isso dificulta a criação de políticas que sejam ao mesmo tempo seguras e convenientes para os usuários. Em contrapartida, as políticas contextuais do Omnigent conseguem lembrar o que aconteceu em uma sessão até o momento (por exemplo, o que o agente leu ou quantos dólares gastou até agora) e usar esse estado para decidir se a próxima ação deve prosseguir. Isso possibilita uma ampla variedade de políticas ricas que são mais seguras e convenientes para os usuários: desde o monitoramento dinâmico do nível de risco de uma sessão até a implementação de modelos de segurança de menor privilégio, passando pela definição de orçamentos para tarefas individuais para gerenciar gastos.

Por que os controles de agentes são melhores com contexto

Agentes de AI introduzem novos tipos de riscos para as empresas. Por exemplo, como os agentes podem sofrer injeção de prompt por conteúdo não confiável e ser solicitados a realizar ações prejudiciais, é recomendável evitar que o mesmo agente leia conteúdo não confiável, acesse dados confidenciais e se comunique com o mundo externo (popularizado como a “Tríade Letal” de Simon Willison e a “Regra de Dois para Agentes” da Meta). Se uma ação é “segura” depende, em parte, do que aconteceu antes: um agente de programação fazendo push para o GitHub geralmente não tem problema se ele acabou de trabalhar em um recurso para um engenheiro, mas o mesmo push para o GitHub é arriscado se o agente tiver baixado anteriormente uma página web não confiável que possa conter um ataque de injeção.

Infelizmente, a maioria dos softwares de agentes hoje oferece apenas controles simples de lista de permissões (allow-list) ou proteções (guardrails) em ações individuais, por exemplo, se deve permitir pushes do Git ou pesquisas na web. Para evitar ataques de injeção, teríamos que bloquear completamente pelo menos uma dessas ações, mas isso seria restritivo para muitos casos de uso inofensivos. Pedir a aprovação do usuário para cada ação também não funciona bem, pois os usuários simplesmente ficam cansados de tantas solicitações de aprovação.

O mesmo se aplica a outras situações. Talvez permitir que o agente de um representante de vendas envie um e-mail para um cliente seja normal, mas fazê-lo enviar milhares de e-mails é indício de uma invasão ou de um bug. Um agente editar um documento que ele mesmo criou é aceitável, mas o mesmo agente editar milhares de documentos internos pode exigir uma análise minuciosa. De fato, muitas ferramentas de segurança para usuários humanos também consideram seu histórico e não apenas a ação atual (isso é chamado de segurança contextual).

Entram em cena as políticas contextuais

No Omnigent, uma política pode monitorar eventos que um agente está realizando (por exemplo, chamadas e respostas de ferramentas, além de entradas e saídas do LLM) e decidir se deve permitir, negar, transformar as mensagens ou pedir permissão ao usuário, de forma semelhante às proteções (guardrails) tradicionais de agentes. No entanto, a política também pode atualizar o estado da sessão: variáveis arbitrárias visíveis apenas para essa política. Isso pode incluir o rastreamento de quantas vezes um agente usou uma ferramenta específica, quais documentos ele leu, etc. O servidor do Omnigent lembra o estado de cada política e sessão e o repassa para o manipulador de políticas na próxima vez que chamá-lo. Para escrever uma política contextual, basta criar uma função que receba o estado antigo e o novo evento que o agente está tentando realizar, e retorne as atualizações de estado e uma decisão. O Omnigent também já vem com várias políticas úteis incluídas.

Além disso, como o Omnigent é um meta-harness, ele pode aplicar suas políticas contextuais a agentes que usam qualquer harness da mesma maneira. O Omnigent oferece suporte a agentes de programação amplamente utilizados, como Claude Code, Codex, Antigravity, Pi, OpenCode e Hermes, bem como a agentes personalizados em frameworks como OpenAI Agents SDK e Claude Agents SDK. Basta iniciar os agentes por meio do Omnigent, e o servidor do Omnigent interceptará suas chamadas de ferramentas para aplicar as políticas.

Exemplos de casos de uso

Aqui estão as três políticas de exemplo integradas que acompanham o Omnigent hoje. Cada uma delas depende de um tipo diferente de estado de sessão: o conteúdo que o agente leu até o momento, uma pontuação de risco acumulada da sessão ou o custo total da sessão atual.

1. Política do Google Drive: mantenha o acesso do agente limitado aos documentos corretos

A política do Google Drive gerencia o que o agente pode ler e modificar no Docs, Sheets e Slides. Por padrão, as operações de escrita são limitadas aos documentos que o agente criou durante esta sessão. Assim, um agente pode criar um novo documento e editá-lo livremente, mas não pode modificar silenciosamente um arquivo preexistente que ele não deveria acessar. Esse comportamento não seria possível de implementar com listas de permissões simples: não queremos permitir ou negar categoricamente a ferramenta “write document”, queremos apenas permiti-la em documentos que o agente criou na mesma sessão.

Como um segundo exemplo de comportamento contextual nessa política, você pode marcar um conjunto de documentos como confidenciais: no momento em que o agente abre um deles, a política se torna mais rígida para que as operações de escrita fiquem limitadas a esse conjunto. Até mesmo um documento que o agente criou um minuto atrás torna-se inacessível, pois anexar material confidencial a ele vazaria esse conteúdo para um arquivo menos protegido. Na segurança clássica, isso implementa o modelo Bell-LaPadula com sua regra "no write-down".

2. Política de pontuação de risco: torne-se mais cauteloso à medida que o agente manipula material confidencial

A pontuação de risco é comumente usada por equipes de segurança para gerenciar o acesso de humanos. No Omnigent, a política de pontuação de risco mantém uma pontuação contínua para a sessão atual, um único número que acompanha o nível de risco acumulado à medida que o agente trabalha. Os usuários podem configurar quais ações aumentarão a pontuação e em quanto: uma chamada de ferramenta rotineira pode adicionar um ou dois pontos, enquanto a leitura de um documento marcado como altamente confidencial adiciona muito mais pontos. Enquanto a pontuação permanecer baixa, o agente trabalha sem interrupções. Assim que ela ultrapassar um limite, ações como enviar um e-mail ou compartilhar um arquivo retornarão ASK em vez de ALLOW e solicitarão a aprovação do usuário. Dessa forma, o mesmo e-mail que teria sido enviado no início de uma sessão pode exigir aprovação humana mais tarde, depois que o agente tiver manipulado material confidencial suficiente, o que eleva a pontuação.

3. Política de custos: mantenha os gastos sob controle

Uma política de orçamento acompanha quanto a sessão gastou em chamadas de modelo até o momento. Depois de ultrapassar um limite flexível, ela faz uma pausa para perguntar se deve continuar. Quando os gastos atingem o limite rígido, a política bloqueia novas chamadas para o modelo caro até que o agente mude para um mais barato, permitindo que a sessão continue em vez de ser interrompida. A mesma ideia se estende além de uma única sessão. Uma equipe de plataforma pode acumular um limite diário por usuário sobre o limite por sessão, para que ninguém acumule custos em várias conversas separadas. Em ambos os casos, o contexto é o gasto acumulado: a política não está julgando nenhuma chamada de modelo pessoal; ela está monitorando o total acumulado e intervindo quando a sessão ou o usuário gasta demais.

4. Autorização baseada em intenção: limite privilégios com base no propósito

A autorização baseada em intenção define as permissões dos agentes com base no prompt inicial do usuário para eles, de modo que mesmo um agente que tenha sofrido injeção de prompt não possa usar a maioria de suas ferramentas para causar danos. Por exemplo, se você iniciar uma sessão pedindo a um agente para atualizar uma apresentação do Google Slides, a política permitirá que esse agente leia e grave nessa apresentação, mas bloqueará o acesso se o agente tentar usar o GitHub de repente. A política simplesmente lembra o que o usuário realmente pediu no início de uma sessão como estado e, em seguida, compara cada chamada de ferramenta com esse objetivo original, aplicando o Princípio do menor privilégio. Essa é uma política muito simples, mas poderosa, viabilizada pelo estado contextual: você pode configurar agentes com muitas ferramentas por padrão, e eles serão bloqueados automaticamente em cada sessão. A mesma chamada de ferramenta que é aceitável em uma sessão pode exigir sua aprovação em outra, dependendo do que você pediu para o agente fazer.

Conclusão

À medida que os agentes assumem mais trabalho real, a parte difícil passa a ser como controlá-los. Os agentes podem começar a causar danos devido a entradas maliciosas ou bugs honestos, e políticas simples de lista de permissões que inspecionam ações individuais não são flexíveis o suficiente para tornar os agentes utilizáveis e seguros ao mesmo tempo. As políticas contextuais permitem agentes mais utilizáveis e seguros ao rastrear dinamicamente o estado dentro de uma sessão e bloquear ações apenas quando o agente acumular risco suficiente. Elas também oferecem uma ferramenta simples e poderosa para gerenciar orçamentos em nível de sessão, em vez de apenas por usuário e por dia. O Omnigent é código aberto e se integra aos frameworks de agentes e agentes de codificação mais populares, para que você possa começar a aplicar isso aos seus agentes existentes.

Experimente

O Omnigent está disponível em código aberto na versão alfa hoje.

• Comece a usar com o nosso guia de início rápido: https://omnigent.ai/quickstart/install
• Dê uma estrela e clone o repositório: https://github.com/omnigent-ai/omnigent
• Siga o tutorial de políticas: https://omnigent.ai/quickstart/policies
• Leia a documentação de políticas: https://omnigent.ai/docs/policies/overview
• Junte-se a nós no Discord: https://discord.gg/omnigent

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original