Доступы ИИ-ассистентов: как ограничить полномочия до первого действия

В понедельник ассистент умеет больше, чем обещала презентация

В пятницу команда показала полезный сценарий: ассистент прочитал карточку обращения, собрал историю переписки и предложил ответ клиенту. На демонстрации он ничего не отправлял. В понедельник сценарий подключили к рабочей почте и CRM, чтобы «не заставлять оператора копировать текст». Теперь один и тот же помощник может искать данные, готовить черновик, менять статус обращения и отправлять письмо наружу.

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

Если сценарий затрагивает персональные данные, правовая граница тоже уже существует. Статья 19 Закона № 152-ФЗ связывает обработку ПДн с обязанностью оператора принимать необходимые меры безопасности. Это не готовая схема ИИ-ассистента и не автоматическое требование купить ещё один продукт. Но это достаточная причина не считать доступы второстепенной деталью «после пилота».

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

Что именно нужно ограничить

Слово «доступ» часто скрывает пять разных вещей.

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

Такой разбор близок к модели ABAC: NIST SP 800-162 описывает авторизацию как проверку атрибутов субъекта, объекта, операции и, при необходимости, условий окружения против политики. Это не иностранское правило для российской компании и не приказ срочно строить универсальный ABAC-движок. Это удобная модель вопроса: не «есть ли у ассистента права», а «разрешено ли этой идентичности выполнить это действие над этим объектом в этих условиях».

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

Граница должна быть вне модели

У ассистента есть две разные работы. Первая — понять задачу и сформировать намерение: «нужно подготовить ответ», «нужно найти договор», «нужно предложить изменить статус». Вторая — сделать вызов инструмента. Между ними должна стоять точка, где обычный программный компонент валидирует параметры и проверяет политику.

Это можно представить как короткий маршрут:

1. Ассистент формирует структурированный план действия: тип операции, объект, параметры и объяснение для пользователя.
2. Шлюз инструмента проверяет схему параметров, допустимый метод и ограничения значения.
3. Политика оценивает субъект, объект, действие и контекст.
4. Система либо отказывает, либо создаёт запрос на подтверждение, либо выпускает узкое временное полномочие на один вызов.
5. Инструмент исполняет разрешённое действие и возвращает результат под тем же корреляционным идентификатором.

Критическая часть этой цепочки не должна жить только в системном промпте. OWASP LLM07 прямо рекомендует оставлять разделение привилегий и проверку границ авторизации детерминированными и аудитируемыми, а не делегировать их модели. Рекомендации OWASP по prompt injection дополняют это: ограничение доступа должно применяться к функции и токену, а не к уверенности, с которой модель объяснила своё решение.

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

Политика проверяет запрос, а не доверяет объяснению модели

Удобно представить policy-check как отдельный договор между инструментом и системой контроля. Ассистент не передаёт туда фразу «пользователь попросил отправить письмо». Он передаёт структурированное намерение: кто инициатор, какой метод нужен, какой объект затрагивается, кому уйдёт результат, какие параметры имеют значение и к какому сценарию относится запрос. Шлюз сначала сверяет структуру и допустимые значения, затем обращается к политике. Политика возвращает один из трёх результатов: разрешить, потребовать подтверждение или запретить. Только после этого вызывается целевая система.

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

Такую проверку нельзя свести к одному списку ролей. Роль полезна как начальная группировка: сотрудник поддержки, руководитель группы, оператор бэк-офиса. Но роль не отвечает, вправе ли конкретный сотрудник передать конкретный документ конкретному получателю именно сейчас. Для этого нужны признаки объекта и обстоятельства. NIST называет их атрибутами субъекта, объекта, операции и окружения. В реальном первом сценарии это может быть отдел инициатора, класс обращения, метод change_status, рабочая среда, лимит на пакет и наличие действующего approval.

Это не аргумент за тотальную платформу атрибутного доступа. В небольшой интеграции те же правила могут жить в серверном модуле: белый список методов, проверка владельца карточки, ограничение получателя, TTL и неизменяемая запись решения. В более зрелом контуре уместны отдельная точка enforcement и движок политик. Существенно не название компонента, а то, что целевой API не вызывается по одному лишь желанию модели, а логика контроля не дублируется непоследовательно в десятке промптов.

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

Три режима вместо общего «разрешено»

Для первой версии матрицы достаточно трёх режимов.

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

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

Сначала отделите видимость данных от права выполнить метод

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

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

Особенно внимательно стоит относиться к поиску и RAG-контексту. Документ, найденный для ответа, — это ещё не разрешение использовать его как инструкцию для действия или переслать его содержимое дальше. Шлюз инструмента не должен превращать текст из базы знаний в источник полномочий. Он получает проверяемые идентификаторы и параметры, а решение о разрешении принимает по политике, не по цитате из документа и не по уверенности модели. Именно это разделение помогает локализовать последствия prompt injection: вредоносная фраза может изменить предложение ассистента, но не добавить метод, область данных или получателя к разрешённой операции.

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

Практический пример: ассистенту поручили изменить статус обращения после того, как оператор согласовал ответ. Делегированный контекст пользователя может подтвердить, что он видит эту карточку. Узкая сервисная идентичность может иметь право вызвать именно метод изменения статуса. Policy-check проверяет допустимый переход и отсутствие конфликта со статусом. А approval связывает одноразовое исполнение с конкретной версией плана. Ни один из четырёх элементов не заменяет остальные; вместе они образуют проверяемую цепочку без общего административного доступа.

Подтверждение не должно быть фразой в чате

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

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

OWASP предлагает human-in-the-loop для значимых операций. Из этого не следует, что нужно заставить человека подтверждать каждую безопасную подсказку. Чрезмерные подтверждения быстро становятся автоматическим кликом. Если действие слишком опасно, чтобы его удобно и осмысленно подтвердить, честнее оставить его в режиме «запретить» и построить отдельный управляемый процесс.

От чьего имени действует инструмент

Есть три типовые модели, и ни одна не является универсальной.

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

Отдельная сервисная идентичность. У ассистента есть собственная учётная запись с коротким перечнем методов и объектов. Это полезно для фоновых процедур и согласованных интеграций. Опасность начинается, когда техническое удобство превращает её в администратора «на всякий случай». Сервисная идентичность должна быть отдельной по средам, ограниченной по методам, сроку и сетевому маршруту; в журнале также сохраняется пользователь или процесс, от имени которого возникло намерение.

Гибрид. Пользовательские права ограничивают чтение и выбор объекта, а узкая сервисная идентичность выполняет одну техническую операцию после policy-check. Такой вариант сложнее, но часто лучше отделяет бизнес-контекст от технического вызова.

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

Что должен содержать журнал

Российский язык защитных мер различает идентификацию и аутентификацию, управление доступом и регистрацию событий безопасности; это видно и в открытом представлении состава мер ФСТЭК. Для ассистента эти классы контроля не должны сливаться в одну запись «tool called».

Минимальный журнал для действия с заметным эффектом связывает:

• корреляционный идентификатор запроса;
• пользователя или процесс-инициатор, техническую идентичность ассистента и подтверждающего, если он нужен;
• тип действия, класс объекта и итоговую область данных — без лишнего содержимого и секретов;
• версию политики, решение «разрешить / подтвердить / запретить» и причину отказа в машиночитаемом виде;
• идентификатор и версию подтверждённого плана;
• факт вызова инструмента, ответ, время и результат;
• отзыв, истечение или ошибку полномочия.

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

Как сделать отказ рабочим состоянием, а не инцидентом

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

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

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

Такой подход связывает безопасность с удобством эксплуатации. Команда получает не чёрный ящик, который то разрешает, то запрещает, а предсказуемый процесс: инициатор видит границу, подтверждающий видит эффект, инженер видит правило и параметры, ИБ видит цепочку решения, а владелец данных может отозвать область доступа. Чем раньше эти роли проходят один и тот же сценарий вместе, тем меньше вероятность, что полномочия будут достраиваться в production через исключения и общий сервисный аккаунт.

Минимальный контракт между владельцем процесса и ИБ

Перед подключением первого инструмента полезно договориться не только о настройках, но и о владельцах решений. Владелец процесса отвечает за то, что действие действительно нужно и что его результат понятен человеку. Владелец данных определяет допустимую область и получателей. ИБ задаёт требования к идентичностям, журналу, отзыву и проверкам. Архитектор или команда интеграции превращает эти решения в проверяемую точку enforcement. У модели нет собственной деловой роли: она предлагает намерение внутри заданных границ.

Этот контракт стоит записать рядом с матрицей. У каждой строки должны быть понятны не только метод и токен, но и владелец правила, повод его пересмотра и безопасная альтернатива при отказе. Например, право отправить письмо может принадлежать не «ассистенту поддержки», а владельцу процесса исходящих коммуникаций; пересмотр нужен при появлении нового канала, нового типа вложений или массового режима; безопасная альтернатива — черновик для сотрудника. Так спор о техническом scope превращается в проверяемое управленческое решение.

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

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

Стоит заранее определить и условия аварийной остановки. Это не обязательно сложный «kill switch»: достаточно, чтобы владелец системы мог выключить конкретный метод, конкретную сервисную идентичность или целый сценарий без изменения модели и без ожидания следующего релиза промпта. Проверка этой возможности важна так же, как успешный демонстрационный вызов. Если ассистент после отзыва продолжает работать по старому токену, кэшу разрешений или отложенной задаче, матрица не выполнила свою главную функцию — не ограничила последствия до первого действия.

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

Матрица полномочий для первого сценария

Ниже — не готовая политика для всех компаний, а стартовый артефакт совместной работы ИБ, владельца процесса, архитектора и команды интеграции.

Смысл последнего столбца часто недооценивают. Разрешение без срока и объёма почти неизбежно переживает задачу, ради которой его выдали. Полномочие на один вызов с TTL, областью объекта и лимитом частоты проще проверить и проще отозвать. Это не означает, что у каждого API нужен собственный продукт. Иногда достаточно правильного scope в OAuth, отдельного метода в backend-for-frontend, ограничения на сервере ресурса и согласованного audit trail.

Порядок внедрения без театра безопасности

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

1. Инвентаризируйте инструменты. Запишите методы, данные, системы, внешние получатели, сервисные аккаунты, секреты и каналы передачи. Если инструмент не нужен первому сценарию, он не должен быть доступен «на будущее».
2. Разложите действия. Разделите «работу с CRM» на читабельные бизнес-значимые строки. У каждой строки должен быть объект и результат.
3. Назначьте режим. Для каждой строки честно выберите «разрешить», «подтвердить» или «запретить» и зафиксируйте почему. Спорные действия безопаснее оставить без автоматического исполнения до решения владельца риска.
4. Вынесите policy-check. Инструмент принимает структурированный запрос, валидирует его и обращается к детерминированной политике до полезного вызова.
5. Сделайте подтверждение связывающим. Предпросмотр, версия, субъект подтверждения, TTL и неизменяемый идентификатор — часть процесса, а не текстовая реплика.
6. Проверьте отзыв. В тестовом контуре отзовите роль, истеките токен, измените подразделение пользователя и убедитесь, что ассистент не продолжает действовать по старому решению.
7. Проведите негативные сценарии. Попросите ассистента выполнить запрещённую операцию, подменить получателя после approval, расширить выборку и повторить вызов. Ожидаемый результат — отказ на внешней границе и журналируемый след, а не только вежливый ответ модели.

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

Тест понедельником

Перед тем как включить ассистента в рабочем контуре, откройте одну строку матрицы и спросите команду:

• Может ли новый сотрудник назвать, какое действие ассистент выполнит, а какое только предложит?
• Если пользователь сменил роль или ушёл из подразделения, прекращается ли доступ до следующего вызова?
• Увидит ли руководитель не только ответ модели, но и основание policy decision, подтверждение и результат инструмента?
• Если во входном документе окажется вредоносная инструкция, остановит ли её внешний запрет на метод, область и получателя?

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

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

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

Важное уведомление

Материал носит информационный характер и не является индивидуальной консультацией, проектной документацией, инструкцией по внедрению или гарантией результата. Применимость описанных подходов зависит от процессов, систем, данных, требований безопасности и иных условий конкретной организации. Перед внедрением или изменением ИТ‑систем необходимо самостоятельно оценить риски и привлечь профильных специалистов.