Obsidian Security lansează un motor de decizie pentru politici în timpul execuției, care controlează acțiunile agenților IA

Obsidian Security a lansat un motor de decizie pentru politici în timpul execuției, conceput pentru a le permite companiilor să controleze ce fac agenții IA în aplicațiile de business, înainte de executarea unei acțiuni. Anunțul extinde platforma companiei pentru securitatea agenților, adăugând un proxy de securitate MCP, un API pentru decizii privind politicile și acoperire suplimentară pentru instrumente de programare și agenți integrați în software terț.

Lansarea răspunde unei probleme pe care controalele obișnuite de acces nu o rezolvă pe deplin: un agent poate avea acreditări valide și poate folosi o aplicație aprobată, dar totuși poate încerca să efectueze o acțiune nepotrivită. De exemplu, permisiunea de a citi înregistrările clienților nu înseamnă neapărat și permisiunea de a le exporta într-o locație externă.

Abordarea Obsidian constă în evaluarea acțiunii propuse în raport cu politicile gestionate central, luând în considerare persoana din spatele agentului, statutul său profesional și permisiunile sale, aplicația vizată și clasificările datelor furnizate de client. Punctele de aplicare conectate permit apoi acțiunea sau o blochează ori solicită aprobarea, acolo unde această funcționalitate este disponibilă.

De la descoperirea agenților la controlul acțiunilor lor

Descoperirea agenților arată ce instrumente sunt prezente și la ce resurse pot ajunge. Guvernanța poate reduce permisiunile inutile sau poate identifica configurațiile riscante. Politicile aplicate în timpul execuției răspund la întrebarea rămasă: ce ar trebui să i se permită să facă, chiar acum, unui agent autorizat în rest?

Anunțul Obsidian vizează atât agenții operați de angajați, cât și agenții integrați în software-ul pe care întreprinderea îl utilizează deja. Capabilitățile extinse de descoperire și guvernanță includ Salesforce Agentforce, Databricks, GitHub, Microsoft 365, Snowflake, ServiceNow și Workday.

Acestea sunt suprafețe de control diferite. Faptul că un agent este găsit într-o aplicație SaaS nu înseamnă, în sine, că fiecare acțiune din aplicația respectivă este interceptată. Aplicarea politicilor în timpul execuției depinde de integrarea acceptată și de punctul prin care trece o acțiune.

Compania a adăugat, de asemenea, suport pentru politici aplicate în timpul execuției în OpenAI Codex, pe lângă controalele existente pentru agenții de programare. Anunțul menționează riscuri precum comenzile distructive, expunerea acreditărilor și citirea datelor din afara domeniului prevăzut al unui proiect — acțiuni care pot avea loc în timpul unei sesiuni de dezvoltare altminteri legitime.

Knowledge Graph oferă contextul lipsă

Un gateway poate inspecta o solicitare, însă este posibil ca solicitarea, de una singură, să nu explice autoritatea care stă la baza ei. Pentru o decizie de securitate pertinentă poate fi necesar să se știe dacă acel cont aparține unui angajat sau unui contractant, dacă raportul de muncă s-a încheiat și ce permisiuni are efectiv contul în aplicația de destinație.

Arhitectura Knowledge Graph a Obsidian conectează persoane, conturi, aplicații, tokenuri, drepturi de acces și relațiile dintre acestea. Compania descrie normalizarea informațiilor provenite din API-uri administrative, fluxuri de activitate și integrări într-un model comun, cu entități și relații versionate pentru a surprinde schimbările de-a lungul timpului.

Această structură ajută la urmărirea accesului în mai multe sisteme, în loc să analizeze fiecare cont separat. Rolul aparent al unui agent poate fi limitat, în timp ce un token sau un drept moștenit îi oferă acces mai larg în altă parte. Corelarea acestor relații oferă motorului de politici o bază mai solidă pentru a stabili dacă o anumită acțiune se încadrează în regulile organizației.

Clienții își pot adăuga propriul context, inclusiv etichete de clasificare. Astfel, o politică poate face diferența între un fișier obișnuit și unul pe care compania îl desemnează drept extrem de sensibil, în loc să se bazeze exclusiv pe definiția generică a unui furnizor de securitate pentru datele confidențiale.

Unde decizia devine aplicare efectivă

Arhitectura separă decizia de acțiune. În explicația Obsidian despre motorul de execuție, un punct de aplicare suspendă operațiunea propusă, trimite detaliile acesteia pentru evaluare și aplică decizia returnată, împreună cu motivarea aferentă.

Noul API pentru decizii privind politicile extinde acest model la gateway-uri operate de clienți, medii de execuție pentru agenți și fluxuri de lucru. O companie își poate păstra infrastructura existentă și, în același timp, poate solicita Obsidian o decizie bazată pe context. Componenta de aplicare a clientului trebuie apoi să pună în aplicare acea decizie înainte ca operațiunea să continue.

Obsidian documentează și un mod de semnalizare pentru testarea potrivirilor cu politicile pe trafic real, înainte de blocarea operațiunilor. Înregistrările deciziilor consemnează agentul, persoana care a inițiat acțiunea, instrumentul, argumentele, rezultatul și politica aplicată, oferind echipelor de securitate o modalitate de a investiga de ce o acțiune a fost permisă sau oprită.

Suportul pentru aprobări este mai restrâns decât arhitectura generală de permitere sau blocare: documentația actuală a companiei precizează că solicitarea aprobării este disponibilă pentru politicile Claude Code care rulează înaintea unei operațiuni. Prin urmare, capacitățile disponibile la nivelul integrărilor sunt importante atunci când se proiectează controale pentru un ansamblu mixt de agenți.

Proxy-ul MCP ține tokenurile aplicațiilor în afara clienților IA

Proxy-ul de securitate MCP controlează conexiunile dintre clienții AI și aplicațiile de business acceptate. Model Context Protocol (MCP) oferă agenților o modalitate standard de a apela instrumentele puse la dispoziție de servere externe. Obsidian interpune o verificare a politicilor între client și serverul MCP al aplicației.

Documentația produsului descrie înlocuirea URL-ului MCP direct al furnizorului cu un endpoint administrat de Obsidian. Utilizatorii autorizează accesul prin fluxul de consimțământ al furnizorului aplicației; clientul AI primește un token emis de proxy, în loc să stocheze el însuși tokenul de acces al aplicației.

Proxy-ul asociază o sesiune utilizatorului, contului său din aplicație și tenantului relevant, cum ar fi o anumită organizație sau un anumit spațiu de lucru Salesforce. Verifică apelurile instrumentelor înainte de a le redirecționa și înregistrează dacă au fost permise sau blocate. Obsidian afirmă că acest mecanism funcționează în limitele permisiunilor existente ale utilizatorului în aplicație, fără a adăuga privilegii prin intermediul unui cont de serviciu partajat.

Anunțul menționează, de asemenea, o colaborare cu Cloudflare și MCP Server Portal al acesteia. Obiectivul este să combine poziția unui gateway pe traseul traficului cu informațiile Obsidian despre identitate, aplicații și date.

De ce contează controalele la nivel de acțiune

Pentru companiile care implementează agenți, provocarea practică este să le permită să desfășoare activități utile, limitând totodată greșelile cu consecințe importante. O interdicție generală poate opri complet un flux de lucru; o decizie cu un domeniu de aplicare restrâns poate permite operațiunile obișnuite de citire, împiedicând în același timp exportul neautorizat sau solicitând verificarea unei modificări distructive.

Obsidian integrează aceste decizii într-un nivel comun de politici, aplicabil instrumentelor și punctelor de control acceptate. Valoarea acestuia va depinde de calitatea contextului de acces subiacent și de exhaustivitatea traseelor aflate sub control. Pe măsură ce agenții primesc tot mai multe responsabilități operaționale, capacitatea de a explica și de a aplica o decizie înainte de executare devine o componentă din ce în ce mai importantă a securității companiilor.