Кто такой этот ИИ-агент в вашей системе: почему создание ИИ-агента для бизнеса начинается с бейджа, а не с промпта

Однажды у нас был честный разговор с безопасниками заказчика. Мы пришли показывать свежесобранного ИИ-агента, который умеет читать 1С, писать в CRM и отправлять письма клиентам. Первый вопрос от безопасника был не про модель, не про MCP и не про качество ответов. Он спросил: «А под каким пользователем он у вас туда ходит?» И тут выяснилось, что это самый неудобный вопрос, который нам могли задать.

Ходил агент под сервисной учёткой с широкими правами, ключи были прописаны в переменных окружения, срок жизни у них — «пока не поменяем руками». То есть в системе, по сути, завёлся новый сотрудник — с доступом почти ко всему, без обучения, без испытательного срока, и уволить его можно только вручную выдёргиванием ключа. Разговор закончился тем, что мы уехали доделывать не агента, а его identity. С тех пор у нас правило: создание ИИ-агента для бизнеса не начинается с выбора модели. Оно начинается с двух вопросов — под кем он ходит и как ему отзовут доступ.

ИИ-агент что это с точки зрения безопасника

Для инженера ИИ-агент — это оркестратор с планировщиком, инструментами через MCP, памятью и моделью. Для безопасника ИИ-агент — это новый пользователь в системе, у которого есть руки, доступ к данным и склонность к самодеятельности. Разница принципиальная. Чат-бот отвечал текстом. Агент нажимает кнопки. И если у него есть доступ к отправке денег, к массовой рассылке или к удалению строк — это уже не бот, это сотрудник, к которому применимы обычные корпоративные правила: у него должен быть бейдж, роль, срок действия доступа, лог действий и процедура увольнения.

Пока у команды в голове первая картинка, а у безопасников — вторая, договориться о запуске в продакшен не получится. Мы поначалу пробовали переубедить безопасников. Плохая идея. Проще было поменять свою картинку.

Первый подход: сервисная учётка с широкими правами. Провалился

Начали, как и все, с одного технического пользователя. Один ключ, все инструменты, вечная жизнь. Работает быстро, удобно отлаживать. Пока однажды агент не сделал то, чего от него никто не просил: пользователь попросил «посмотреть последние заказы», а агент по цепочке вызовов зашёл в аналитический отчёт, который тянул данные из соседнего подразделения. Никакой утечки не случилось, но история попала в лог, и объяснять её пришлось долго.

Проблема была не в модели. Проблема была в том, что агент технически имел право туда пойти. А раз имел — рано или поздно пошёл бы. Модель, планировщик и промпт — плохая последняя линия обороны. Хорошая линия обороны — это права доступа, которых у агента изначально нет.

Мы попробовали залатать это ролями. Завели агенту роль «читатель заказов», «писатель в CRM», «отправитель писем». Стало лучше, но появилась другая беда: роли статичны, а задачи агента — нет. Сегодня он разбирает входящую заявку и ему нужен CRM. Завтра тот же агент помогает бухгалтеру — и ему нужна 1С. Держать один агентский аккаунт со всеми возможными ролями — это тот же самый широкий доступ, только слегка причёсанный.

Что сработало: короткоживущий доступ на задачу

Второй подход мы подсмотрели в свежих анонсах у Okta, где identity для ИИ-агентов сделали first-class сущностью с короткоживущими правами. Идея простая: у агента нет постоянных ключей. На каждую задачу он получает временный токен, который действует ровно столько, сколько нужно, и ровно на те инструменты, которые нужны для конкретного запроса.

Как это устроено у нас. Пользователь пишет запрос агенту. Планировщик разбирает запрос и говорит: «Для этой задачи мне понадобится чтение карточки клиента в CRM и обращение к 1С за последним счётом». Дальше в дело вступает наш собственный брокер прав — небольшой сервис на FastAPI, который проверяет, имел ли право этот пользователь сам сходить в CRM и 1С за этими данными. Если да — брокер выдаёт агенту токен на конкретные операции, на короткое окно времени, с привязкой к запросу пользователя. Если нет — агент физически не получит ключа, даже если модель очень захочет.

Ключевая мысль: агент действует не от своего имени. Он действует от имени пользователя, который его позвал. И его права — это подмножество прав пользователя, а не какие-то отдельные «агентские» полномочия.

Как создать ИИ-агента, у которого нельзя украсть ключ

Дальше — детали, которые превратили красивую идею в рабочую систему.

Токены короткие и одноразовые по смыслу. Не «действует час», а «действует до конца этой задачи». Планировщик завершил цепочку — токен отозван, даже если технически ещё жив. Если модель зациклилась и продолжает дёргать инструменты после планового финиша, брокер её больше не пустит.

MCP-серверы принимают решение сами. Мы не делаем проверку прав в коде агента. Проверка живёт в MCP-сервере, который стоит перед 1С, CRM или почтовой шиной. Агент приходит с токеном — MCP-сервер идёт к брокеру, спрашивает: «Этот токен ещё жив? Что ему разрешено?» — и либо выполняет, либо отказывает. Такая архитектура полезна тем, что даже если промпт-инъекция уговорит модель сделать что-то запрещённое, у неё не будет технической возможности.

Аудит привязан к пользователю, а не к агенту. В каждый вызов инструмента мы прокидываем traceparent — сквозной идентификатор запроса. Он идёт от Angular-фронта через FastAPI, через планировщик, через MCP-сервер и оседает в логах и в базе. Через полгода можно поднять любой инцидент и увидеть: вот этот сотрудник в такой-то день попросил вот это, агент решил сделать вот такие шаги, каждый шаг выполнял под таким-то временным токеном, вот результат. Ни один шаг не подписан «сделал сервисный пользователь № 7».

Увольнение сотрудника отзывает права его агента. Это, пожалуй, самое неожиданное для заказчика следствие. Если человек уволился и его учётку заблокировали в Active Directory или в 1С — брокер перестанет выдавать токены агентам, которые пытаются действовать от его имени. Никаких «а давайте потом руками почистим». Оно чистится само, потому что права агента всегда производные от прав живого человека.

Российский контур без Okta

Отдельно про то, как это делать, когда Okta недоступна, а половина инфраструктуры должна оставаться внутри периметра заказчика. Мы собираем эту связку на Keycloak или на встроенных механизмах 1С и Active Directory. Брокер прав — свой, на FastAPI, живёт рядом с планировщиком агента. Модель — обычно GigaChat Pro, потому что данные не покидают российский контур и это закрывает часть вопросов по 152-ФЗ.

Импортозамещение здесь получается естественным: identity, брокер, MCP-серверы и модель — всё внутри. Зарубежных зависимостей ровно ноль, а архитектурная идея — та же, что у современных enterprise-платформ.

Что изменилось в работе

Раньше диалог с безопасниками растягивался на недели. Мы приносили агента, они находили дыру в правах, мы уезжали чинить. Теперь этот разговор занимает одну встречу: показываем схему брокера, показываем, как выдаются и отзываются токены, показываем лог с traceparent от пользователя до конкретной строчки в 1С. Дальше обсуждаем уже прикладные вопросы: какие MCP-серверы выкатываем в первой очереди, какие роли покрываем.

И ещё одно наблюдение. Когда права агента честно завязаны на права пользователя, у заказчика гораздо быстрее наступает доверие. Не потому что мы что-то сказали, а потому что математика простая: агент физически не может сделать то, чего не может сделать человек, который его позвал. Это понятно и директору по безопасности, и коммерческому директору.

Так что если вы думаете, как создать ИИ-агента, который завтра пойдёт в продакшен и не станет главным сюжетом внутреннего расследования — начинайте не с промпта. Начинайте с бейджа. Кто он такой в вашей системе, чьими руками он действует и как вы его уволите, когда придёт время. А планировщик и модель — это уже потом.