Кто на самом деле стоит за действиями ИИ-агентов: проблема делегирования полномочий

ИИ-агенты не обладают собственной властью. Это звучит контринтуитивно, но именно это делает их особенно опасными с точки зрения корпоративной безопасности. Когда агент выполняет задачу, он действует не от своего имени — он действует от имени того, кто его запустил. Человека. Сервисного аккаунта. Бота. Другой машины. И вот здесь кроется настоящая проблема, которую принято называть «разрывом полномочий ИИ-агента» (AI Agent Authority Gap).
Кто на самом деле стоит за действиями ИИ-агентов: проблема делегирования полномочий
Изображение носит иллюстративный характер

Традиционные системы управления идентификацией и доступом, IAM, были спроектированы вокруг одного вопроса: кто имеет доступ? Это работало, пока «кто» означало человека или конкретную систему с понятными границами. Сейчас вопрос стал сложнее: какие полномочия делегированы, кем именно, при каких условиях и с какой целью? Это не терминологическое усложнение, а принципиальная смена логики управления. Классический IAM на этот вопрос отвечать не умеет.
Разрыв, о котором идёт речь, это по сути делегационный разрыв. Предприятия пытаются управлять самим агентом, не разобравшись сначала с идентичностями, которые его запускают. Это всё равно что ужесточать контроль на выходе из здания, оставив входную дверь открытой. Агент наследует полномочия от своего источника — и если этот источник плохо контролируется, агент становится не просто уязвимостью, а её усилителем.
Проблему усугубляет то, что корпоративные идентичности сегодня сильно фрагментированы. Они живут в приложениях, встроенных учётных данных, неуправляемых сервисных аккаунтах, API, бизнес-логике конкретных систем. Всё это — то, что компания Orchid называет «identity dark matter», тёмная материя идентичности. Это полномочия, которые существуют, работают и накапливают риски за пределами видимости любых управляемых систем. Когда ИИ-агент получает делегированные права от такого невидимого источника, он действует в полной слепоте — и компания вместе с ним.
Orchid предлагает начинать не с агента, а с источника делегирования. Последовательность имеет значение. Прежде чем выстраивать управление ИИ-агентами, нужно разобраться с традиционными акторами: людьми, машинами, ботами, сервисными аккаунтами, нечеловеческими идентичностями. Нужно устранить тёмную материю идентичности и установить верифицированную базовую линию реального поведения идентичностей — не статические политики, а живое понимание того, что происходит на самом деле.
Модель непрерывной наблюдаемости Orchid (Orchid's Continuous Observability Model) как раз занимается этим. Она не просто делает идентичности видимыми — она превращает эту видимость в механизм управления. Телеметрия собирается постоянно, и данные о поведении традиционных акторов поступают в реальном времени в то, что Orchid называет слоем делегирования полномочий агентного ИИ (Agent-AI Delegation Authority Layer). Это не архивирование событий постфактум, а живой механизм принятия решений.
Как работает этот механизм на практике? Когда агент запрашивает право действовать, система оценивает четыре переменных одновременно: профиль полномочий делегирующего актора, контекст целевого приложения, намерение за запрошенным действием, и реальный охват выполнения. На основе этого анализа система принимает решение с машинной скоростью: агент может действовать, может рекомендовать, ограничивается минимальным набором инструментов или останавливается полностью.
Ключевое правило, которое здесь работает: чем слабее, рискованнее или менее понятен делегирующий актор, тем жёстче должны быть ограничения на действия агента. Это логика, противоположная тому, как сейчас устроено большинство корпоративных систем. Обычно ограничения накладываются на агента по умолчанию и снимаются по запросу. Orchid предлагает динамический подход: полномочия агента формируются в реальном времени исходя из состояния его источника делегирования.
Итоговое состояние, к которому ведёт эта архитектура, называется динамическим последовательным контролем делегирования (Dynamic Sequential Delegation Control). Это не разовая проверка при выдаче прав доступа, а непрерывный процесс, где каждое действие агента оценивается заново с учётом актуального контекста. Такой подход позволяет реагировать не на инциденты, которые уже произошли, а предотвращать их до того, как агент успеет нанести ущерб.
Почему это важно именно сейчас? Потому что ИИ-агенты принципиально отличаются от программного обеспечения прошлых поколений. Они не просто выполняют заданные операции — они интерпретируют контекст, принимают промежуточные решения, взаимодействуют с другими системами. При этом они полностью неотделимы от идентичностей, которые их запускают. Любая попытка управлять агентом в обход управления его источником делегирования — это иллюзия контроля.
Путь, который описывает Orchid, состоит из трёх шагов: сначала сократить тёмную материю идентичности, затем выстроить непрерывную наблюдаемость за реальным поведением идентичностей, и только потом использовать эти данные как входные для слоя делегирования полномочий агентного ИИ. Без первых двух шагов третий не имеет смысла. Именно эта последовательность, по сути, и является тем мостом, которого не хватает между классическим IAM и безопасным внедрением агентного ИИ в корпоративную среду.


Новое на сайте

20327Кости прерий: как истребление бизонов породило целую индустрию — и сама себя же уничтожила 20326Кто и зачем взламывает серверы Ollama и ComfyUI ради ключей от AWS? 20325Как злоумышленники спрятали командный сервер внутри блокчейна и почему его невозможно... 20324Брюссель заставляет Android делиться секретами с чужими ИИ-помощниками 20323WordPress: как два бага слились в одну критическую дыру, которую назвали wp2shell 20322Как китайские хакеры обманули DigiCert и украли сертификаты для подписи кода? 20321Что скрывается за уязвимостью, которую агентство США внесло в список активно используемых... 20320Автономные системы наступают быстрее, чем инфраструктура для управления ими: кто выиграет... 20319Почему в OpenSSL нашли дыру, съедающую память серверов, но не дали ей даже номер CVE? 20317SonicWall SMA 1000: как два бага превратили VPN-шлюз в бэкдор для атакующих 20316Может ли уязвимость в клиенте Zoom для Windows открыть доступ к чужому аккаунту без... 20315TELEPUZ: новый вредонос на C, который научился прятаться в Telegram, Steam и блокчейне... 20314Дома из дёрна: как исландцы триста лет прятались от холода под слоем земли и травы 20313Как один токен от чужого сервиса мог впустить злоумышленника в чужой аккаунт n8n?
Ссылка