Obsidian Security запускає рушій політик під час виконання для контролю дій агентів ШІ

Obsidian Security запустила рушій ухвалення рішень щодо політик під час виконання, який дає змогу підприємствам контролювати дії агентів ШІ в бізнес-застосунках до їх виконання. Цей запуск розширює платформу компанії для захисту агентів: до неї додано проксі-сервер безпеки MCP, API ухвалення рішень щодо політик, а також ширшу підтримку інструментів для написання коду й агентів, вбудованих у стороннє програмне забезпечення.

Цей запуск покликаний розв’язати проблему, яку не усувають повністю звичайні засоби контролю доступу: агент може мати дійсні облікові дані й користуватися дозволеним застосунком, але водночас намагатися виконати недоречну дію. Наприклад, дозвіл читати записи клієнтів не обов’язково означає дозвіл експортувати їх до зовнішнього ресурсу.

Obsidian оцінює запропоновану дію відповідно до політик, якими централізовано керують, враховуючи особу, від імені якої діє агент, її працевлаштування та дозволи, залучений застосунок і надані клієнтом класифікації даних. Підключені засоби контролю виконання потім дозволяють або блокують дію чи вимагають схвалення, якщо така можливість підтримується.

Від виявлення агентів до контролю їхніх дій

Виявлення агентів дає змогу з’ясувати, які інструменти є в системі та до чого вони мають доступ. Засоби управління можуть скоротити надмірні дозволи або виявити ризиковані конфігурації. Політики під час виконання допомагають відповісти на питання, що лишається: що саме можна дозволити робити зараз агенту, який загалом має відповідні повноваження?

У повідомленні Obsidian ідеться як про агентів, якими користуються працівники, так і про агентів, вбудованих у програмне забезпечення, яким підприємство вже користується. Розширені можливості виявлення агентів і управління ними охоплюють Salesforce Agentforce, Databricks, GitHub, Microsoft 365, Snowflake, ServiceNow і Workday.

Це різні точки контролю. Виявлення агента в SaaS-застосунку саме по собі не означає, що перехоплюватиметься кожна дія в цьому застосунку. Контроль виконання залежить від підтримуваної інтеграції та точки, через яку проходить дія.

Компанія також додала підтримку політик під час виконання для OpenAI Codex на додачу до вже наявних засобів контролю агентів для написання коду. У повідомленні компанії згадано такі ризики, як деструктивні команди, розкриття облікових даних і читання даних за межами передбаченої для проєкту області — дії, які можуть відбуватися під час цілком легітимної сесії розробки.

Граф знань надає необхідний контекст

Шлюз може перевірити запит, але сам запит може не пояснювати, які повноваження за ним стоять. Щоб ухвалити обґрунтоване рішення з безпеки, може знадобитися знати, чи належить обліковий запис, від імені якого надійшов запит, працівникові або підряднику, чи завершилися його трудові відносини та які саме дозволи має обліковий запис у цільовому застосунку.

Архітектура Knowledge Graph від Obsidian пов’язує людей, облікові записи, застосунки, токени, надані права та зв’язки між ними. Компанія описує, як нормалізує інформацію з адміністративних API, потоків активності та інтеграцій, зводячи її до спільної моделі з версіонованими сутностями та зв’язками, щоб фіксувати зміни з часом.

Така структура допомагає відстежувати доступ у кількох системах, а не розглядати кожен обліковий запис окремо. Видима роль агента може бути вузькою, тоді як токен або успадковане право надає йому ширший доступ до інших ресурсів. Врахування цих зв’язків дає рушію політик надійнішу основу для визначення того, чи відповідає конкретна дія правилам організації.

Клієнти можуть додавати власний контекст, зокрема мітки класифікації. Завдяки цьому політика може розрізняти звичайний файл і файл, який підприємство визначило як особливо чутливий, замість того щоб покладатися лише на загальне визначення конфіденційних даних від постачальника засобів безпеки.

Як рішення перетворюється на примусове виконання

В архітектурі окремо передбачено ухвалення рішення та його виконання. В поясненні роботи рушія під час виконання від Obsidian ідеться про те, що засіб контролю призупиняє запропоновану операцію, надсилає її параметри на оцінювання, а потім застосовує отримане рішення та пояснення до нього.

Новий API ухвалення рішень щодо політик поширює цю модель на шлюзи, якими керують клієнти, середовища запуску агентів і робочі процеси. Підприємство може й надалі використовувати наявну інфраструктуру, водночас запитуючи в Obsidian вердикт з урахуванням контексту. Перш ніж операцію буде виконано, компонент контролю на боці клієнта має застосувати цей вердикт.

Obsidian також описує режим позначення, який дає змогу перевіряти збіги з політиками на реальному трафіку, перш ніж блокувати операції. У записах рішень фіксуються агент, особа, від імені якої він діє, інструмент, аргументи, результат і політика, що спрацювала. Це дає командам безпеки змогу з’ясовувати, чому дію дозволили або зупинили.

Підтримка схвалення доступна не для всіх сценаріїв у загальній архітектурі дозволу або блокування: згідно з актуальною документацією компанії, вимагати схвалення можна для політик Claude Code, які спрацьовують до виконання операції. Тому під час розробки засобів контролю для різнорідного набору агентів важливо враховувати можливості кожної інтеграції.

Проксі-сервер MCP не дає токенам застосунків потрапити до клієнтів ШІ

Проксі-сервер безпеки MCP керує з’єднаннями між клієнтами ШІ та підтримуваними бізнес-застосунками. Протокол контексту моделі, або MCP, надає агентам стандартний спосіб викликати інструменти, доступні на зовнішніх серверах. Obsidian розміщує перевірку політик між клієнтом і MCP-сервером застосунку.

У документації до продукту описано, як замінити пряму MCP-адресу URL постачальника на кінцеву точку під керуванням Obsidian. Користувачі надають доступ через процес надання згоди постачальника застосунку; клієнт ШІ отримує токен, виданий проксі-сервером, замість того, щоб зберігати токен доступу до застосунку.

Проксі-сервер пов’язує сеанс із користувачем, його обліковим записом у застосунку та відповідним тенантом, наприклад конкретною організацією чи робочим простором Salesforce. Перед пересиланням викликів інструментів він перевіряє їх і фіксує, чи було їх дозволено або заблоковано. За словами Obsidian, це працює в межах наявних дозволів користувача в застосунку, а не надає додаткових привілеїв через спільний службовий обліковий запис.

В оголошенні також згадується співпраця з Cloudflare та її порталом MCP-серверів. Мета — поєднати розташування шлюзу на шляху мережевого трафіку з контекстом ідентичності, застосунків і даних, яким володіє Obsidian.

Чому важливий контроль на рівні дій

Для підприємств, які впроваджують агентів, практичне завдання полягає в тому, щоб дозволяти корисну роботу й водночас обмежувати наслідки серйозних помилок. Загальна заборона може повністю зупинити робочий процес; натомість вузько окреслене рішення може дозволити звичайні операції читання, водночас зупинивши несанкціоноване експортування даних або вимагаючи перевірки деструктивної зміни.

Obsidian об’єднує такі рішення у спільний рівень політик для підтримуваних інструментів і точок контролю. Цінність такого підходу залежатиме від якості базового контексту доступу та повноти шляхів, що перебувають під контролем. У міру того як агенти отримують більше операційних повноважень, здатність пояснювати й забезпечувати виконання рішення до його реалізації стає дедалі важливішою складовою безпеки підприємства.