Служебная учётная запись ИИ-агента: владелец, доступ и отключение

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

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

Пилот на чужом пропуске

Условная сцена: в компании «Северный мост» (название вымышленное) ИИ-агент раз в сутки собирает заявки из почты и раскладывает их по папкам в CRM. Год назад его подключили под учётной записью руководителя отдела продаж Марины, потому что так было быстрее всего. Марина перешла в другой департамент, а агент продолжает работать — теперь с правами, которых у неё уже нет, и с доступом к данным, которые её новой роли не касаются.

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

Если ваша задача — назначить владельца доступа агента, на странице соответствующего направления 404ai можно посмотреть опубликованные возможности и оставить описание текущего процесса. Конкретные подключения, исходные данные и критерии приёмки согласуем отдельно.

Агент — это не сотрудник и не сервис

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

От сервисной учётной записи классической интеграции её отличает поведение. Классический коннектор делает одно и то же действие по расписанию. Агент принимает решения в рамках задачи: выбирает, куда положить заявку, кому её адресовать, что сделать с нестандартным письмом. Чем шире свобода действий, тем важнее, чтобы у этой свободы был конкретный человек-владелец, который отвечает за границы.

Отсюда первое практическое следствие: заводить агента под личным аккаунтом сотрудника — значит наследовать все проблемы личного аккаунта. Смена роли, отпуск, увольнение, повышение прав — всё это автоматически меняет и полномочия агента, причём без отдельного решения. Microsoft в документации по управляемым идентичностям описывает идентичность, привязанную к ресурсу, а не к человеку, с собственным жизненным циклом (Managed identities overview). Это не единственный способ, но он показывает принцип: идентичность агента стоит привязывать к ресурсу или отдельной служебной записи, а не к личному аккаунту сотрудника.

Что должно быть записано до первого запуска

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

Таблица заполняется один раз и пересматривается при каждом изменении роли агента. Главное в ней — не полнота ради галочки, а то, что владелец и назначение записаны явно, а не подразумеваются.

Два эпизода, в которых всё ломается по-разному

Эпизод первый: владелец ушёл. В условной компании «Ласточка» (название вымышленное) агент-помощник готовил черновики ответов клиентам. Его подключили под учётной записью начальника поддержки. Через полгода начальник уволился, учётную запись заблокировали — и агент перестал работать. Не потому, что кто-то принял решение его выключить, а потому, что исчезла идентичность, под которой он ходил. Две недели никто не понимал, почему черновики не появляются: в интерфейсе агента ошибок не было, ошибка возникала на стороне почтового сервиса. Когда разобрались, выяснилось, что нового владельца у агента нет, назначение нигде не записано, а восстановить работу можно только создав новую учётную запись — со всеми доступами заново и без истории.

Эпизод второй: права выросли незаметно. В условной компании «Тихий двор» (название вымышленное) агент раскладывал заявки в CRM под учётной записью менеджера. Менеджера повысили до руководителя направления, и вместе с повышением ему выдали расширенные права: просмотр всех сделок, выгрузка отчётов, изменение справочников. Агент эти права унаследовал молча. Через месяц при проверке журналов выяснилось, что агент, который по замыслу должен был только создавать карточки, начал править справочник причин отказа — потому что модель стала чаще встречать нестандартные формулировки и «помогала» их классифицировать. Никто не давал такого указания. Просто у агента оказалось больше свободы, чем предполагало его назначение.

Разница между эпизодами принципиальная. В первом агент перестал работать, и это заметили. Во втором агент работал слишком широко, и это не заметили бы ещё долго, если бы не сверка журналов. Оба случая — следствие одной и той же дыры: у идентичности не было владельца, который следит за её границами.

Минимальные полномочия — это не лозунг, а список

Принцип наименьших привилегий звучит настолько часто, что перестал что-либо значить. Для агента его стоит перевести в конкретный список: какие системы, какие действия, какие данные. Microsoft в документации по ролям и привилегиям описывает, что полномочия выдаются ролями, а роли складываются из привилегий (Security roles and privileges). Это помогает аудиту, но не гарантирует его: расширение доступа возможно и через изменение привилегий внутри уже назначенной роли, поэтому сверять нужно не только список ролей, но и их состав.

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

• Чтение. Какие папки, таблицы, разделы агент видит. Часто именно здесь прячется лишнее: агенту нужна папка «Заявки», а он видит весь ящик.
• Запись. Что агент создаёт и меняет. Отдельно стоит отметить, разрешено ли ему править существующие записи или только создавать новые.
• Действия с внешними последствиями. Отправка писем, сообщений клиентам, изменение статусов, запуск платежей. Это самый чувствительный уровень, и его стоит ограничивать жёстче всего.

Для каждого уровня полезно ответить на вопрос: что произойдёт, если агент ошибётся именно здесь? Если ответ «ничего страшного, это черновик» — уровень можно оставить широким. Если ответ «клиент получит неверное письмо» — нужен либо человек в цепочке подтверждения, либо узкое ограничение.

Секрет, который попал в лог

Условная сцена: в компании «Полевой стан» (название вымышленное) при отладке агента инженер включил подробное логирование запросов. В лог попал заголовок авторизации — тот самый секрет, которым агент представляется перед CRM. Лог лежал на общем диске отдела. Формально ничего не произошло: никто лог не читал, секрет не использовался. Но с этого момента гарантировать, что доступом пользуется только агент, стало невозможно.

Базовые требования к секретам общеизвестны: они не должны попадать в логи, должны храниться в защищённом месте и подлежать смене при компрометации. OWASP в шпаргалке по аутентификации разбирает смежные вопросы хранения паролей и защиты учётных данных (Authentication Cheat Sheet). Для агента это означает ещё одну вещь: у секрета должен быть владелец, который знает, где он лежит, и может его заменить, не останавливая всю работу надолго.

Порядок действий при попадании секрета в лог стоит описать заранее, потому что в момент инцидента думать некогда. Минимально: заменить секрет, проверить журналы обращений за период, когда старый секрет был доступен, убедиться, что старый перестал приниматься, и только потом чистить лог. Чистка лога первой — распространённая ошибка: она убирает следы, по которым можно было бы понять, пользовался ли кто-то чужим доступом.

Общая учётная запись на двух агентов

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

Второе следствие — неразличимость в журналах. Если оба агента ходят под одним логином, по журналу нельзя сказать, кто именно отправил письмо или создал карточку. При разборе инцидента это превращается в отдельное расследование, которое часто заканчивается ничем.

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

Что видит сотрудник, который работает рядом с агентом

Интерфейс для человека — часть жизненного цикла идентичности, а не отдельная тема. Сотрудник, который получает результат работы агента, должен понимать три вещи: от чьего имени действует агент, что он сделал и как это остановить.

Первое — атрибуция. В карточке, созданной агентом, стоит видеть не просто «система», а имя агента и его владельца. Тогда при странной записи сотрудник знает, к кому идти, а не пишет в общий чат поддержки.

Второе — журнал действий в понятном виде. Не сырой лог запросов, а список: что создано, что изменено, что отправлено, когда. С возможностью отфильтровать по агенту и по периоду.

Третье — кнопка «остановить» с понятными последствиями. Не «удалить агента» (это страшно и необратимо), а «приостановить»: агент перестаёт делать новые действия, но его история и настройки сохраняются. Владелец или дежурный может нажать её, не дожидаясь согласований, — иначе в момент проблемы никто не решится ничего трогать.

Отдельно стоит продумать, что видит сотрудник, когда агент пытается сделать что-то за пределами своих полномочий. Хороший интерфейс в этом случае не молчит и не падает с ошибкой, а показывает: «агент запросил доступ к справочнику, которого у него нет; обратитесь к владельцу». Это превращает инцидент в понятную задачу, а не в загадку.

Отключение — это не одна кнопка

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

Порядок отключения стоит описать как чек-лист и хранить рядом с карточкой агента.

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

Служебная идентичность агента: исключения и проверка условий

Любая схема жизненного цикла упирается в случаи, которые в неё не укладываются. Их полезно проговорить заранее, чтобы не изобретать решение в момент проблемы.

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

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

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

Агент, чей владелец тоже агент. Иногда владельцем назначают другую автоматизированную систему. Это создаёт цепочку, в которой никто из людей не отвечает за конечное поведение. Такое допустимо только как техническая прослойка, за которой всё равно стоит человек.

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

Проверка по документам, а не по памяти

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

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

Тесты, которые стоит прогнать до инцидента

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

Тесты стоит повторять при каждом изменении: новая интеграция, новая роль, новый владелец. Жизненный цикл идентичности — не разовое мероприятие, а то, что поддерживается.

Практикум: собрать карточку агента за один час

Возьмём условный пример, отличный от предыдущих. В компании «Речной узел» (название вымышленное) есть агент, который раз в неделю собирает из CRM список «зависших» сделок и присылает его руководителю отдела в мессенджер. Агент работает уже полгода, подключён под учётной записью аналитика, который недавно перешёл в другой отдел.

Задача практикума — не переписать агента, а собрать для него карточку и проверить, что она соответствует реальности. Порядок такой.

1. Выписать назначение одним предложением. «Раз в неделю читать сделки без активности более 14 дней и отправлять список руководителю отдела в мессенджер». Всё, что не входит в это предложение, — за пределами полномочий.
2. Перечислить системы и действия. CRM: чтение сделок, фильтр по дате активности. Мессенджер: отправка сообщения одному получателю. Больше ничего.
3. Сверить с фактическими правами. Открыть настройки учётной записи, под которой работает агент, и выписать, что ей реально разрешено. Здесь почти наверняка обнаружится лишнее: например, право править сделки, которое агенту не нужно.
4. Назначить владельца. Конкретный человек, который отвечает за поведение агента и может его остановить. Не «отдел», а имя с заместителем.
5. Описать отключение. Три шага: остановить расписание, отозвать доступ к CRM и мессенджеру, проверить журнал за последнюю неделю.
6. Прогнать один тест. Например, попросить агента отправить сообщение не тому получателю и убедиться, что он этого не может.

После этого карточка готова, и её можно пересматривать раз в квартал или при каждом изменении. Главное — не оставлять её в голове владельца, а положить туда, где её найдут другие.

Передача служебной идентичности владельцу процесса

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

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

Смежный вопрос разобран отдельно: Ротация API-ключа ИИ-агента: сменить доступ и сохранить рабочую очередь.