Идеальные логи ИИ-агента не спасут прод: почему мониторинг — это не контроль

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

Аудит-лог — это улика, а не система разрешений: если агент способен выполнить запрещённое действие и платформа лишь сообщает об этом постфактум, никакого управления рисками не происходит.

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

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

Что мы умеем и чего не умеем

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

Но наблюдаемость отвечает ровно на один вопрос: «Что произошло?». Контроль полномочий отвечает на другой: «Было ли это действие разрешено?». Это разные задачи, и подмена одной другой — архитектурная ошибка, а не вопрос удобства.

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

Сценарий: агент поддержки с тремя инструментами

Классический пример. Агенту доступны get_customer_record(), update_customer_record() и send_customer_email(). Его задача — разбирать обращения клиентов и предлагать решения. Системный промпт запрещает обновлять записи и отправлять письма без согласования.

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

Это не гипотетическая угроза в вакууме. Класс атак промпт-инъекций и «побочных эффектов» модели известен: модель интерпретирует цель и выбирает путь, который разработчик не предполагал. Ограничение, записанное словами, а не в коде, — это пожелание, а не барьер.

Где должен стоять контроль

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

Человеческое подтверждение — тот же механизм принуждения, но только если workflow действительно удерживает выполнение до получения согласия. Уведомление «агент только что отправил письмо с чувствительными данными» — это мониторинг. Чекпоинт «письмо не будет отправлено без одобрения» — это enforcement. Внешне похожие сценарии, принципиально разный риск-профиль.

Сложные случаи, о которых не рассказывают на демо

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

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

Ответы на эти вопросы и определяют, является ли механизм контроля реальным или декоративным. Fail-closed («при сбое — запрещаем») в большинстве случаев безопаснее, чем fail-open, но выбор зависит от того, насколько критична доступность конкретного процесса.

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

Для инженерных команд выводы достаточно конкретны.

Во-первых, разделяйте слои. Трассировка и авторизация — разные подсистемы с разными целями, и закладывать их стоит на этапе проектирования, а не после первого инцидента.

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

В-третьих, думайте о месте применения ограничений. Вопрос, который стоит задать команде: где именно принуждаются разрешения — в агентном фреймворке, в шлюзе инструментов или на уровне backend API? У каждого варианта свои минусы: логика внутри фреймворка проще в реализации и сложнее в доверии, шлюз централизует политику, но требует, чтобы все вызовы через него проходили, а ограничения на уровне API защищают лучше всего, но требуют работы с каждым сервисом отдельно. На практике разумна комбинация: жёсткие границы — как можно ближе к данным, агентные ограничения — как дополнительный слой.

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

Оговорка об источнике

Разбираемая публикация — по сути вендорский материал: рассуждение о границах наблюдаемости завершается описанием подхода Nuroen AI к «ограниченному исполнению» агентов и ссылкой на сайт компании. Общая идея — мониторинг не заменяет авторизацию — корректна и не нова, она обсуждается в работах по безопасности LLM-систем уже не первый год. Конкретные же продуктовые обещания вроде «проверок уверенности» и «шлюзов согласия» стоит оценивать отдельно: сторонних данных об эффективности решения Nuroen AI в публичном доступе нет.

Итог

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