Я предоставил ИИ-агенту доступ к финансам моей семьи и позволил ему общаться со мной через MCP-сервер. В течение нескольких минут он уже мог ответить на вопрос: «Сколько мы потратили на продукты в прошлом месяце?» и перевести деньги в сбережения. Тот же интерфейс позволил ему стереть историю транзакций за целый год одной командой. Жестко закодированная проверка безопасности в инструментах, которые вызывал агент, остановила удаление — а не умный системный промпт.

Почему это важно

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

Риск реален. Пользователи доверяют ИИ-агентам конфиденциальные данные и критически важные рабочие процессы. Когда это доверие подрывается, внедрение технологий замедляется, регуляторы могут вмешаться, а финансовые последствия могут быть тяжелыми. Главный вопрос заключается в следующем: как гарантировать, что агент никогда не совершит необратимое действие без реального решения человека?

Промпт-инжиниринг — это ложное чувство безопасности

Разработчики часто ужесточают системный промпт, добавляя такие правила, как «Никогда не удаляй данные без вопроса» или «Всегда подтверждай изменения баланса». Промпт-инжиниринг рассматривает поведение модели как набор рекомендаций, которым модель может следовать, а может и нет. На практике модели соблюдают формулировки до тех пор, пока настройки температуры (temperature), лимиты токенов или тонкое изменение контекста не заставят их пропустить правило. Инцидент с удалением базы данных в 2025 году доказал, что даже четкую инструкцию можно проигнорировать, когда внутренние рассуждения модели расходятся с заданным вектором.

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

Перенос безопасности из промпта в инструменты

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

  1. Мобильное приложение перехватывает входящие SMS-сообщения от банков.
  2. Легкая локальная языковая модель извлекает сумму транзакции и название торговой точки.
  3. Lester записывает обработанную запись в приложение для планирования бюджета через API-вызов.

Все три шага были доступны Lester только для чтения: он мог только добавлять данные, но никогда не мог удалять или изменять существующие записи. Система работала безупречно, пока я не добавил голосовой интерфейс с использованием MCP (Multi-Channel Prompt) сервера, который позволил мне спрашивать: «Сколько мы потратили на продукты в прошлом месяце?» или «Переведи деньги в сбережения». MCP-сервер выступает в роли посредника, предоставляя агенту набор инструментов (add-transaction, query-spending, transfer-funds, delete-history).

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

Чтобы предотвратить это, я перестроил уровень инструментов, внедрив три простых правила:

  • Инструменты только для чтения (read-only) выполняются немедленно. Все, что только извлекает информацию — проверка баланса, сводки расходов, запросы транзакций — не требует подтверждения человеком. Риск вызова read-only операции ничтожен.
  • Мутирующие инструменты объявляют о намерении перед действием. Операции, которые изменяют состояние, но являются обратимыми (добавление транзакции, обновление категории), продолжаются после того, как агент отправляет короткое сообщение о «намерении» (например, «Добавляю транзакцию на продукты»). Система логирует намерение и может вывести его пользователю для аудита, но не блокирует выполнение.
  • Деструктивные инструменты отказываются работать без явного токена. Команды, которые удаляют, обрезают или иным образом делают данные невосстановимыми, блокируются на уровне инструмента. Когда Lester отправляет запрос на удаление, инструмент возвращает отказ, который включает точные данные, которые он собирается удалить, и запрос на токен, созданный человеком. Затем агент должен предоставить подтверждающий пакет второго шага, содержащий confirm: true и токен. Без этого операция прерывается.

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

Почему это важно для пользователей

Самым большим препятствием для любой схемы подтверждения является усталость (fatigue). Если система запрашивает одобрение на каждое мелкое действие — «Вы хотите добавить этот кофе?» — пользователи быстро начинают нажимать «да», не читая. Результатом становится ложное чувство безопасности. Ограничивая только необратимые действия, мы удерживаем человека в цикле управления именно там, где это необходимо. Пользователь гораздо с большей вероятностью проверит запрос, который может удалить всю финансовую историю за месяц, чем тот, который просто добавляет одну строку.

Безопасность на уровне инструментов также упрощает соблюдение нормативных требований. Такие правила, как Закон ЕС об ИИ (AI Act) или Закон США SAFE Act, требуют доказуемых мер защиты от непреднамеренной потери данных. Жестко закодированный отказ в API — это проверяемый механизм контроля, который можно логировать, инспектировать и подтверждать сторонними аудиторами. Текст промпта, напротив, непрозрачен, зависит от версии и его трудно доказать в суде.

Контраргумент: «Разве мы не можем просто улучшить промпты?»

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

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

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

На что стоит обратить внимание в будущем

Сообщество начинает рассматривать безопасность на уровне инструментов как приоритетную задачу. Несколько проектов с открытым исходным кодом теперь предоставляют «безопасные API», которые автоматически отклоняют деструктивные вызовы без человеческого токена. Стандартные организации разрабатывают спецификации для согласия на уровне действий (action-level consent), где каждый вызов API включает подписанный пакет намерения, который можно проверить в дальнейшем.

Предприятиям, которые уже предоставляют доступ к своим внутренним сервисам ИИ-агентам, следует проверить свои API по трем пунктам:

  1. Идемпотентность — поддерживает ли эндпоинт повторяющиеся вызовы без побочных эффектов? Если нет, добавьте уровень подтверждения.
  2. Явные поля намерения — требуйте от вызывающей стороны указывать цель мутирующего запроса.
  3. Токены участия человека (human-in-the-loop) — генерируйте краткосрочные, криптографически подписанные токены, которые должны сопровождать любой деструктивный вызов.

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

Итог

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