Obsidian Security uruchamia silnik reguł działający w czasie wykonywania, aby kontrolować działania agentów AI

Obsidian Security uruchomiło silnik decyzyjny polityk, który ma umożliwić przedsiębiorstwom kontrolowanie działań agentów AI w aplikacjach biznesowych, zanim zostaną one wykonane. Ogłoszenie rozszerza platformę firmy do zabezpieczania agentów o proxy bezpieczeństwa MCP, interfejs API do podejmowania decyzji dotyczących polityk oraz dodatkową ochronę narzędzi programistycznych i agentów osadzonych w oprogramowaniu innych firm.

Wprowadzenie tego rozwiązania odpowiada na problem, którego nie rozwiązują w pełni standardowe mechanizmy kontroli dostępu: agent może dysponować prawidłowymi danymi uwierzytelniającymi i korzystać z zatwierdzonej aplikacji, a mimo to próbować wykonać niewłaściwe działanie. Na przykład uprawnienie do odczytu danych klientów nie musi oznaczać zgody na eksportowanie ich do zewnętrznej lokalizacji.

Obsidian ocenia proponowane działanie na podstawie centralnie zarządzanych reguł, uwzględniając osobę stojącą za agentem, jej zatrudnienie i uprawnienia, używaną aplikację oraz klasyfikacje danych określone przez klienta. Połączone punkty egzekwowania reguł zezwalają na działanie lub je blokują, a w przypadkach, w których ta funkcja jest obsługiwana, mogą też wymagać zatwierdzenia.

Od wykrywania agentów do kontrolowania ich działań

Wykrywanie agentów pozwala ustalić, jakie narzędzia są dostępne i do jakich zasobów mają dostęp. Nadzór może ograniczyć zbędne uprawnienia lub pomóc zidentyfikować ryzykowne konfiguracje. Reguły egzekwowane w czasie wykonywania odpowiadają na pozostałe pytanie: co w danej chwili powinien móc zrobić agent, który ma odpowiednie uprawnienia?

Komunikat Obsidian obejmuje zarówno agentów obsługiwanych przez pracowników, jak i agentów dostępnych w używanym już przez przedsiębiorstwo oprogramowaniu. Rozszerzone możliwości wykrywania i nadzoru obejmują Salesforce Agentforce, Databricks, GitHub, Microsoft 365, Snowflake, ServiceNow i Workday.

Są to różne punkty kontroli. Wykrycie agenta w aplikacji SaaS nie oznacza samo w sobie, że każde działanie w tej aplikacji jest przechwytywane. Egzekwowanie reguł w czasie wykonywania zależy od obsługiwanej integracji i punktu, przez który przechodzi działanie.

Firma dodała również obsługę reguł egzekwowanych w czasie wykonywania dla OpenAI Codex, uzupełniając dotychczasowe mechanizmy kontroli agentów programistycznych. W komunikacie wymieniono takie zagrożenia jak destrukcyjne polecenia, ujawnienie danych uwierzytelniających i odczyt danych spoza zakresu przewidzianego dla projektu — działania, do których może dojść podczas sesji programistycznej przebiegającej poza tym zgodnie z prawem.

Graf wiedzy dostarcza brakującego kontekstu

Brama może sprawdzić żądanie, ale samo żądanie może nie wyjaśniać, z jakiego zakresu uprawnień wynika. Podjęcie właściwej decyzji dotyczącej bezpieczeństwa może wymagać ustalenia, czy konto wywołujące działanie należy do pracownika czy podwykonawcy, czy stosunek pracy lub współpracy już się zakończył oraz jakie uprawnienia konto faktycznie ma w docelowej aplikacji.

Architektura Knowledge Graph firmy Obsidian łączy osoby, konta, aplikacje, tokeny, uprawnienia i relacje między nimi. Firma opisuje normalizowanie informacji z interfejsów API do zarządzania, strumieni aktywności i integracji do wspólnego modelu, w którym wersjonowane encje i relacje pozwalają rejestrować zmiany zachodzące w czasie.

Taka struktura ułatwia śledzenie dostępu w wielu systemach, zamiast analizowania każdego konta z osobna. Rola przypisywana agentowi może wydawać się ograniczona, podczas gdy token lub odziedziczone uprawnienie zapewnia mu szerszy dostęp w innym miejscu. Powiązanie tych relacji daje silnikowi reguł lepszą podstawę do oceny, czy dane działanie jest zgodne z zasadami organizacji.

Klienci mogą dodawać własny kontekst, w tym etykiety klasyfikacyjne. Dzięki temu reguła może odróżniać zwykły plik od takiego, który firma uznaje za wysoce wrażliwy, zamiast opierać się wyłącznie na ogólnej definicji danych poufnych przyjętej przez dostawcę zabezpieczeń.

Od decyzji do egzekwowania reguł

Architektura rozdziela podejmowanie decyzji od działania. W objaśnieniu działania silnika w czasie wykonywania firmy Obsidian punkt egzekwowania reguł wstrzymuje proponowaną operację, przesyła jej szczegóły do oceny, a następnie stosuje otrzymaną decyzję i uzasadnienie.

Nowy interfejs API do podejmowania decyzji dotyczących reguł rozszerza ten model na bramy obsługiwane przez klientów, środowiska obsługujące agentów i przepływy pracy. Przedsiębiorstwo może zachować dotychczasową infrastrukturę, a jednocześnie zwracać się do Obsidian o ocenę uwzględniającą kontekst. Komponent egzekwujący reguły po stronie klienta musi następnie zastosować tę decyzję, zanim operacja będzie kontynuowana.

Obsidian opisuje również tryb flagowania, który pozwala sprawdzać, czy rzeczywisty ruch sieciowy spełnia warunki reguł, zanim operacje zostaną zablokowane. Rejestry decyzji zawierają informacje o agencie, osobie wywołującej działanie, narzędziu, argumentach, wyniku i zastosowanej regule, dzięki czemu zespoły ds. bezpieczeństwa mogą sprawdzić, dlaczego dane działanie zostało dozwolone lub zablokowane.

Obsługa zatwierdzania ma węższy zakres niż ogólna architektura zezwalania na działania lub ich blokowania: aktualna dokumentacja firmy informuje, że wymóg zatwierdzenia jest dostępny dla reguł Claude Code uruchamianych przed operacją. Przy projektowaniu mechanizmów kontroli dla zróżnicowanego środowiska agentów istotne są więc możliwości poszczególnych integracji.

Proxy MCP chroni tokeny aplikacji przed dostępem klientów AI

Proxy bezpieczeństwa MCP zarządza połączeniami między klientami AI a obsługiwanymi aplikacjami biznesowymi. Model Context Protocol, czyli MCP, zapewnia agentom standardowy sposób wywoływania narzędzi udostępnianych przez serwery zewnętrzne. Obsidian umieszcza kontrolę zgodności z polityką między klientem a serwerem MCP aplikacji.

Dokumentacja produktu opisuje zastąpienie bezpośredniego adresu URL MCP dostawcy punktem końcowym zarządzanym przez Obsidian. Użytkownicy autoryzują dostęp za pomocą procesu wyrażania zgody dostawcy aplikacji; klient AI otrzymuje token wydany przez serwer proxy, zamiast przechowywać samodzielnie token dostępu do aplikacji.

Serwer proxy przypisuje sesję do użytkownika, jego konta w aplikacji oraz odpowiedniego środowiska, takiego jak konkretna organizacja lub przestrzeń robocza Salesforce. Przed przekazaniem wywołań narzędzi sprawdza je i rejestruje, czy zostały dozwolone, czy zablokowane. Obsidian twierdzi, że rozwiązanie działa w ramach istniejących uprawnień użytkownika w aplikacji, zamiast nadawać dodatkowe uprawnienia za pośrednictwem współdzielonego konta usługi.

W ogłoszeniu wspomniano również o współpracy z Cloudflare i jego portalem MCP Server Portal. Jej celem jest połączenie pozycji bramy w ścieżce ruchu sieciowego z kontekstem tożsamości, aplikacji i danych zapewnianym przez Obsidian.

Dlaczego kontrola na poziomie działań ma znaczenie

W przypadku przedsiębiorstw wdrażających agentów praktycznym wyzwaniem jest umożliwienie im użytecznej pracy przy jednoczesnym ograniczaniu skutków poważnych błędów. Całkowity zakaz może zatrzymać cały przepływ pracy; precyzyjnie określona decyzja może pozwolić na rutynowe odczyty, a jednocześnie zablokować nieautoryzowany eksport lub wymagać sprawdzenia destrukcyjnej zmiany.

Obsidian przenosi te decyzje do wspólnej warstwy polityk obejmującej obsługiwane narzędzia i punkty egzekwowania zasad. Wartość rozwiązania będzie zależeć od jakości kontekstu dostępu oraz kompletności ścieżek objętych kontrolą. Wraz ze wzrostem zakresu odpowiedzialności operacyjnej agentów możliwość wyjaśnienia i egzekwowania decyzji przed jej wykonaniem staje się coraz ważniejszym elementem bezpieczeństwa przedsiębiorstw.