Безопасность ИИ-агентов: доступы, согласования и контроль действий

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

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

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

Почему безопасность ИИ-агента шире защиты чата

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

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

Поэтому я разделяю четыре вопроса:

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

Если хотя бы на один вопрос нет конкретного ответа, автономность пока рано расширять.

Быстрая модель уровней риска

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

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

Начните с карты процесса, а не с промпта

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

1. Инициатор: кто и при каких условиях запускает работу.
2. Входы: какие данные агент получает напрямую и какие находит сам.
3. Инструменты: к каким системам он может обратиться.
4. Операции: что именно разрешено в каждой системе.
5. Последствия: что изменится после вызова инструмента.
6. Согласующий: кто принимает решение при чувствительном действии.
7. Восстановление: как остановить маршрут и вернуть предыдущее состояние.

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

Эту карту стоит приложить к ТЗ на разработку ИИ-агента. Тогда фраза «интеграция с CRM» превращается в проверяемое требование: какие сущности видны, какие поля меняются, где нужен черновик, кто подтверждает отправку и сколько хранится журнал.

Дайте агенту отдельную личность и владельца

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

Для карточки агента достаточно зафиксировать:

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

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

Ограничьте права до действия, а не только до сервиса

Фраза «у агента есть доступ к Google Drive» почти ничего не говорит. Нужно знать, к какой папке, на чтение или запись, может ли он делиться файлами, удалять их и видеть историю. То же относится к CRM, почте, CMS, календарю и внутренним API.

Я использую простой реестр прав:

Минимальные права не означают, что агент ничего не умеет. Они означают, что каждая возможность оправдана задачей. Похожий принцип я уже показывал на примере разделения доступов в НейроЦЕХе. Здесь шаг дальше: право должно проверяться не только в оркестраторе, но и в самой целевой системе. Если агент попросил изменить чужую запись, CRM или API обязаны отказать независимо от того, что решила модель.

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

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

Если человек подтверждает каждый поиск и каждое чтение, агент превращается в медленный интерфейс. Если подтверждений нет нигде, цена одного неверного решения становится слишком высокой. Нужна матрица согласований, привязанная к последствиям.

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

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

Защитите данные на всём маршруте

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

Проверьте данные по пяти точкам:

1. Сбор. Агент получает только нужные поля, а не полный экспорт «на всякий случай».
2. Передача. Команда знает, какие фрагменты уходят модели, инструменту и внешнему сервису.
3. Хранение. Определены сроки для истории, файлов, памяти и технических журналов.
4. Вывод. Перед отправкой проверяются персональные, финансовые и другие чувствительные данные.
5. Удаление. Есть понятный способ удалить рабочие копии и отозвать ссылки или токены.

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

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

Считайте внешние данные недоверенными

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

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

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

Фильтр модели здесь — один слой, а не вся защита. Даже если агент ошибся в рассуждении, узкий интерфейс инструмента должен не дать ему выполнить действие за границей процесса.

Разделите подготовку и исполнение

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

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

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

Ведите журнал действий, а не только переписку

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

• время и идентификатор запуска;
• пользователя или систему, которая поставила задачу;
• идентичность агента и версию его конфигурации;
• выбранный инструмент и тип операции;
• целевой объект и область действия;
• безопасное представление параметров без секретов;
• правило согласования и решение согласующего;
• ответ целевой системы, созданный ID или код ошибки;
• число повторов и итоговый статус;
• ссылку на версию или снимок до изменения.

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

Добавьте лимиты, откат и аварийную остановку

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

Для каждого рабочего маршрута задайте:

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

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

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

Проверьте контур до запуска на реальных сценариях

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

1. Обычная разрешённая задача завершается ожидаемым результатом.
2. Агент запрашивает объект вне своей области и получает отказ.
3. Документ содержит ложную инструкцию вызвать другой инструмент.
4. Обязательное поле отсутствует, поэтому запись не выполняется.
5. Согласующий отклоняет действие, а агент не пытается обойти решение.
6. Целевая система отвечает с ошибкой после частичного выполнения.
7. Повторный запуск не создаёт дубль и не отправляет сообщение второй раз.
8. Токен или роль отозваны, и действие действительно блокируется.
9. Аварийная остановка прекращает новые и активные операции.
10. Откат возвращает контрольный объект в предыдущее состояние.

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

Кто отвечает за безопасность ИИ-агента

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

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

Когда автономность лучше уменьшить

Не каждому процессу нужен агент, который сам вызывает инструменты. Оставьте систему в режиме помощника или черновика, если:

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

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

Чек-лист безопасной архитектуры ИИ-агента

Перед запуском ответьте «да» на каждый пункт:

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

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

Частые вопросы

Можно ли сделать ИИ-агента полностью безопасным?

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

Какие действия всегда отдавать на согласование человеку?

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

Достаточно ли фильтра от prompt injection?

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

Локальная модель решает проблему конфиденциальности?

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

С чего начать аудит уже работающего агента?

Возьмите один реальный запуск и восстановите цепочку: кто его инициировал, какие данные прочитаны, какие инструменты вызваны, что изменилось и как это отменить. Затем сравните фактические права с необходимыми и проверьте отказ, повтор, отзыв токена и остановку.

Вывод

Безопасность ИИ-агентов не сводится к длинному промпту и ручной проверке каждого шага. Надёжный контур строится из отдельных идентичностей, минимальных прав, согласований по последствиям, защиты данных, проверяемых инструментов, журналов, лимитов и восстановления.

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