Агент опасен не потому, что «умный», а потому, что получил кнопку
Бизнес обычно начинает с безобидного помощника: найти клиента в CRM, сверить остаток, подготовить письмо. Затем к нему добавляют инструменты — создать сделку, изменить цену, провести документ, отправить сообщение. В этот момент языковая модель перестаёт быть генератором текста и становится участником бизнес-процесса.
Ошибку здесь легко сформулировать неверно: «нужно лучше настроить промпт, чтобы агент не делал лишнего». Промпт полезен для поведения, но не является контуром доступа. Модель может ошибиться, неверно понять двусмысленную просьбу или обработать вредоносную инструкцию из письма и документа. Ограничение должно работать даже тогда, когда вывод модели неправильный.
NIST предлагает рассматривать агентные системы по двум осям: права инструмента — чтение, ограниченная запись или широкая запись — и доверенность среды. RAG по внутренним материалам с доступом только на чтение существенно отличается от компьютерного агента, который действует в открытом интернете и меняет состояние систем. Чем шире права и менее доверенна среда, тем сильнее должны быть технические ограничения.
Для малого бизнеса практический вывод прост: не давайте модели прямой доступ к CRM, 1С, почте и базе данных. Поставьте между ними шлюз действий. Модель формирует типизированное предложение, а обычный программный слой проверяет права, лимиты, дубли, обязательное согласование и только затем вызывает узкую операцию.
Три независимые причины ограничивать агента
OWASP называет Excessive Agency сочетанием избыточной функциональности, избыточных разрешений и избыточной автономности. Эти причины полезно разделять.
**Избыточная функциональность.** Для составления черновика письма агенту дали почтовый модуль, который умеет не только читать, но и отправлять и удалять сообщения. Даже если учетная запись ограничена, лишняя функция уже увеличивает последствия ошибки.
**Избыточные разрешения.** Инструмент для поиска товара подключается к базе под учётной записью, которая может менять цены и удалять строки. Модель может вызвать только функцию поиска, но у промежуточного сервиса остаются опасные полномочия.
**Избыточная автономность.** Функция действительно нужна и права настроены, однако операция проводится без подтверждения: письмо отправляется, скидка применяется, платежное поручение создаётся в финальном статусе.
Эти слои закрываются разными мерами. Узкий каталог инструментов уменьшает функциональность. Отдельные сервисные учётные записи и права на уровне объектов уменьшают разрешения. Предпросмотр, лимиты и человеческое утверждение уменьшают автономность. Один «системный промпт безопасности» не заменяет ни один из трёх механизмов.
Архитектура шлюза действий
Рабочий контур можно собрать из восьми компонентов.
1. Контекст пользователя
Каждый запрос связан не только с агентом, но и с сотрудником, от имени которого выполняется работа: его ролью, подразделением, клиентским портфелем и текущей сессией. Общая привилегированная учётная запись стирает границы: менеджер видит чужих клиентов, а оператор поддержки получает финансовые функции.
Если используется удалённый MCP-сервер, спецификация требует проверять аудиторию токена и запрещает передавать входящий токен дальше как есть. Шлюз получает отдельный токен для целевого API с нужным назначением и минимальными областями. Токены не передаются модели и не сохраняются в истории диалога.
2. Планировщик без права записи
Модель читает разрешённый контекст и решает, какое действие предложить. На этом этапе она не меняет данные. Результат — не SQL, URL или командная строка, а объект по строгой схеме, например:
```json
{
"action": "crm.create_followup",
"customer_id": "c_1842",
"due_date": "2026-08-19",
"reason": "client requested a callback"
}
```
Поле `action` выбирается из короткого списка. Идентификатор клиента должен существовать в уже разрешённом наборе. Дата проходит форматную и бизнес-проверку. Поле `reason` отображается человеку, но никогда не исполняется как инструкция.
3. Валидатор схемы
Обычный код проверяет типы, обязательные поля, длину строк, перечисления и допустимые диапазоны. Неизвестное поле отклоняется. Модель не может добавить `admin=true`, вторую команду внутри строки или произвольный адрес назначения.
Структурированный JSON сам по себе не делает операцию безопасной. Он лишь создаёт границу, на которой можно применить детерминированные правила. После схемы идут проверка существования объектов, статусов, связей и ограничений процесса.
4. Движок политик
Политика отвечает на вопросы, которые нельзя отдавать модели:
- может ли этот сотрудник выполнять действие;
- разрешено ли оно для этого клиента и подразделения;
- допустимы ли сумма, скидка, количество и срок;
- требуется ли второй согласующий;
- разрешено ли действие в текущем статусе документа;
- не превышен ли дневной или минутный лимит;
- работает ли целевая система в тестовом или боевом контуре.
Правило должно возвращать не только «запрещено», но и понятную причину. Тогда сотрудник может исправить данные или выбрать обычный маршрут, а команда видит, какие ограничения чаще всего мешают автоматизации.
5. Предпросмотр и оценка риска
Шлюз показывает человеку будущий эффект: какие поля изменятся, кому уйдёт письмо, какая цена была и станет, какие документы создадутся. Для письма показываются адресаты и полный текст. Для CRM — сравнение до и после. Для 1С — вид документа, организация, контрагент, сумма и статус.
Действия делятся минимум на три класса:
- **низкий риск:** создать внутреннюю задачу или черновик;
- **средний риск:** изменить обратимое поле, назначить ответственного;
- **высокий риск:** отправить внешнее сообщение, поменять цену, провести документ, инициировать платёж или удалить данные.
Низкий риск после успешного пилота можно выполнять автоматически в узких пределах. Средний требует явного подтверждения или пакетного утверждения. Высокий сохраняет штатное согласование в целевой системе; кнопка в чате не должна обходить бухгалтерский или договорной контроль.
6. Детерминированный исполнитель
Исполнитель не рассуждает. Он принимает уже разрешённую команду и вызывает конкретный метод, например `create_crm_followup`, а не `run_sql`. Инструмент имеет минимальную функциональность и подключается под отдельной сервисной ролью.
MCP рекомендует валидировать входы инструментов, применять контроль доступа и ограничение частоты, очищать результаты, ставить тайм-ауты и журналировать вызовы. Эти меры полезны независимо от самого протокола: MCP описывает интерфейс, но не отменяет защиту API и базы данных.
7. Идемпотентность и очередь
Сетевой тайм-аут не означает, что операция не состоялась. Если повторить `создать счёт` вслепую, появится дубль. Для каждой бизнес-команды формируется стабильный ключ из типа действия, объекта и версии запроса. Исполнитель сначала проверяет, не обработан ли ключ, и возвращает прежний результат.
Практичный вариант — транзакционная очередь: команда и запись аудита сохраняются вместе, затем рабочий процесс доставляет её во внешнюю систему. Отдельная сверка ищет зависшие и частично выполненные операции. Агент не решает, повторять ли запрос после неопределённого ответа.
8. Аудит и обратная связь
Журнал хранит пользователя, входной запрос, версию модели и политики, предложенную команду, решение правил, предпросмотр, подтверждение, фактический ответ API и итоговый статус. Секреты и лишние персональные данные туда не попадают.
Для оценки качества нужны не только успешные вызовы. Полезны доля отклонённых предложений, причины отказа, ручные исправления перед подтверждением, дубли, откаты и действия, которые сотрудник предпочёл выполнить обычным способом. Эти данные показывают, где агент экономит время, а где создаёт новую очередь проверки.
Что давать агенту вместо универсальных инструментов
Опасные интерфейсы выглядят удобно: `execute_sql`, `run_shell`, `fetch_url`, `send_email(to, subject, body)` без ограничений. Они переносят почти всю безопасность в текстовые инструкции.
Узкие инструменты описывают бизнес-намерение:
- `find_customer_by_phone` — чтение ограниченного набора полей;
- `create_callback_draft` — внутренняя задача без отправки клиенту;
- `prepare_invoice_draft` — непроведённый документ по существующему заказу;
- `request_discount_approval` — заявка, а не изменение цены;
- `send_approved_template` — только утверждённый шаблон и разрешённый адресат;
- `attach_document_to_case` — добавление файла в один доступный кейс без удаления старых.
Такое API кажется более медленным в разработке, зато каждое действие имеет владельца, тесты и границу ущерба. Для малого бизнеса десять узких операций обычно дают больше пользы, чем универсальный агент с доступом ко всему рабочему столу.
Локальная модель не отменяет контроль действий
Локальный запуск решает вопросы передачи данных, задержки и зависимости от внешнего API. Он не исправляет двусмысленность запроса, prompt injection и ошибочный выбор инструмента. Модель внутри периметра может так же неверно провести документ, если ей дали широкие права.
Рациональная схема оставляет локально модель, контекст, политики, журнал и шлюз. CRM или 1С доступны только исполнителю в отдельном сегменте. Внешняя модель, если она используется, получает обезличенный минимум и не видит токены. Выбор размещения меняет границу данных, но принцип минимальных полномочий остаётся тем же.
Модельная экономика
Предположим, сотрудники выполняют 300 однотипных действий в день. Поиск объекта, заполнение формы и проверка занимают четыре минуты. Агент сокращает подготовку до одной минуты, но 30% операций требуют ещё двух минут ручной проверки. Экономия составляет:
- исходно: 300 × 4 = 1 200 минут;
- с агентом: 300 × 1 + 90 × 2 = 480 минут;
- модельный эффект: 720 минут, или 12 часов в день.
Из выгоды вычитаются разработка узких инструментов, интеграция, сопровождение политик, аудит и разбор исключений. Один ошибочный платёж или массовая рассылка может перекрыть месячную экономию, поэтому стоимость риска входит в расчёт. Эти цифры — пример, а не результат реального предприятия.
Четырёхнедельный пилот
**Неделя 1.** Выберите одно обратимое действие: создать внутреннюю задачу по существующему клиенту. Зафиксируйте базовое время, ошибки и права пользователей.
**Неделя 2.** Реализуйте чтение и типизированное предложение без записи. Добавьте схему, политику и предпросмотр. Проверьте неверные идентификаторы, чужих клиентов, лишние поля и вредоносный текст в заметке.
**Неделя 3.** Подключите детерминированный исполнитель в тестовом контуре. Добавьте идемпотентный ключ, лимиты, журнал и имитацию сетевого тайм-аута.
**Неделя 4.** Разрешите запись для небольшой группы с подтверждением каждого действия. Считайте время до завершения, долю правок, отказы политик, дубли и откаты.
Переход к следующему инструменту оправдан, если нет критических ошибок, дубли блокируются, сотрудник понимает будущий эффект, а экономия сохраняется после проверки. Автоматическую отправку или проведение документов оставьте на отдельный этап.
Главный управленческий вывод: агенту нужен не «доступ к системе», а короткий каталог разрешённых намерений. Внутрик может принести целую связку ключей, но рабочий шлюз должен принимать только один подходящий ключ, проверять владельца и показывать человеку, какая дверь откроется.