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

Опасность ИИ‑агента начинается не с «неправильного ответа», а с права превратить этот ответ в действие. Ошибка в черновике видна редактору. Ошибка агента с доступом к CRM, почте, ценам или файлам может за секунды распространиться на сотни объектов.

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

Семь обязательных слоёв защиты

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

Начните с модели угроз конкретного процесса

Вместо общего вопроса «безопасен ли ИИ?» опишите, что именно может пойти не так:

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

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

Права: принцип минимально необходимого доступа

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

Разделяйте чтение и запись

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

Ограничивайте не только операцию, но и область

«Можно обновлять товары» слишком широко. Безопаснее: разрешены определённая организация, список магазинов, конкретные поля, не более N объектов за запуск и только значения в допустимом диапазоне.

Не используйте универсальные инструменты

Функции «выполнить произвольный запрос», «запустить команду» или «изменить любую запись» удобны для прототипа, но плохо контролируются. Для production создают узкие операции с типизированным входом.

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

Подтверждение человеком: какие действия нельзя прятать за одной кнопкой

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

OpenAI рекомендует human‑in‑the‑loop там, где результат используется на практике, особенно в областях с высокой ценой ошибки. Проверяющий должен иметь доступ к исходному материалу, а не только к пересказу модели.

Журнал действий: что записывать

Хороший аудит‑лог позволяет восстановить цепочку без чтения всего диалога.

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

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

Нужен ИИ‑офис с правами и согласованиями, а не «бот с паролем владельца»? Посмотрите подход SelSup к проектному внедрению ИИ в бизнес‑процессы.

Откат: четыре разных механизма

1. Отмена до применения

Change set существует отдельно от production. Его можно проверить, отклонить или пересобрать. Это самый дешёвый откат.

2. Техническая ревизия

Перед изменением сохраняются старые значения, файл или версия записи. Восстановление возможно по точному fingerprint, чтобы не затереть более новые правки.

3. Компенсирующее действие

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

4. Бизнес‑восстановление

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

Защита от повторов и гонок

Сетевой тайм‑аут не означает, что действие не выполнено. Если агент просто повторит запрос, появятся дубли. Для write‑операций нужны:

• идемпотентный ключ на бизнес‑операцию;
• проверка текущего состояния перед записью;
• optimistic lock или expected version;
• лимит повторов и backoff;
• отдельный статус «результат неизвестен», требующий проверки;
• защита от одновременного изменения одного объекта.

Prompt injection: почему документу нельзя доверять команды

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

Практические меры:

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

Официальные рекомендации OpenAI включают red‑teaming и проверку на prompt injection. Security Best Practices MCP дополняют это требованиями к consent, авторизации, защите токенов и сетевых границ.

Этапы безопасного запуска

1. Офлайн‑тест. Исторические данные, никаких живых инструментов.
2. Read‑only. Агент читает ограниченный контекст и формирует рекомендации.
3. Теневой режим. Сравнение с сотрудником на реальных событиях.
4. Черновики. Агент создаёт неприменённый change set.
5. Подтверждаемая запись. Одно узкое обратимое действие.
6. Автодействие в лимите. Только после измерений и с автоматическим контролем.
7. Регулярный пересмотр. Права, инструменты, журналы, ошибки и обновления.

Чек‑лист допуска в production

• Владелец процесса и владелец системы названы.
• Отдельная учётная запись агента создана.
• Права выданы по принципу минимальной необходимости.
• Read и write разделены.
• Критичные параметры проверяются сервером, а не только моделью.
• Есть лимиты объёма, суммы и частоты.
• Подтверждение показывает точный diff.
• Секреты не попадают в промты, ответы и логи.
• Write‑операции идемпотентны.
• Журнал позволяет связать событие, решение и результат.
• Откат протестирован на стенде.
• Есть аварийное отключение без остановки основного бизнеса.
• Проведены негативные и adversarial‑тесты.
• После действия выполняется контроль факта.

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

Достаточно ли просить агента «всегда спрашивать подтверждение»?

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

Нужно ли логировать весь диалог?

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

Можно ли дать агенту токен администратора на время пилота?

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

Что делать, если внешняя система не поддерживает rollback?

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

Кто отвечает за безопасность: разработчик или бизнес?

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

Безопасный ИИ‑агент — это не модель без ошибок, а система, в которой ошибка ограничена, заметна и исправима. До выдачи write‑прав проверьте, подходит ли процесс для пилота, по матрице ценности, данных, риска и обратимости.