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 управляет соединениями между клиентами ИИ и поддерживаемыми бизнес-приложениями. Model Context Protocol, или MCP, предоставляет агентам стандартный способ вызывать инструменты, доступные на внешних серверах. Obsidian устанавливает проверку политик между клиентом и MCP-сервером приложения.

В документации к продукту описан переход с прямого URL-адреса MCP поставщика на конечную точку под управлением Obsidian. Пользователи предоставляют доступ через процесс подтверждения согласия поставщика приложения; ИИ-клиент получает токен, выданный прокси, вместо того чтобы хранить собственный токен доступа к приложению.

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

В объявлении также упоминается сотрудничество с Cloudflare и ее порталом MCP Server Portal. Цель — объединить положение шлюза на пути трафика с контекстом Obsidian, связанным с идентификацией, приложениями и данными.

Почему важен контроль на уровне действий

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

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