Tool‑calling и агенты: как дать LLM доступ к CRM и не устроить катастрофу

Представьте: ваш AI‑агент, которому вы поручили «просто разобрать почту», случайно удалил базу контактов или отправил всем VIP‑клиентам тестовое сообщение «Привет, я робот». Звучит как ночной кошмар CTO, верно?

Агенты с функцией tool‑calling (вызова инструментов) – это уже не просто чат-боты, которые отвечают текстом. Это полноценные сотрудники, у которых есть «руки»: они могут читать карточки в CRM, ставить задачи, бронировать встречи в календаре и даже писать клиентам. Но давать LLM прямой доступ к продакшену без контроля – всё равно что пустить стажёра в серверную с правами админа. В этой статье мы разберём архитектуру безопасности, которую мы используем в CrmAI, чтобы спать спокойно: allowlist, песочницы, лимиты, human‑in‑the‑loop и защиту от дублей. Всё, чтобы дать модели свободу действий, но оставить пульт управления у бизнеса.

Главные принципы: строим «периметр безопасности»

Безопасность агента – это не одна настройка, а слоеный пирог. Если откажет один слой, должен сработать следующий. Вот 8 принципов, на которых мы строим защиту:

• Allowlist (Белый список): Запрещено всё, что не разрешено. Мы явно прописываем: «этому агенту можно делать create_task, но нельзя delete_contact». Никаких SELECT *.
• Sandbox (Песочница): У агента свои собственные права доступа. Он не работает под правами админа. Более того, у нас разделены среды: dev, stage и prod. Агент учится в песочнице, где ничего нельзя сломать.
• Лимиты (Rate Limiting): Не даем агенту «сойти с ума». Максимум 5 действий за диалог, таймауты на выполнение, бюджет токенов. Если агент зациклился – система его остановит.
• Human‑in‑the‑loop (Человек в контуре): «Красная кнопка» для важных действий. Хочешь отправить письмо клиенту? Создай черновик, а менеджер нажмет «Отправить». Это золотой стандарт для начала работы.
• Тотальный аудит: Каждое, абсолютно каждое действие логируется. tool_call_id, кто вызвал, с какими данными, что ответила система. Это нужно для разбора полетов.
• Идемпотентность: Если агент случайно нажмет кнопку дважды (или случится сетевой сбой и повтор запроса), система должна понять, что это то же самое действие, и не создавать две одинаковые задачи.
• Защита от повторов (Replay Protection): Чтобы злоумышленник не мог перехватить запрос агента и «проиграть» его снова. Используем подписи и временные метки.
• Fail‑safe (Безопасный отказ): Если что-то пошло не так (отвалилась база, непонятный ответ) – агент должен остановиться и позвать человека, а не пытаться «починить» всё случайными действиями.

Эталонная архитектура: как это работает под капотом

Представьте работу агента как проход в элитный клуб. Есть фейсконтроль, охрана и менеджер зала. Вот как выглядит путь запроса:

1. Intent Router (Фейсконтроль). Сначала мы понимаем, чего хочет пользователь. «Хочу отчет» и «Удали всё» – это разные сценарии. Роутер направляет запрос в нужный коридор, где действуют свои правила.
2. Policy Guard (Охрана). Проверяем пропуск. Есть ли у этого пользователя права на это действие? Не превышен ли лимит запросов? Соответствует ли запрос региону данных?
3. Tool Gateway (Входная дверь). Это единственный путь к CRM. Гейтвей очищает данные (маскирует телефоны, если надо), проверяет, что инструмент в белом списке, и добавляет ключ идемпотентности.
4. Human Approval (Менеджер). Если действие критичное (удаление, изменение статуса сделки, отправка письма), запрос ставится на паузу. Агент говорит: «Я подготовил черновик, посмотрите?». Человек подтверждает.
5. Execution & Audit (Выполнение). Только теперь действие реально выполняется. Всё записывается: время, параметры, результат.
6. Post-check (Контроль качества). Система проверяет, что всё прошло нормально. Если агент начал сбоить (3 ошибки подряд) – звучит сирена (алерт админам).

Allowlist: что можно, а что нельзя

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

Sandbox и защита от «эффекта обезьяны с гранатой»

Даже самый умный AI может ошибиться. Мы страхуемся технически:

• Раздельные ключи: У агента свои ключи API. Если они утекут – мы отзовем только их, не ломая работу всей интеграции.
• Жесткие тайм-ауты: Инструмент должен отработать за 5-10 секунд. Если дольше – обрываем, чтобы не вешать систему.
• Идемпотентность (ещё раз): Это важно. Мы генерируем уникальный хеш (ключ) для каждого намерения. Если агент попробует создать задачу с тем же ключом второй раз – CRM просто вернет "ОК" (или "Уже создано"), но не создаст копию.
• Принцип «Need to know»: Агент не видит всю БД. Он видит только то, что вы ему разрешили видеть через API.
• Audit-ready: Мы храним не просто "было действие", а "дифф": состояние ДО и состояние ПОСЛЕ. Это спасает при разборе инцидентов.

5 безопасных сценариев для старта

Не нужно сразу пытаться заменить весь отдел продаж. Начните с простых, изолированных задач:

Чеклист готовности к проду

Прежде чем «открыть шлюзы», пройдитесь по этому списку. Если хоть один пункт «нет» – вы не готовы.

• Роли назначены: Кто отвечает, если агент «накосячит»? Есть ли дежурный инженер?
• Allowlist задокументирован: Вы точно знаете, какие методы доступны. Тесты на попытку вызова запрещенного метода проходят.
• Метрики настроены: Вы видите не только «всё работает», но и качество (groundedness), задержки, количество отказов.
• Алерты подключены: Если посыплются ошибки 500 – вы узнаете об этом раньше клиентов.
• Есть «Красная кнопка»: Вы можете отключить tool-calling одной командой, не останавливая остальную работу CRM.
• Команда обучена: Менеджеры знают, что такое «черновик от агента» и как его валидировать.

FAQ: Частые вопросы CTO

В: Можно ли дать агенту доступ к полной карточке клиента, «чтобы он всё знал»?
О: В проде – категорически нет. Это нарушение принципа минимальных привилегий и огромный риск утечки PII (персональных данных). Давайте только агрегированные поля (сегмент, чек, стадия) и последние 3 активности.

В: Как избежать «бесконечного цикла», когда два агента начнут общаться друг с другом?
О: Жесткие лимиты на количество шагов (steps) в одном диалоге. Плюс детектор циклов (если агент вызывает один и тот же tool с теми же параметрами подряд – стоп).

В: Как быть с законом о защите данных (Закон РК о персональных данных, GDPR)?
О: Логируйте всё. Не передавайте в LLM «сырые» данные, используйте псевдонимизацию или маскирование. В логах аудита не должно быть чувствительных данных в открытом виде.

В: Агент иногда «галлюцинирует» и вызывает инструмент неправильно. Что делать?
О: Внедрите шаг «Reasoning» перед действием. Пусть агент сначала напишет план: «Я хочу вызвать инструмент X, потому что...», и только потом вызывает. И используйте строгую типизацию параметров (Pydantic/Zod), чтобы отсекать мусор на входе.

Полезное чтение

• Как внедрять LLM безопасно: промпт-инжиниринг и ролевые модели
• Качество данных: фундамент для работы агентов