Если вы читаете это, вы, вероятно, потратили немалую часть своей карьеры на то, чтобы отбирать права администратора у людей, которые были твердо уверены, что они им нужны. Большинство из нас заплатили за принцип наименьших привилегий на конечных точках билетами, эскалациями и несколькими неприятными встречами, наблюдали, как список исключений вырастает из пяти записей во что-то, требующее отдельного владельца, и все же добились своего. А потом появились агенты для написания кода.
Теперь у каждого разработчика есть неутомимый коллега, работающий в его сеансе, запускающий оболочки, устанавливающий пакеты и редактирующий файлы десятки раз в минуту. Вопрос, который я постоянно слышу от коллег и задавал себе самому, заключается в том, требует ли это принципиально новой категории средств контроля.
Потратив несколько месяцев на изучение этого вопроса, чтение того, что написали наши инженеры, и споры с коллегами, я пришел к выводу, что уже имеющиеся у нас подходы охватывают большую часть проблем, если применять их к новому типу пользователей, которые не спят и очень быстро печатают.
Основные выводы:
- Локальные ИИ-агенты запускаются от имени вошедшего в систему пользователя с тем же токеном, файлами, учетными данными и сеансами. В 96% организаций этот доступ далеко выходит за рамки того, что требуется для выполнения ролей.
- Хуки отвечают на вопрос, должно ли определенное действие агента состояться. Принцип наименьших привилегий отвечает на вопрос, насколько сильно может навредить любое действие. Зрелая программа использует и то, и другое.
- Привилегии и область действия определяют радиус поражения. Удаление постоянных прав администратора — это самый быстрый выигрыш как для людей, так и для агентов.
- Следите за деревом процессов, потому что ущерб обычно наносится в дочерних процессах агента.
Ниже описано, как я пришел к этому выводу. Здесь будет немного технических деталей продуктов, потому что я работаю там, где работаю, но я постараюсь приводить их там, где они полезны, а в разделе часто задаваемых вопросов в конце приведены справочные материалы для всех (или чего угодно), кому они понадобятся.
Как агент выглядит для операционной системы
Если убрать окно чата, агент окажется вполне обычной программой.
Claude Code помещает подписанный бинарный файл в %USERPROFILE%\.local\bin и хранит свои настройки в %USERPROFILE%\.claude. Codex CLI и значительная часть его аналогов устанавливаются через npm и работают как обычный node.exe. Cursor устанавливается в %LOCALAPPDATA%\Programs\cursor. Ни один из них не требует прав администратора для установки, а в macOS и Linux они точно так же размещаются в домашнем каталоге. Аудит папки Program Files и списка установленных приложений часто пропускает их, потому что, хотя некоторые установщики для конкретных пользователей действительно регистрируются в HKCU, версии, поставляемые через npm и портативные варианты, не оставляют там никаких следов.
После запуска агент не получает собственной идентичности. Он работает от имени вошедшего в систему пользователя, используя его токен, файлы, сохраненные учетные данные, сетевые ресурсы и сеансы единого входа (SSO), поэтому у операционной системы нет отдельного субъекта для анализа. Из-за этого также трудно по логам определить, исходило ли конкретное действие от человека или от агента, работающего от его имени, и я подозреваю, что фраза «это был не я, офицер, это агент» станет привычной при разборе инцидентов. С точки зрения операционной системы, это был он.
Агент также редко работает в одиночку. Одна инструкция вроде «исправь падающий тест» может породить дерево процессов, состоящее из node, npm, git, одной или двух оболочек и пары локальных серверов протокола контекста модели (MCP), и каждое из них является дочерним процессом с тем же токеном, читающим и пишущим данные в файловой системе и обращающимся к сети в течение нескольких секунд.
Таким образом, модель угроз выглядит пугающе знакомо. Будь то агент вайб-кодинга, переживающий творческий полдень, или злоумышленник, перемещающийся латерально из скомпрометированного фишингом сеанса, оба наследуют привилегии вошедшего в систему пользователя. Исследования показывают, что человеческие учетные записи действуют с доступом, далеко выходящим за рамки того, что требуется по их ролям, и агент забирает весь этот избыток в первый же день.
Внимательный читатель возразит, что агент спрашивает разрешения перед каждой командой. Многие действительно спрашивают по умолчанию — ровно до третьего дня, когда кто-то нажимает «всегда разрешать» для инструмента оболочки, потому что запросы мешают работе, и мы все знаем, чем заканчивается эта история.
Два разных вопроса: безопасность на основе хуков против принципа наименьших привилегий
Растущий класс средств безопасности, ориентированных на агентов, работает изнутри самого агента. Современные фреймворки агентов предоставляют хуки жизненного цикла: перед запуском инструмента агент передает запланированный вызов внешней программе, которая может разрешить его, отклонить или изменить, а инструменты безопасности подключаются к этим хукам, чтобы применять политику к тому, что агент собирается сделать. Такая позиция дает им то, чего нет больше ни у кого на компьютере, а именно контекст. Они знают, какой инструмент MCP был вызван, с какими аргументами, в каком сеансе и часто какой запрос привел к этому, поэтому они могут делать выводы о намерениях, остановить рискованное действие на условиях самого агента и вести журнал, понятный проверяющему человеку.
Вопрос, на который отвечает хук, заключается в том, должно ли это конкретное действие от этого конкретного агента происходить. Это хороший вопрос, и я хочу знать на него ответ. Работая с этим, однако, я постоянно возвращался ко второму вопросу, который находится на уровень ниже и к которому хуки по своей конструкции не имеют прямого отношения: когда действие все же происходит — независимо от того, было ли оно одобрено, оценено неверно или вообще обошлось без агента, — насколько сильно оно может навредить?
Некоторые свойства конечной точки затрудняют игнорирование этого второго вопроса:
- Работа происходит в процессах, запускаемых агентом. npm install выполняет любой скрипт postinstall, поставляемый с пакетом, а агент, который пишет fix.py, а затем запускает python fix.py, сообщает о совершенно обычной командной строке. Что эти процессы будут делать дальше, определяется их токеном и операционной системой.
- Агенты — это упорные решатели проблем. Традиционное программное обеспечение останавливается и выдает ошибку при столкновении с препятствием, и любой, кто наблюдал за работой агента по написанию кода в течение полудня, видел, как он воспринимает ту же преграду как еще одну задачу для решения, пробуя cmd /c del после Remove-Item, а после этого написания небольшой программы. Ограничение возможностей действует независимо от того, какой путь выберет агент.
- Множество вещей на конечной точке действуют от имени пользователя, не будучи агентом. Самодельный скрипт, созданный на базе открытого фреймворка, загруженный кем-то портативный инструмент, вредоносное ПО или злоумышленник, находящийся в скомпрометированном фишингом сеансе, наследуют тот же токен и не имеют причин объявлять о своих планах кому бы то ни было.
- Одобренное действие выполняется с токеном процесса. Когда действие разрешено, оно выполняется с теми правами, которыми обладает процесс, поэтому на машине, где пользователь является локальным администратором, одобренное действие является действием администратора.
Именно этот последний момент стал для меня ключевым, поэтому позвольте мне остановиться на нем подробнее.
У радиуса поражения есть два регулятора
Подумайте о том, что на самом деле идет не так с агентами: внедрение промпта (prompt injection), скрытое в README, зараженный сервер MCP, модель, которая неправильно истолковала команду «очистить папку сборки», или злоумышленник, который просто перехватил сеанс. Сценарий, который кажется мне наиболее интересным, — наименее драматичный, когда любопытный или откровенно раздраженный сотрудник просит агента «упростить» какой-то процесс, который постоянно мешает ему работать.
Представьте разработчика, у которого сборка еле ползет из-за того, что защита конечных точек (endpoint protection) сканирует каждый файл. Он просит агента ускорить сборку, и агент заботливо выполняет команду Add-MpPreference -ExclusionPath для всей папки репозитория. На компьютере, где этот разработчик является локальным администратором, исключение добавляется без лишнего шума, и сборка действительно становится быстрее — как и для всего остального, что с этого момента попадает в эту папку.
На компьютере, где он является обычным пользователем, агент получает отказ в доступе и возвращается с сообщением, что не смог этого сделать. Ни в одной из версий этой истории нет злого умысла, и каждый шаг выглядит как обычная IT-работа — именно поэтому первую версию так легко упустить из виду.
Когда я впервые набросал этот аргумент, я построил его исключительно вокруг прав администратора, но коллега быстро указал на брешь в этой логике: большинство резонансных и дорогостоящих инцидентов с агентами, о которых мы слышим, вообще не требовали прав администратора. Удаленный репозиторий, папка .ssh и учетные данные ~/.aws, опубликованные там, где им не место, или творчески использованная активная SaaS-сессия — все это легко происходит в рамках прав обычного пользователя.
Поэтому теперь я представляю радиус поражения в виде двух регуляторов.
Первый — это привилегии, то есть то, что процесс способен изменить на машине, а второй — это охват, то есть то, к чему он может прикоснуться от имени пользователя: файлы, ключи, сетевые ресурсы и сетевые назначения. Некоторые сбои будут перехвачены на уровне агента, а некоторые в момент выполнения будут выглядеть совершенно обоснованно. Размер кратера каждый раз определяется тем, как были установлены эти два регулятора.
Размер кратера каждый раз определяется тем, как были установлены эти два регулятора.
Размер кратера каждый раз определяется тем, как были установлены эти два регулятора.
Агент с правами администратора может изменять системные файлы, устанавливать ПО, менять настройки безопасности, создавать локальных пользователей и запускать утилиты с повышенными привилегиями, тогда как агент, работающий от имени обычного пользователя, ограничен теми же рамками, что и учетная запись. Перехватчик определяет, что агент должен делать, в то время как привилегии и охват определяют, что любой процесс может делать, при этом второе правило действует даже тогда, когда к первому вообще не обращаются.
Хорошая новость заключается в том, что большинству агентов права администратора вообще не нужны. Чтение файлов, написание кода, запуск команд уровня пользователя и взаимодействие с репозиториями и облачными API прекрасно работают от имени обычного пользователя, поэтому регулятор привилегий можно убавить без ущерба для нужной функциональности. С регулятором охвата все сложнее, так как агенту обоснованно требуется доступ к части того, к чему имеет доступ пользователь, хотя я еще не встречал ассистента для кодинга, у которого была бы веская причина читать хранилище паролей браузера.
На практике убавление обоих регуляторов для агентов сводится к четырем вопросам, где первые два касаются привилегий, а последние два — охвата. Я опишу, как мы отвечаем на них в Idira Endpoint Privilege Manager (EPM), так как знаю продукт лучше всего, но сами вопросы универсальны.
Что может запускаться и для кого
Большинство агентов устанавливаются в профиль пользователя, поэтому политика должна явно ориентироваться на это расположение. Наш подход использует три уровня. Верхний уровень применяет базовые ограничения ко всем установленным пользователем приложениям, которые еще никто не оценивал: никакого запуска PowerShell, cmd или wscript, никакого доступа к хранилищам учетных данных и инструментам безопасности, никакой записи в память других процессов.
Средний уровень — это список разрешений (allowlist) для проверенных инструментов, идентифицируемых по расположению, подписи издателя, исходному имени файла или хэшу, при этом каждый одобренный инструмент получает собственную политику. Большинство агентов для кодинга малополезны без командной строки, поэтому стандартный выбор для одобренного агента — разрешить ему использовать ее без повышения привилегий и с ограниченным охватом, а полный запрет командной строки оставить для инструментов, которым она не требуется.
Нижний уровень начинает работу в режиме обнаружения (discovery mode), фиксируя, к чему обращаются установленные пользователем приложения, а затем переключается в режим запрета по умолчанию (default deny). С этого момента любой новый инструмент или агент, появившийся в профиле пользователя, остается заблокированным до проверки, в то время как обновления уже одобренных инструментов продолжают работать, если список разрешений сопоставляет их по издателю и другим стабильным критериям, а не по одиночному хэшу файла.
Предупреждение из опыта: разработчики целыми днями собирают и запускают собственные исполняемые файлы в своем профиле, поэтому спланируйте исключения для результатов сборки (build output) до того, как переключите тумблер — если только вы не любите очень оживленные утра понедельника.
Какие привилегии он получает
Откажитесь от постоянных прав администратора у людей, и агент также их лишится. Кроме того, ИИ-инструменту можно разрешить запуск только с обычными правами и запретить запуск с повышением привилегий, получение автоматического повышения или передачу повышения своим дочерним процессам. Если конкретная задача действительно требует повышения привилегий, вы предоставляете его для этой задачи через тот же процесс согласования, который уже используете для людей.
К чему он может получить доступ
Разрешение на запуск ничего не говорит о том, к чему инструмент может прикоснуться. Управление доступом приложений (Application Access Control) задает границы для каждого приложения по пяти категориям: узлы интернета и интранета, сетевые ресурсы, локальные файлы, ключи реестра и память других процессов. Каждая категория начинается с режима обнаружения (Detect), чтобы вы узнали, что инструмент делает на самом деле, а затем переходит в режим ограничения (Restrict). Запись в память можно сразу перевести в Restrict, поскольку ни одному легитимному ассистенту для кодинга не нужно писать в память другого процесса. Типичные кандидаты на ограничение доступа к файлам — это .ssh, Диспетчер учетных данных (Credential Manager), мастер-ключи DPAPI и хранилища паролей браузеров.
Для MCP-серверов, которым нужна рабочая директория, настройте Application Access Control в политике агента так, чтобы разрешить папку проекта и ограничить доступ к конфиденциальным путям. При включенном наследовании дочерними процессами (child process inclusion) эти ограничения применяются к агенту и его дочерним процессам, оставляя при этом пользователю возможность доступа к этим ресурсам через другие приложения.
Что наследуют его дочерние процессы
Это именно та часть, о которой люди часто забывают, а ведь вся интересная работа происходит именно там — в дочерних процессах, поэтому политика должна следовать по всему дереву. При включенном наследовании дочерними процессами процессы node, npm, git и MCP-серверов, порождаемые агентом, подпадают под те же правила контроля доступа и тот же аудит, а попытка запустить экземпляр PowerShell блокируется, если вы решили, что этому конкретному агенту он не нужен.
Все это соблюдается на уровне операционной системы, за пределами агента. Это работает без каких-либо изменений в самом агенте и обрабатывает действие одинаково, независимо от того, исходило ли оно от модели, пользователя или кого-то, кто похитил сессию. Это тот же набор политик, который мы уже используем для людей.
Что принцип наименьших привилегий не решает для ИИ-агентов
Предпочитаю сказать об этом сам, чем дать вам узнать об этом в процессе проверки концепции (POC).
Агент по-прежнему не является отдельным субъектом безопасности. Если пользователь может открыть общий ресурс отдела кадров, то и агент тоже, если вы специально не ограничите доступ этого приложения к общим ресурсам. Элементы управления привилегиями не читают подсказки, не оценивают рассуждения модели и не проверяют содержимое данных, покидающих систему через разрешенный канал. Аудит показывает, какой инструмент был запущен, к чему он прикасался или пытался прикоснуться и какие правила сработали, хотя он и не объяснит, почему модель решила так поступить. Средства контроля на уровне процессов также зависят от надежной идентификации процесса искусственного интеллекта.
Подписанный нативный бинарный файл проверить легко, в то время как агент, поставляемый через npm, работает как node.exe, подписанный издателем Node.js, и для того, чтобы отличить его от любого другого приложения Node на машине разработчика, требуется более тщательный подход к учету местоположения, исходного имени файла и хэшей. Честно говоря, это одна из самых сложных сторон. Кроме того, готовый к импорту фреймворк изоляции на данный момент ориентирован в первую очередь на Windows.
Именно поэтому я рассматриваю хуки и привилегии как два уровня одной программы, каждый из которых выполняет задачу, для которой не был создан другой. Хуки дают понимание намерений: что именно агент пытался сделать и зачем. Привилегии обеспечивают надежную основу, которая срабатывает всякий раз, когда какое-то решение выше по уровню оказывается неверным, и распространяются на каждый процесс на конечной точке — будь то агент или что-то еще. Зрелой программе нужны оба ответа.
Привилегии обеспечивают надежную основу, которая срабатывает всякий раз, когда какое-то решение выше по уровню оказывается неверным.
Привилегии обеспечивают надежную основу, которая срабатывает всякий раз, когда какое-то решение выше по уровню оказывается неверным.
Еще одна мысль из наших собственных слайдов не выходит у меня из головы: идентичность — это самый эффективный инструмент контроля, которым мы располагаем, но достаточно ли он быстр теперь, когда то, что раньше занимало дни, теперь делается за минуты?
Полезное свойство элементов управления привилегиями заключается в том, что их можно автоматизировать, не портя жизнь пользователю. Когда SOC замечает что-то неладное, плейбук может перевести эту конечную точку в более строгий режим (отзвать права администратора, заблокировать любое повышение привилегий, заблокировать неподписанные и только что загруженные исполняемые файлы), пока пользователь продолжает работать. Изоляция хоста сопряжена со столькими сложностями, что многие команды оставляют для нее человека в контуре, тогда как отнять права администратора у агента — это то, что плейбук может сделать в 3 часа ночи, никого не будя.
Мои выводы вкратце
- Агент — это новый тип пользователя, использующий старый тип токена, и ограничение как того, что этот токен может изменять, так и того, к чему он может получать доступ, решает задачу по большей части.
- Хуки отвечают на вопрос, должно ли произойти конкретное действие агента, привилегии отвечают на вопрос, насколько сильно может навредить любое действие, а зрелая программа отвечает на оба вопроса.
- Привилегии и область доступа в совокупности определяют радиус поражения, а удаление постоянных прав администратора — это мера, которая приносит максимальную пользу как людям, так и агентам.
- Запрет по умолчанию для новых исполняемых файлов в профиле пользователя — это самый практичный ответ на скорость выпуска агентов, при условии, что вы заранее спланируете исключения для результатов сборки разработчиков.
- Следите за деревом процессов, так как ущерб обычно наносится в дочерних процессах агента.
- Начните с обнаружения (Detect) и переходите к ограничению (Restrict), когда поймете, как выглядит нормальное поведение, потому что две недели логов научат вас об агентах больше, чем любой бриф вендора, включая этот.
Агент — это новый тип пользователя, использующий старый тип токена.
Агент — это новый тип пользователя, использующий старый тип токена.
Ну, вот и все
Если вы дочитали до этого места — спасибо. В следующий раз, когда разбор инцидента дойдет до момента, кто-то скажет: «Это был не я, начальник», я надеюсь, в логах будет виден агент, который работал как стандартный пользователь и которому было некуда пойти. Если вы хотите посмотреть, что происходит, когда ему все-таки есть куда пойти, Шай Нахари (Shay Nahari) и Брайан Мерфи (Bryan Murphy) из Unit 42 разбирают реальные атаки с использованием агентов.
Часто задаваемые вопросы
Что такое локальный ИИ-агент на конечной точке?
Локальный ИИ-агент — это приложение, установленное на рабочей станции пользователя, которое планирует и выполняет многоэтапные задачи автономно путем вызова таких инструментов, как командные оболочки, интерпретаторы скриптов, пакетные менеджеры, компиляторы и серверы MCP (Model Context Protocol). Распространенными примерами являются Claude Code (Anthropic), Cursor (Anysphere), GitHub Copilot в IDE и CLI (GitHub/Microsoft), OpenAI Codex CLI, Google Antigravity и Amazon Q Developer (AWS). Большинство из них устанавливаются в профиль пользователя без административных прав, например %USERPROFILE%\.claude, %USERPROFILE%\.codex или %LOCALAPPDATA%\Programs\cursor в Windows, а также ~/.claude или ~/.cursor в macOS и Linux. Контроль приложений, ориентированный только на системные директории, не обнаруживает и не ограничивает эти инструменты.
Какие удостоверения и привилегии использует локальный ИИ-агент?
Локальный ИИ-агент работает от имени вошедшего в систему пользователя. Операционная система не создает для него отдельную учетную запись, маркер безопасности или границу доверия. Агент наследует разрешения пользователя, файлы, сохраненные учетные данные, доступ к сетевым ресурсам и аутентифицированные сеансы. Если пользователь является локальным администратором, агент обладает правами администратора. Каждый дочерний процесс, запускаемый агентом (оболочки, интерпретаторы, менеджеры пакетов, MCP-серверы), наследует тот же токен. Поскольку агент работает в сеансе пользователя, в журналах сложно отличить действия, инициированные агентом, от действий, инициированных пользователем.
Почему принцип наименьших привилегий является основным средством контроля для ограничения радиуса поражения ИИ-агентов?
Ущерб, который может нанести ИИ-агент, ограничен привилегиями процесса, в котором он запущен. Агент с правами администратора может изменять файлы операционной системы, устанавливать программное обеспечение, изменять настройки безопасности, создавать локальных пользователей, получать доступ к защищенным ресурсам и запускать повышенные в правах утилиты. Агент, работающий с правами обычного пользователя, ограничен возможностями обычной учетной записи. Таким образом, принцип наименьших привилегий снижает воздействие каждого типа сбоев одновременно: ошибки модели, неправильной конфигурации, благонамеренных запросов пользователя (например, просьбы к агенту «упростить» процесс), которые приводят к отключению средств безопасности в качестве побочного эффекта, инъекции промпта, вредоносного или скомпрометированного MCP-сервера, скомпрометированного ИИ-приложения и злоумышленника, действующего внутри сеанса пользователя. Этот элемент контроля применяется независимо от того, какой агент задействован и как именно сформулировано или обфусцировано то или иное действие. Большинству ИИ-агентов не нужны административные права для их обычной работы, которая включает чтение файлов, генерацию кода, выполнение команд пользовательского уровня, доступ к репозиториям и вызовы облачных служб.
Что такое безопасность ИИ-агентов на основе хуков?
Безопасность ИИ-агентов на основе хуков интегрируется с хуками жизненного цикла, которые предоставляют некоторые фреймворки ИИ-агентов, например хуки, запускаемые перед выполнением вызова инструмента. Агент передает запланированное действие (например, команду оболочки, запись файла или вызов инструмента MCP с его аргументами) внешней программе, которая может разрешить, запретить или изменить его в соответствии с политикой. Главное преимущество такого подхода заключается в семантическом контексте: он позволяет видеть, какой инструмент агент собирается использовать, с какими параметрами, и часто видит запрос или сеанс, приведший к этому действию. Это делает его хорошо приспособленным для оценки того, подходит ли конкретное действие агента, и для создания журнала активности на уровне агента.
Какую задачу решает безопасность на основе хуков, а какую — принцип наименьших привилегий?
Безопасность на основе перехвата (hook-based security) и принцип наименьших привилегий решают разные задачи и дополняют друг друга. Безопасность на основе перехвата определяет, следует ли разрешить конкретное действие, запрашиваемое поддерживаемым ИИ-агентом, используя собственный контекст агента. Принцип наименьших привилегий определяет, какой ущерб может нанести любой процесс на конечной точке после выполнения действия — независимо от того, было ли действие одобрено, оценено неверно или вообще не проходило через агента. Принцип наименьших привилегий важен на этом втором уровне по четырем причинам:
- Последствия действий агента часто проявляются в запускаемых им процессах, таких как скрипты установки пакетов или созданный и затем выполненный агентом файл скрипта. Эти процессы регулируются их токеном и операционной системой.
- ИИ-агенты ориентированы на достижение целей и могут пытаться найти альтернативные пути после получения отказа (например, другую команду, интерпретатор или заново написанную программу). Ограничение возможностей распространяется на каждый путь.
- Многие процессы действуют от имени пользователя, не будучи при этом ИИ-агентами, включая пользовательские скрипты, портативные утилиты, вредоносное ПО и злоумышленников, действующих в рамках сеанса пользователя.
- Разрешенное действие выполняется с полными привилегиями процесса. Сокращение этих привилегий снижает последствия каждого разрешенного действия.
Рекомендуемый подход заключается в использовании обоих уровней, где базовым является принцип наименьших привилегий.
Как Idira EPM управляет ИИ-агентами на конечных точках?
Idira Endpoint Privilege Manager от Palo Alto Networks управляет ИИ-агентами с помощью той же модели политик, которая используется для людей и приложений, посредством четырех элементов управления:
- Контроль приложений: какие инструменты ИИ могут запускаться и для каких пользователей, групп или ролей. Неутвержденные инструменты могут быть заблокированы.
- Контроль привилегий: отмена постоянных прав локального администратора; инструменты ИИ можно разрешить запускать только с обычными правами и предотвратить их запуск от имени администратора, автоматическое повышение прав или наследование прав администратора. Повышение прав может предоставляться для конкретных задач при наличии обоснования.
- Контроль доступа к приложениям: ограничения для каждого отдельного приложения в отношении интернет- и интранет-ресурсов, сетевых папок, локальных файлов, разделов реестра (Windows) и доступа на запись в память других процессов.
- Контроль дочерних процессов: политики, ограничения доступа и аудит распространяются на каждый процесс, порождаемый ИИ-агентом, включая серверы MCP, с возможностью блокировки дочерних процессов высокого риска, таких как PowerShell или cmd.
Эти элементы управления применяются на уровне операционной системы, независимо от ИИ-приложения, и не требуют никаких изменений в самом ИИ-инструменте или его конфигурации.
Что представляет собой трехслойная структура Idira EPM для устанавливаемых пользователем ИИ-агентов?
Трехслойная структура представляет собой набор политик EPM для приложений, которые устанавливаются и запускаются из профиля пользователя, включая большинство ИИ-агентов. Слои применяются в порядке приоритета:
- Уровень 1: элементы управления для снижения рисков применяются ко всем приложениям пользователя, независимо от того, утверждены они или нет. Ограничивает запуск интерпретаторов высокого риска (PowerShell, cmd.exe, wscript.exe), доступ к хранилищам учетных данных Windows и компонентам безопасности, доступ на запись в память других процессов, а также доступ к чувствительным инструментам безопасности ОС. Это ограничивает ущерб еще до того, как инструмент был оценен, включая инструменты, подвергшиеся манипуляциям через внедрение промптов (prompt injection).
- Уровень 2: белый список утвержденных ИИ-агентов; оцененные инструменты освобождаются от Уровня 1 и выполняются с правами доступа, определенными в их собственной политике.
- Уровень 3: обнаружение с последующим запретом по умолчанию. Политика «UBA Layer 3 - Discovery of User-Based Apps» позволяет приложениям пользователя работать в режиме обнаружения (Detect mode) для регистрации их доступа во время оценки. Политика «UBA Layer 3 - Default Deny for User-Based App» затем блокирует любые пользовательские приложения, отсутствующие в белом списке Уровня 2, включая инструменты ИИ, выпущенные после настройки политики.
