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

Безопасный ИИ-агент не получает прямой неограниченный доступ к системам. Модель предлагает структурированное действие, policy layer проверяет полномочия и риск, исполнитель работает в изолированной среде, а результат проходит валидацию и аудит. Для необратимых или чувствительных операций требуется отдельное подтверждение.

Чат-бот генерирует текст. Агент дополнительно планирует шаги, вызывает инструменты, читает данные, сохраняет память и меняет внешнее состояние. Именно способность действовать расширяет полезность — и поверхность риска.

Базовая модель угроз

Рассматривайте минимум шесть источников риска.

Прямые вредоносные инструкции

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

Непрямые инструкции

Команда находится в документе, письме, веб-странице или результате API. Агент воспринимает внешние данные как указание к действию.

Избыточные полномочия

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

Ошибка модели

Агент неверно понял контекст, выбрал неправильный объект или сформировал несовместимые параметры.

Неконтролируемая цепочка

Повторы, рекурсия или делегирование между агентами расходуют время и бюджет, создают дубли и затрудняют остановку.

Утечка через память и журналы

Чувствительные данные попадают в долгоживущий контекст, общую базу знаний или диагностические записи.

Разделите решение и исполнение

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

Надёжный поток:

Запрос → контекст → модель → структурированное намерение
→ проверка политики → approval при необходимости
→ ограниченный исполнитель → проверка результата → аудит

Модель возвращает не командную строку, а объект по строгой схеме:

{
  "action": "create_support_ticket",
  "customerId": "c-1842",
  "priority": "normal",
  "summary": "Delivery status requires investigation"
}

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

Инструменты должны быть узкими

Плохой инструмент:

execute_sql(query)

Более безопасные инструменты:

get_order_status(orderId)
create_support_ticket(customerId, category, summary)
request_refund_review(orderId, reason)

Узкий контракт:

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

Используйте отдельную service identity для агента и каждого окружения. Права пользователя и агента пересекаются: операция разрешена только если она допустима обоим.

Политика риска для действий

Разделите операции по уровню.

Уровень	Пример	Контроль
Низкий	Поиск инструкции	Автоматически, с журналом
Средний	Создание черновика заявки	Валидация и возможность отмены
Высокий	Отправка сообщения клиенту	Подтверждение человеком или строгая политика
Критичный	Платёж, удаление, изменение прав	Отдельный процесс, MFA, двойной контроль

Модель не должна сама решать, что её действие «низкого риска». Классификация задаётся вне модели в политике инструмента.

Защитите RAG и внешние данные

Retrieval-Augmented Generation добавляет к запросу найденные документы. Эти документы недоверенные даже внутри компании: файл может быть устаревшим, ошибочным или содержать внедрённую инструкцию.

Меры:

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

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

Память с ограниченным сроком

Не вся информация должна становиться памятью. Разделите:

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

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

Ограничьте автономность технически

Установите пределы вне промпта:

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

Идемпотентный ключ предотвращает повторное создание заявки или отправку сообщения при retry. Подход к повторам описан в статье об API-архитектуре.

Human-in-the-loop должен быть содержательным

Кнопка «Подтвердить» бесполезна, если человек не видит контекст. Экран approval должен показывать:

• что изменится;
• какой объект затронут;
• исходные данные;
• предложенные параметры;
• основание и найденные источники;
• риск и возможность отката;
• срок действия подтверждения.

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

Изоляция исполнителя

Если агент обрабатывает файлы или выполняет код, используйте sandbox с:

• минимальным образом;
• отдельной файловой системой;
• лимитами CPU, памяти и времени;
• запретом произвольной сети;
• allowlist адресов;
• одноразовыми учётными данными;
• очисткой после задачи;
• сканированием результата.

Секреты не помещаются в промпт. Исполнитель получает короткоживущий токен только после проверки политики.

Наблюдаемость без утечки

Связывайте события одним trace ID:

1. входной запрос;
2. версия модели и правил;
3. найденные источники;
4. предложенное действие;
5. результат политики;
6. approval;
7. вызов инструмента;
8. проверка результата;
9. финальный ответ.

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

Метрики:

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

Оценка перед релизом

Обычные unit-тесты не покрывают вариативность модели. Нужен evaluation set:

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

Для каждого кейса фиксируются допустимые действия и запрещённые последствия. Регрессия запускается после изменения модели, инструментов, схемы памяти, retrieval или политики.

Инцидент и аварийная остановка

Предусмотрите:

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

Kill switch должен находиться вне самого агентного контура и проверяться на учениях.

План пилота

Шаг 1. Выберите обратимый сценарий

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

Шаг 2. Опишите границу

Какие данные доступны, какие инструменты разрешены, кто владелец, какой результат считается успешным.

Шаг 3. Сделайте узкие инструменты

Строгие схемы, отдельные identity, идемпотентность, таймауты и аудит.

Шаг 4. Добавьте policy layer

Роли, риск, лимиты и approval реализуются вне модели.

Шаг 5. Соберите evaluation set

Используйте реальные обезличенные сценарии и атаки на границы.

Шаг 6. Запустите в shadow mode

Агент предлагает действия, но не выполняет их. Сравните с решениями сотрудников.

Шаг 7. Разрешите малый объём

Ограничьте пользователей, объекты и дневной бюджет. Расширяйте только после анализа.

Чек-лист production readiness

• Действия отделены от генерации текста.
• У каждого инструмента узкий контракт.
• Модель не принимает решение об авторизации.
• Права пользователя и service identity пересекаются.
• ACL применяются до retrieval.
• Память изолирована и имеет срок хранения.
• Высокий риск требует содержательного approval.
• Установлены лимиты шагов, времени, стоимости и повторов.
• Изменяющие операции идемпотентны.
• Исполнение кода и файлов изолировано.
• Есть evaluation set и release gate.
• Аудит связывает решение с действием.
• Kill switch проверен.
• Владелец отвечает за бизнес-результат.

Вывод

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

Полезные ориентиры: NIST AI Risk Management Framework, OWASP AI Agent Security Cheat Sheet и OWASP Securing Agentic Applications Guide. Они не заменяют применимые российские требования и внутреннюю модель угроз.

Свежие примеры развития платформ есть в новости о совместном проекте Selectel и ИТМО и обзоре стандартов взаимодействия ИИ-агентов в Китае.

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