ИИ-агент как сотрудник: права, журнал и BearPass

Большинство компаний заводят ИИ-агента в инфраструктуру так же, как подключают новый удобный сервис. Создают сервисную учётную запись, выдают долгоживущий API-ключ, иногда сразу с правами администратора, потому что иначе «что-то не работает». Подключают к репозиторию, таск-трекеру, корпоративной вики и идут заниматься следующей задачей. Через полгода уже никто не помнит, какие именно секреты лежат у агента и к каким сервисам он может обратиться. Если такую учётную запись скомпрометируют, радиус поражения не контролирует никто.

Проблема в том, что ИИ-агент в продакшене — это не просто инструмент. Это субъект, который держит у себя секреты, ходит по корпоративным API, читает входящие данные из непроверенных источников и сам принимает решения о вызове функций. Работает он круглосуточно, в десятки раз быстрее человека и принципиально не способен оценить, кому именно он сейчас помогает. Если посмотреть на агента как на сотрудника, картина становится понятнее: ему, как и человеку, нужны онбординг с минимальными правами, контроль операций с журналом, kill switch и офбординг. По структуре это четыре процесса, которые давно есть для людей; по содержанию для агентов они отличаются.

Почему промпт-инъекцию нельзя починить на уровне модели

Ключевая особенность ИИ-агента в том, что он интерпретирует входящие данные как инструкции. У большой языковой модели нет надёжного способа отличить команду разработчика от текста, который пришёл из письма, комментария к задаче или веб-страницы. Любой обработанный контент потенциально является инструкцией. Это и есть промпт-инъекция (prompt injection), и на уровне самой модели она пока не решается. Сам термин «инъекция» в безопасности значит «впрыскивание»: злоумышленник подсовывает системе свой текст так, что система принимает его за команду, а не за обычные данные. Название пошло от старой атаки SQL-инъекции, где вредоносный текст в поле ввода превращался в команду к базе данных.

Удобную рамку предложил исследователь Саймон Уиллисон, сформулировавший само понятие промпт-инъекции. Его модель называется lethal trifecta (смертельная триада). Критический риск возникает, когда у агента одновременно сходятся три условия: доступ к недоверенным входным данным, привилегированный доступ к ценным ресурсам и возможность отправить данные наружу. Если все три свойства присутствуют в одной сессии, агент структурно уязвим к краже данных, и никакая настройка системного промпта это не отменяет.

Смертельная триада: при наличии всех трёх свойств агент структурно уязвим

Это не теория. За 2025 и начало 2026 года исследователи и вендоры задокументировали целый класс атак, в которых агент читает скрытые инструкции из внешнего источника и выполняет их. Классический пример: атакующий оставляет инструкции в комментарии к issue в публичном репозитории, агент через MCP-сервер читает их, открывает pull request в приватный репозиторий и выкладывает туда содержимое чужих проектов. Особенно опасны утечки секретов из CI/CD: в 2025 году скомпрометированная зависимость tj-actions/changed-files (CVE-2025-30066) засветила секреты в логах сборки более чем 23 000 проектов. Массового вывода этих секретов наружу зафиксировано не было, но логи публичных репозиториев доступны всем, и засвеченные доступы пришлось спешно ротировать.

Важная оговорка: кража данных — не единственный исход. Даже без канала на экспорт промпт-инъекция может заставить агента совершить вредное действие в рамках уже выданных прав: удалить записи, перевести средства, опубликовать или перезаписать данные, поменять конфигурацию. Meta (организация признана экстремистской организацией и запрещена в РФ) в своём фреймворке прямо относит к рискам действия от имени пользователя и нарушение работы системы, а не только утечку. Журнал и kill switch такие сценарии частично закрывают, но проектировать защиту нужно с расчётом и на вредное действие, а не только на вывод данных.

Фильтры и классификаторы ловят известные шаблоны, но их обходят простым перефразированием — собственные классификаторы Microsoft на практике обходили. Уиллисон формулирует планку жёстко: в прикладной безопасности даже 99% перехвата — это провал, потому что атакующему достаточно одной прошедшей попытки. Вопрос не в том, можно ли защитить агента на уровне модели — нельзя. Вопрос в том, что произойдёт, когда инъекция сработает.

Фильтры ловят известные шаблоны, но не закрывают проблему

Агент — это новый тип учётной записи

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

Подход Meta (организация признана экстремистской организацией и запрещена в РФ) к этой проблеме, Agents Rule of Two, формулирует ту же мысль: пока промпт-инъекцию нельзя надёжно детектировать, в одной сессии агенту стоит давать не более двух из трёх опасных свойств триады. Отрезать одну из ножек — например, лишить агента возможности экспортировать данные наружу или жёстко ограничить набор ресурсов.

Четыре процесса жизненного цикла агентской учётной записи

Онбординг: что значит «минимальные права» для агента

Принцип least privilege (минимально необходимых прав) кажется банальностью, пока вы не начинаете применять его к ИИ-агенту. Агенту нужно прописать всё на уровне политик и токенов, потому что любая неоднозначность будет интерпретирована моделью, и не обязательно в вашу пользу.

Отдельная сервисная учётная запись на каждую роль агента. Никаких общих ключей между агентом код-ревью и агентом деплоя — иначе вы получаете концентрацию рисков в одной точке, которую невозможно изолировать при инциденте.

Привязка прав к конкретной задаче. Если агент проверяет pull request, ему не нужен доступ на запись в основную ветку. Если собирает релиз — не нужны учётные данные продакшен-базы.

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

Ограничение scope и изоляция окружений. Токен с доступом только к одному репозиторию или таблице при компрометации не даёт атакующему ничего лишнего. А агент с тестовым контуром не должен по ошибке достать секрет из продакшена.

Контроль операций: журнал, который кто-то действительно читает

В классическом управлении доступом журнал событий — вспомогательная функция. Для ИИ-агента журнал — первичный механизм безопасности, потому что у агента нет понятного человеку намерения, по которому можно отличить нормальную работу от компрометации. Запрос пароля от продакшена в три часа ночи от сотрудника очевидно подозрителен. Тот же запрос от агента может быть и легитимной фоновой задачей, и последствием инъекции.

В журнал на каждый вызов должны попадать идентификатор агента и его роль, источник запроса, какие секреты запрошены и из какого хранилища, какой scope имели токены и какие действия выполнены. Эти события нужно сразу отправлять в SIEM — локальный лог на раннере будет уничтожен вместе с контейнером. KUMA, MaxPatrol SIEM, QRadar и Splunk при правильной настройке ловят аномалии: всплеск запросов к секретам, обращение к ресурсу, к которому агент раньше не обращался, scope за рамками нормы.

Kill switch: что делать, когда уже поздно

Допустим, инъекция сработала и атакующий получил рабочий токен. Дальше четыре шага. Первое — отозвать токен; эфемерный решает половину проблемы автоматически. Второе — отозвать все активные сессии агента; это и есть kill switch, одна команда со временем срабатывания в минуты, а не часы. Третье — поднять журнал и понять, что произошло между инъекцией и отключением. Четвёртое — оценить утечку и запустить процедуры.

Если в скомпрометированных секретах были учётные данные к системам с персональными данными, по 152-ФЗ на уведомление Роскомнадзора отводится 24 часа, а штраф за нарушение срока доходит до трёх миллионов рублей. Ограничение прав на этапе онбординга — это инвестиция в скорость восстановления и в размер возможного штрафа.

Офбординг: единственный сценарий, который точно случится

Любой агент рано или поздно выводится из работы. Если онбординг был сделан правильно, офбординг занимает минуты. Если нет — остаются зомби-учётки с действующими токенами, к которым непонятно какие доступы привязаны. Чек-лист короткий: отозвать все токены, удалить учётную запись из хранилища секретов, снять роли, заархивировать журнал, уведомить команды.

Про регуляторику отдельно. Приказ ФСТЭК №117, заменивший №17 и вступивший в силу 1 марта 2026 года, не выделяет ИИ-агентов в отдельную категорию, но требования к идентификации, журналу и разграничению доступа применяются ко всем учётным записям, включая сервисные. Всё, что выстроено под 117 приказ, должно закрывать и работу с агентами.

Как это реализуется на практике

Опишу подход на примере BearPass, потому что в этом продукте процессы выстроены вокруг описанных принципов. Я не сравниваю продукты, а показываю, что общая модель реализуема штатными средствами и не требует писать собственное хранилище секретов с нуля.

Каждое требование к безопасности агента закрывается конкретным механизмом BearPass

Сервисная учётная запись агента создаётся как отдельный объект с собственной ролью RBAC. Агент код-ревью получает доступ к одной папке с токенами к нужному репозиторию и LLM-провайдеру; доступа к продакшен-базе у него нет физически. Выдача токенов идёт через REST API с аутентификацией по JWT через OpenID Connect: агент запрашивает временный токен с указанием scope и срока жизни, хранилище проверяет право на scope, выдаёт короткоживущий токен и фиксирует выдачу в журнале. Никаких долгоживущих ключей в окружении раннера.

Журнал каждого обращения уходит в syslog в формате SIEM (KUMA, MaxPatrol SIEM, QRadar). Поверх работает модуль «Правила»: если агент запросил доступ к секрету, которым раньше не пользовался, или scope резко вырос — уведомление, замедление выдачи, в строгом режиме автоматическое отключение. Kill switch отзывает доступы агента в один клик, поддерживаются массовые операции и отзыв на уровне роли. Офбординг — это удаление учётки и роли; журнал сохраняется отдельно для ретроспективного анализа.

Для соответствия: BearPass состоит в реестре российского ПО под номером 15427, поддерживает ГОСТ и AES-256-GCM, разворачивается on-premise за час-два на Astra Linux, РЕД ОС, Debian или Ubuntu, в том числе в закрытом контуре.

Вывод

ИИ-агент — это новый тип учётной записи. Не инструмент, не интеграция, а учётная запись с особенностями, которые требуют отдельных процессов управления доступом: онбординг с минимальными правами, эфемерные ограниченные по scope токены вместо вечных ключей, журнал в SIEM как первичный механизм безопасности, kill switch со срабатыванием в минуты и предсказуемый офбординг.

Промпт-инъекцию на уровне модели в обозримом будущем не починят. Времени на «подождём, пока всё устаканится» нет. Базовая гигиена работы с агентами как с учётными записями закрывает большую часть рисков уже сейчас, штатными средствами парольного менеджера корпоративного класса. Посмотреть механизмы в интерфейсе можно на demo.bearpass.ru, развернуть бесплатную версию для команды до пяти пользователей на bearpass.ru/start