Доступ AI-агентов к CRM: читать всё, менять — по правилам, удалять — никогда

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

Почему CRM — особая система для агентов

Четыре свойства делают CRM уникально рискованной для автономного доступа. Во-первых, это персональные данные в чистом виде: имена, телефоны, почты, суммы контрактов — то, за утечку чего штрафуют и по GDPR, и по 152-ФЗ. Во-вторых, это деньги напрямую: стадии сделок, скидки, счета — агент, двигающий сделку, двигает выручку. В-третьих, это внешние коммуникации: письмо клиенту от имени компании нельзя «откатить» — оно уже прочитано. В-четвёртых, это связность: компрометация одной CRM-интеграции расползается в downstream-системы, как показал взлом связки Salesloft–Salesforce (UNC6395), где скомпрометированный чат-бот открыл доступ к Salesforce и дальше — к Google Workspace, Slack, S3 и Azure сотен компаний.

Обычный сотрудник в CRM ограничен ролью, иерархией и страхом увольнения. У агента нет ни того, ни другого, ни третьего — только те границы, которые вы построили явно.

Native vs connected: где живёт агент

Первый архитектурный выбор — где исполняется агент. Salesforce описывает два варианта: CRM-native агент живёт внутри платформы, работает с realtime-данными и наследует её governance — модель разрешений, иерархию ролей, дефолты доступа. CRM-connected агент стучится снаружи через API со своим ключом и своей логикой прав.

Native проще для старта: агент по умолчанию не имеет разрешений и получает только явно выданное, действия наследуют проверки Apex, Flow и шаблонов. Но у native есть слепое пятно: иерархия ролей и общеорговые дефолты могут молча расширять доступ шире задуманного — Salesforce прямо советует их регулярно ревизовать. Connected даёт больше контроля на своей стороне — собственный слой политик, собственный журнал, — но требует построить этот слой, а не получить его в наследство.

Правило выбора: если агент действует внутри одной CRM и команда готова жить в её модели прав — native с жёсткой ревизией. Если агент ходит в несколько систем (CRM + почта + биллинг) или нужен единый журнал и approval-контур поверх всего — connected через управляемый слой доступа. Смешивать без понимания, какое правило из какого мира действует, — худший вариант: доступы складываются, а ответственность теряется.

Уровни доступа: четыре кольца

Не выдавайте «доступ к CRM» одним переключателем. Разложите его на четыре кольца с разными требованиями:

Кольцо 1. Чтение карточек и воронки. Самый безопасный уровень: агент видит сделки, контакты, историю — отвечает на вопросы, готовит сводки, подсказывает следующие шаги. Даже здесь нужны границы: scope по подразделению или региону, маскирование чувствительных полей (паспортные данные, личные телефоны), запрет массового экспорта — чтение «по одной карточке» и «выгрузить всю базу» должны быть разными разрешениями.

Кольцо 2. Обновление полей и комментариев. Агент пишет заметки, меняет статусы активностей, дополняет карточки. Требования: allowlist изменяемых полей (комментарий — да, сумма сделки — нет), валидация входов, запрет перезаписи чужих изменений без проверки, журнал «было → стало» по каждому полю.

Кольцо 3. Движение воронки и деньги. Смена стадии, скидка, создание счёта — действия, меняющие выручку. Каждое — через подтверждение человеком или через детерминированные guardrails: скидка до N% — автоматически, выше — на согласование; стадия вперёд — по условию, назад — только вручную.

Кольцо 4. Внешние коммуникации. Письма, сообщения, звонки от имени компании. Самая необратимая категория: отправленное не вернуть. Агент готовит черновики, отправляет человек — или отправляет агент, но по явному правилу с получателем из карточки, а не из сгенерированного текста.

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

Запреты по умолчанию

Список того, чего агент в CRM не делает никогда без отдельного решения и отдельной политики:

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

Каждый запрет должен быть техническим, а не инструкцией в системном промпте. Инструкция «не экспортируй базу» ломается одной косвенной инъекцией; отсутствующий scope не ломается ничем.

Approval-контур для воронки и рассылок

Подтверждения — не бюрократия, а единственная граница между «агент предложил» и «компания сделала». Три правила рабочего контура:

Человек видит источник и масштаб. В запросе на подтверждение — что меняется, в какой сделке, на какую сумму, по чьей просьбе и какие данные легли в основу. «Подтвердить?» без контекста — это кнопка согласия вслепую.
Границы сумм и охватов — числами. До какой суммы скидки агент действует сам, с какой — зовёт руководителя; сколько писем в день — норма, дальше — стоп. Числа пересматриваются по журналу, а не по ощущениям.
Подтверждённое — тоже в журнале. Кто подтвердил, когда, что видел в момент подтверждения. Иначе спор «я этого не одобрял» неразрешим.

Детерминированные guardrails дополняют человека там, где решения рутинны: проверки формата, диапазонов, соответствия стадии условиям. Агент 2026 года надёжен именно в связке «детерминированные проверки + человек на необратимое» — это один из главных трендов года по оценке Salesforce.

Уроки инцидентов: UNC6040 и UNC6395

Два инцидента экосистемы Salesforce стоит разобрать как учебные — оба бьют в точку «агент/интеграция с избыточными правами»:

UNC6040: голосовой фишинг → bulk API. Злоумышленники голосовым фишингом получали доступ и гнали массовые API-запросы для кражи данных и вымогательства. Урок для агентов: bulk-операции должны быть отдельным разрешением с лимитами и алертами, а не следствием обычного read-доступа. Агент, умеющий читать по одной записи, не обязан уметь выгружать всё.

UNC6395 (Salesloft–Salesforce supply chain). Компрометация одной чат-бот интеграции раскрылась в несанкционированный доступ к Salesforce и downstream-приложениям сотен компаний. Урок: SaaS-to-SaaS связи — это цепочки доверия, и каждая должна иметь свой scope, свой отзыв и свой мониторинг. Доверенный вендор сегодня — не гарантия завтра; отзыв токена интеграции должен занимать минуты.

Оба инцидента объединяет standing privilege: права, выданные навсегда и шире необходимого. Агент с короткоживущим scope на конкретную задачу не превращается в вечный мост для атакующего.

Журнал, который читается по сделке

Аудит CRM-действий агента обязан отвечать на вопрос бизнеса, а не только SOC: «что робот сделал с моей сделкой?». Запись журнала: когда, какой агент и по чьему поручению, какое действие и с какими аргументами, что было до и стало после, что вернула система, кто подтвердил (если требовалось). Связка «поручение → действия → подтверждения» должна собираться в одну трассу: по сделке видно всё, что с ней делал агент за период. Это и расследование инцидентов, и ответ аудитору, и разбор споров с клиентами — «письмо ушло, потому что менеджер подтвердил черновик в 14:32».

Чеклист подключения агента к CRM

Где Codenik

Codenik — это connected-вариант, доведённый до дисциплины: агент ходит в CRM не с API-ключом «на всё», а через инструменты с field-level скоупами. Чтение карточек — широко, изменение суммы — только с approval, массовый экспорт и удаление — отсутствуют как инструменты в принципе. Секреты агент не держит: доступ выдаётся just-in-time через брокер и живёт час, а не год. Каждое действие — запись в едином журнале с трассой «поручение → вызовы → подтверждение», одинаковой для Salesforce, HubSpot и Bitrix24. А когда вендорская интеграция становится вектором — как в UNC6395 — отзыв одного скоупа рвёт цепочку за минуты, а не расследует её неделями.

Короткий вывод

Агент в CRM — это сотрудник с доступом к деньгам и репутации, но без страха увольнения и с буквальным послушанием любому тексту. Давайте ему чтение широко, запись — точечно, воронку и рассылки — через подтверждения, а удаление и массовый экспорт — никогда. Проверяйте наследованные права, считайте bulk отдельным разрешением и пишите журнал так, чтобы его читал владелец сделки, а не только SOC. Тогда агент станет лучшим менеджером по данным — а не самым быстрым способом лишиться базы.