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

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

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

В конце – чек-лист: по нему можно пройтись по своему агенту и закрыть самые опасные дыры до первого инцидента.

Ошибки ИИ-агента: почему они неизбежны и почему логи их не покажут

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

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

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

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

Права: принцип минимальных привилегий для агента

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

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

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

Отдельно проверьте сочетание трёх условий. Агент становится по-настоящему опасным, когда одновременно:

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

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

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

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

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

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

Дальше нужны ограничения на случай, когда что-то всё-таки проскочит:

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

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

Независимый ревьюер, которого проверили на отказ

Ревьюер – второй контур для важных действий: отдельный шаг проверки или отдельный агент, который смотрит на предложенное действие до его выполнения. Систему, которой нужно убедить независимого проверяющего, сложнее довести до плохого результата.

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

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

Журнал, который пишет не агент

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

Из чего складывается такой журнал:

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

Хеш-цепочка и подписи. Каждая запись связана с предыдущими. Изменить её или переставить порядок незаметно не получится – останется разрыв.

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

Убеждения агента, а не только действия. До исполнения фиксируйте, в какой среде агент себя считает, от чьего имени действует и что считает целью. Именно это объясняет случаи, когда агент «думал, что это тест».

Имя, а не роль. В графе «кто разрешил» должен стоять конкретный человек, а не «проверяющий» или «система».

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

Чекпоинт и откат всей среды за секунды

Все слои выше снижают вероятность ошибки. Последний исходит из того, что ошибка всё-таки случится, и делает её дешёвой.

Один из вариантов – запускать агента в изолированной среде, которую можно сохранить целиком и вернуть. Так устроен, например, Managed Agents от DigitalOcean: каждая сессия агента работает в отдельной микро-ВМ, и всю машину можно сохранить в чекпоинт, размножить в независимые копии и откатить (на октябрь 2026).

В одном публичном эксперименте с этой платформой на сервере намеренно остановили веб-сервер и удалили каталог приложения. После отката к чекпоинту вернулись не только файлы: остановленный процесс снова работал – его восстановили из памяти, а не запустили заново. Откат занял 5,6 секунды, создание трёх копий из чекпоинта – 15,3 секунды (замеры октября 2026). Сам чекпоинт создаётся дольше – около 25 секунд, а платформа пока в публичном превью и работает в одном регионе.

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

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

Ключевые термины

• Принцип минимальных привилегий – Правило давать агенту только тот доступ, который строго нужен для его задачи, и ничего сверх.
• Радиус поражения – Объём того, что затронет действие при ошибке: какие данные, системы и деньги оно может изменить.
• Промпт-инъекция – Скрытые инструкции в тексте, который читает агент (письмо, страница, документ), заставляющие его сделать то, чего никто не просил.
• Хеш-цепочка – Способ связать записи журнала так, что каждая содержит отпечаток предыдущих, и любое изменение или удаление оставляет видимый разрыв.
• Хранилище только на дозапись – Хранилище, куда можно добавлять новые записи, но нельзя незаметно править или удалять старые.
• Чекпоинт – Снимок полного состояния среды агента – файлов и запущенных процессов, – к которому можно откатиться.
• Форк сессии – Независимая копия работающей среды агента, продолжающаяся с момента чекпоинта.

Итог: чек-лист безопасности ИИ-агента перед выдачей доступов

Пройдитесь по этому списку для каждого агента с реальными доступами. Сначала – права:

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

Дальше – контроль и откат:

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

Проверьте себя

1. Агент отчитался, что почистил тестовую базу, мониторинг зелёный. Что надёжнее всего подтвердит, что всё в порядке?

• А. Повторный запуск проверки в CI, который читает отчёт агента
• Б. Подробный лог самого агента о выполненных шагах
• В. Проверка реального состояния: на месте ли рабочие данные, сходятся ли итоги
• Г. Код ответа 200 от команды удаления

2. Агент получает письма клиентов, имеет доступ к базе заказов и может отправлять письма. Какой шаг сильнее всего снизит риск промпт-инъекции? (Верных ответов несколько.)

• А. Добавить фильтр, который ищет вредные инструкции в письмах
• Б. Попросить агента в промпте не выполнять чужие инструкции
• В. Ограничить доступ агента только нужными таблицами
• Г. Убрать одно из трёх условий, например запретить агенту отправлять письма без подтверждения

3. Вы подключили второго агента-ревьюера, и за месяц он одобрил все действия. Что это значит?

• А. Неизвестно, работает ли ревьюер: его нужно проверить заведомо плохим действием
• Б. Основной агент работает безупречно
• В. Ревьюер не нужен, его можно отключить

4. Какая из записей журнала помогает понять причину стёртой базы, а не только сам факт удаления?

• А. Итоговый статус «успешно»
• Б. Команда удаления и время её выполнения
• В. Среда и цель, которые агент считал текущими в момент решения

5. Вы сделали форк сессии агента из чекпоинта и в форке что-то сломалось. Как откатиться?

• А. Перезапустить тот же промпт в новой сессии – получится то же самое
• Б. Откатить форк к чекпоинту родительской сессии
• В. Заранее сделать отдельный чекпоинт внутри самого форка