A Obsidian Security lança mecanismo de políticas em tempo de execução para controlar as ações de agentes de IA

A Obsidian Security lançou um mecanismo de decisão de políticas em tempo de execução, desenvolvido para permitir que as empresas controlem o que os agentes de IA fazem dentro de aplicativos corporativos antes que uma ação seja executada. O anúncio amplia a plataforma de segurança de agentes da empresa com um proxy de segurança MCP, uma API de decisão de políticas e cobertura adicional para ferramentas de programação e agentes incorporados a softwares de terceiros.

O lançamento aborda um problema que os controles de acesso comuns não resolvem por completo: um agente pode ter credenciais válidas e usar um aplicativo aprovado, mas ainda assim tentar realizar uma ação inadequada. Ter permissão para ler registros de clientes, por exemplo, não significa necessariamente ter permissão para exportá-los para um destino externo.

A abordagem da Obsidian consiste em avaliar a ação proposta com base em políticas gerenciadas centralmente, levando em conta a pessoa por trás do agente, seu vínculo empregatício e suas permissões, o aplicativo envolvido e as classificações de dados fornecidas pelo cliente. Em seguida, pontos de aplicação de políticas conectados permitem ou bloqueiam a ação, ou exigem aprovação quando esse recurso é compatível.

Da descoberta de agentes ao controle de suas ações

A descoberta de agentes identifica quais ferramentas estão presentes e a que elas podem ter acesso. A governança pode reduzir permissões desnecessárias ou identificar configurações arriscadas. As políticas em tempo de execução abordam a questão que resta: o que um agente que, de resto, está autorizado deve poder fazer neste momento?

O anúncio da Obsidian abrange tanto agentes operados por funcionários quanto agentes integrados a softwares que a empresa já utiliza. Os recursos ampliados de descoberta e governança incluem Salesforce Agentforce, Databricks, GitHub, Microsoft 365, Snowflake, ServiceNow e Workday.

Esses são pontos de controle distintos. Encontrar um agente dentro de um aplicativo SaaS não significa, por si só, que todas as ações nesse aplicativo sejam interceptadas. A aplicação de políticas em tempo de execução depende da integração compatível e do ponto pelo qual a ação passa.

A empresa também adicionou suporte a políticas em tempo de execução para o OpenAI Codex, além dos controles já existentes para agentes de programação. O anúncio identifica riscos como comandos destrutivos, exposição de credenciais e leituras fora do escopo previsto para um projeto — ações que podem ocorrer durante uma sessão de desenvolvimento que, de resto, é legítima.

O Knowledge Graph fornece o contexto que faltava

Um gateway pode inspecionar uma solicitação, mas talvez ela, por si só, não esclareça quais são as permissões de quem a iniciou. Para tomar uma decisão de segurança adequada, pode ser necessário saber se a conta que invocou o agente pertence a um funcionário ou contratado, se o vínculo empregatício terminou e quais permissões a conta realmente tem no aplicativo de destino.

A arquitetura do Knowledge Graph da Obsidian conecta pessoas, contas, aplicativos, tokens, direitos de acesso e as relações entre eles. A empresa descreve a normalização de informações provenientes de APIs administrativas, fluxos de atividade e integrações em um modelo comum, com entidades e relações versionadas para registrar mudanças ao longo do tempo.

Essa estrutura ajuda a rastrear o acesso em vários sistemas, em vez de examinar cada conta isoladamente. O papel aparente de um agente pode ser restrito, enquanto um token ou direito de acesso herdado lhe dá um alcance mais amplo em outro lugar. Conectar essas relações dá ao mecanismo de políticas uma base mais sólida para decidir se determinada ação está de acordo com as regras da organização.

Os clientes podem acrescentar seu próprio contexto, incluindo rótulos de classificação. Assim, uma política pode distinguir um arquivo comum de outro que a empresa classifica como altamente confidencial, em vez de depender apenas da definição genérica de dados confidenciais adotada por um fornecedor de segurança.

Onde a decisão se transforma em aplicação

A arquitetura separa a decisão da execução. Na explicação do mecanismo em tempo de execução da Obsidian, um ponto de aplicação de políticas pausa uma operação proposta, envia os detalhes para avaliação e aplica a decisão e a justificativa recebidas.

A nova API de decisão de políticas estende esse modelo a gateways operados pelos clientes, estruturas de execução de agentes e fluxos de trabalho. Uma empresa pode manter sua infraestrutura atual e, ao mesmo tempo, solicitar à Obsidian um parecer que leve o contexto em conta. Em seguida, o componente de aplicação de políticas do cliente precisa aplicar esse parecer antes que a operação prossiga.

A Obsidian também documenta um modo de sinalização para testar a correspondência com as políticas usando tráfego real antes de bloquear operações. Os registros de decisão capturam o agente, a pessoa que o invocou, a ferramenta, os argumentos, o resultado e a política correspondente, permitindo que as equipes de segurança investiguem por que uma ação foi permitida ou interrompida.

O suporte à aprovação é mais limitado do que a arquitetura geral de permissão ou bloqueio: a documentação atual da empresa informa que a exigência de aprovação está disponível para políticas do Claude Code executadas antes de uma operação. Isso torna os recursos disponíveis em cada integração importantes ao projetar controles para um conjunto diversificado de agentes.

O proxy MCP mantém os tokens dos aplicativos fora dos clientes de IA

O Proxy de Segurança do MCP controla as conexões entre clientes de IA e aplicações empresariais compatíveis. O Model Context Protocol, ou MCP, oferece aos agentes uma maneira padronizada de chamar ferramentas disponibilizadas por servidores externos. A Obsidian insere uma verificação de políticas entre o cliente e o servidor MCP da aplicação.

A documentação do produto descreve a substituição do URL direto do MCP do fornecedor por um endpoint controlado pela Obsidian. Os usuários autorizam o acesso por meio do fluxo de consentimento do fornecedor da aplicação; o cliente de IA recebe um token emitido pelo proxy, em vez de armazenar o próprio token de acesso à aplicação.

O proxy associa uma sessão ao usuário, à conta dele na aplicação e ao locatário correspondente, como uma organização ou um espaço de trabalho específico do Salesforce. Ele verifica as chamadas às ferramentas antes de encaminhá-las e registra se foram permitidas ou bloqueadas. Segundo a Obsidian, esse processo funciona dentro das permissões que o usuário já tem na aplicação, sem conceder privilégios adicionais por meio de uma conta de serviço compartilhada.

O anúncio também menciona uma colaboração com a Cloudflare e o MCP Server Portal da empresa. O objetivo é combinar a posição de um gateway no fluxo de tráfego com o contexto de identidade, aplicação e dados da Obsidian.

Por que os controles no nível da ação são importantes

Para as empresas que implementam agentes, o desafio prático é permitir atividades úteis e, ao mesmo tempo, conter erros com consequências significativas. Uma proibição geral pode interromper completamente um fluxo de trabalho; uma decisão de escopo restrito pode permitir operações rotineiras de leitura e, ao mesmo tempo, impedir uma exportação não autorizada ou exigir a revisão de uma alteração destrutiva.

A Obsidian está reunindo essas decisões em uma camada de políticas compartilhada entre as ferramentas compatíveis e os pontos de aplicação das regras. O valor dependerá da qualidade do contexto de acesso subjacente e da abrangência dos caminhos sob controle. À medida que os agentes assumem mais responsabilidades operacionais, a capacidade de explicar e fazer cumprir uma decisão antes de sua execução se torna uma parte cada vez mais importante da segurança empresarial.