Obsidian Security spouští modul pro vynucování zásad za běhu, který umožňuje řídit činnost agentů AI

Obsidian Security uvedla na trh rozhodovací modul pro zásady běhu, který podnikům umožňuje řídit, co agenti AI dělají v podnikových aplikacích, ještě před provedením akce. Toto oznámení rozšiřuje bezpečnostní platformu společnosti pro agenty o MCP Security Proxy, rozhraní Policy Decision API a další pokrytí nástrojů pro programování a agentů zabudovaných do softwaru třetích stran.

Toto uvedení na trh řeší problém, který běžné řízení přístupu nedokáže plně vyřešit: agent může mít platné přihlašovací údaje a používat schválenou aplikaci, a přesto se pokusit o nevhodnou akci. Oprávnění číst záznamy zákazníků například nutně neznamená oprávnění exportovat je do externího cíle.

Obsidian navrhuje posuzovat zamýšlenou akci podle centrálně spravovaných zásad. Zohledňuje přitom osobu, která za agentem stojí, její pracovní poměr a oprávnění, příslušnou aplikaci a klasifikaci dat poskytnutou zákazníkem. Propojené kontrolní body pak akci povolí, zablokují nebo tam, kde je tato možnost podporována, vyžádají schválení.

Od vyhledávání agentů k řízení jejich činnosti

Vyhledávání agentů odpovídá na otázky, které nástroje jsou k dispozici a k čemu mají přístup. Správa může omezit zbytečná oprávnění nebo odhalit riziková nastavení. Zásady uplatňované za běhu řeší zbývající otázku: co by měl jinak oprávněný agent právě teď smět dělat?

Oznámení společnosti Obsidian se týká jak agentů ovládaných zaměstnanci, tak agentů, kteří jsou součástí softwaru, jejž firma již používá. Rozšířené možnosti vyhledávání a správy zahrnují Salesforce Agentforce, Databricks, GitHub, Microsoft 365, Snowflake, ServiceNow a Workday.

Jde o různé kontrolní body. Nalezení agenta v aplikaci SaaS samo o sobě neznamená, že se zachytí každá akce v této aplikaci. Vynucování zásad za běhu závisí na podporované integraci a na místě, kudy akce prochází.

Společnost také přidala podporu zásad uplatňovaných za běhu pro OpenAI Codex, která doplňuje její dosavadní kontrolní mechanismy pro programovací agenty. V oznámení uvádí rizika, jako jsou destruktivní příkazy, odhalení přihlašovacích údajů a čtení dat mimo zamýšlený rozsah projektu – k těmto akcím může dojít i během jinak legitimní vývojové relace.

Kontext, který dosud chyběl, poskytuje znalostní graf

Brána může požadavek zkontrolovat, ale samotný požadavek nemusí objasnit, jaká oprávnění se za ním skrývají. Ke správnému bezpečnostnímu rozhodnutí může být třeba vědět, zda účet, z něhož požadavek přichází, patří zaměstnanci, nebo dodavateli, zda jeho pracovní poměr již skončil a jaká oprávnění tento účet v cílové aplikaci skutečně má.

Architektura Knowledge Graph společnosti Obsidian propojuje osoby, účty, aplikace, tokeny, oprávnění a jejich vzájemné vztahy. Společnost popisuje, jak normalizuje informace ze správních API, proudů aktivit a integrací do společného modelu, který obsahuje verzované entity a vztahy zachycující změny v čase.

Tato struktura pomáhá sledovat přístup napříč několika systémy, místo aby se každý účet posuzoval izolovaně. Agent může zdánlivě zastávat omezenou roli, ale token nebo zděděné oprávnění mu jinde může poskytnout širší přístup. Propojení těchto vztahů dává modulu pro vynucování zásad lepší základ k posouzení, zda je konkrétní akce v souladu s pravidly organizace.

Zákazníci mohou doplnit vlastní kontext, včetně štítků klasifikace. Zásady tak mohou rozlišovat mezi běžným souborem a souborem, který firma označila za vysoce citlivý, namísto toho, aby se spoléhaly výhradně na obecnou definici důvěrných údajů stanovenou dodavatelem bezpečnostního řešení.

Kde se rozhodnutí mění ve vynucení zásad

Architektura odděluje rozhodování od provádění akcí. Podle vysvětlení fungování modulu pro vynucování zásad za běhu od společnosti Obsidian kontrolní bod pozastaví zamýšlenou operaci, odešle její podrobnosti k posouzení a následně uplatní vrácené rozhodnutí i jeho odůvodnění.

Nové API pro rozhodování o zásadách rozšiřuje tento model na brány provozované zákazníkem, prostředí pro spouštění agentů a pracovní postupy. Firma si může ponechat stávající infrastrukturu a požádat Obsidian o rozhodnutí zohledňující kontext. Kontrolní komponenta zákazníka pak musí toto rozhodnutí uplatnit, než operace pokračuje.

Obsidian také popisuje režim příznaku, který umožňuje testovat shodu s pravidly na skutečném provozu ještě před blokováním operací. Záznamy rozhodnutí zachycují agenta, osobu, která požadavek vyvolala, nástroj, argumenty, výsledek i odpovídající zásadu. Bezpečnostní týmy tak mohou zjistit, proč byla akce povolena, nebo zastavena.

Možnost vyžadovat schválení je užší než celková architektura založená na povolování a blokování: podle aktuální dokumentace společnosti je schválení k dispozici u zásad pro Claude Code, které se spouštějí před provedením operace. Při navrhování kontrolních mechanismů pro různorodou sadu agentů jsou proto důležité možnosti jednotlivých integrací.

Proxy MCP brání tomu, aby se tokeny aplikací dostaly do klientů AI

Bezpečnostní proxy MCP řídí spojení mezi klienty s umělou inteligencí a podporovanými podnikovými aplikacemi. Model Context Protocol neboli MCP poskytuje agentům standardní způsob, jak volat nástroje zpřístupněné externími servery. Obsidian vkládá kontrolu zásad mezi klienta a server MCP dané aplikace.

Dokumentace k produktu popisuje nahrazení přímé adresy URL MCP dodavatele koncovým bodem spravovaným společností Obsidian. Uživatelé autorizují přístup prostřednictvím procesu udělování souhlasu dodavatele aplikace; klient s umělou inteligencí obdrží token vydaný proxy, místo aby sám ukládal přístupový token aplikace.

Proxy přiřazuje relaci uživateli, jeho účtu v aplikaci a příslušnému tenantovi, například konkrétní organizaci nebo pracovnímu prostoru Salesforce. Před předáním volání nástrojů ověřuje a zaznamenává, zda byla povolena, nebo zablokována. Obsidian uvádí, že toto řešení funguje v rámci stávajících oprávnění uživatele v aplikaci, místo aby přidávalo oprávnění prostřednictvím sdíleného servisního účtu.

Oznámení zmiňuje také spolupráci se společností Cloudflare a jejím portálem MCP Server Portal. Cílem je spojit umístění brány v trase síťového provozu s kontextem identity, aplikací a dat, který poskytuje Obsidian.

Proč jsou kontroly na úrovni jednotlivých akcí důležité

Pro podniky nasazující agenty spočívá praktická výzva v tom, jak jim umožnit užitečnou práci a zároveň omezit dopady závažných chyb. Plošný zákaz může celý pracovní postup zastavit; úzce vymezené rozhodnutí může povolit běžné čtení dat, ale zároveň zabránit neoprávněnému exportu nebo vyžadovat kontrolu destruktivní změny.

Obsidian začleňuje tato rozhodnutí do společné vrstvy zásad napříč podporovanými nástroji a body vynucování. Přínos bude záviset na kvalitě podkladového kontextu přístupových oprávnění a na úplnosti cest, které jsou pod kontrolou. S rostoucí provozní odpovědností agentů nabývá schopnost rozhodnutí před provedením vysvětlit a vynutit na významu jako stále důležitější součást zabezpečení podniku.