Стандартная связка функций Salesforce способна провести сообщение внешнего отправителя от почтового ящика службы поддержки прямо в контекст ИИ-агента — а затем отправить ответ наружу. Безопасность ИИ-агентов в такой схеме зависит не только от модели и фильтра промптов, но и от старых настроек CRM, которые могли никто не пересматривать после внедрения Agentforce, сообщает The Hacker News.
Речь не об отдельной уязвимости и не о неверно выставленной галочке. В Salesforce для запуска Agentforce по событиям рекомендуется использовать Flow: например, при создании или обновлении обращения система передаёт данные в промпт агента. Параллельно штатные механизмы Email-to-Case и Web-to-Case превращают входящие письма и сообщения с сайта в записи обращений. В связке получается маршрут: интернет → письмо или веб-форма → обращение → промпт агента → действие агента → комментарий к обращению → внешний ответ.
Для авиакомпании, отеля или крупного ритейлера это выглядит как обычная автоматизация поддержки. Но незалогиненный человек получает канал, через который может влиять на текст, поступающий агенту с внутренними правами. Дальше всё определяют детали конкретной инсталляции: какие формы приёма обращений включены, какие триггеры запускают Flow, доступны ли объекты гостевым пользователям, что именно передаётся в агентский контекст и к какой версии модели обращается платформа.
Промпт-фильтр сам по себе эту картину не видит. Он может оценить содержимое сообщения, но не обязательно понимает, что строка в промпте пришла из анонимного письма, а не из проверенной внутренней записи. Отсюда неприятный вывод для администраторов и команд безопасности: проверка поставщика на этапе закупки не отвечает на вопрос, как агент встроен в уже работающие процессы компании.
Агент наследует не только данные, но и риски платформы
Исследователи описали этот сценарий в августе 2026 года как пример проблемы «унаследованных» агентов. Они появляются внутри CRM, ServiceNow, систем документооборота и других зрелых платформ, где уже накопились интеграции, роли, исключения и десятки лет автоматизации. Риск часто возникает не внутри нейросети, а на стыке штатных возможностей приложения.
Схожая логика проявилась в кампании City-Forum, которую авторы материала называют действующей глобальной операцией по краже данных против экземпляров Salesforce и ServiceNow. Кампания наблюдается с марта 2025 года и эксплуатирует разрыв между возможностями платформ и тем, как предприятия настроили их в реальной жизни. Это важное уточнение: даже идеальная модельная защита не компенсирует публичный вход в процесс, лишние права сервисного аккаунта или старый автоматический маршрут данных.
Проблему усугубляет доступность конструкторов. Маркетинговая команда может собрать агента для отчётов по воронке, финансовая — для сверки счетов, а разработчик — подключить кодового помощника к рабочему чату. Обычно агент работает с полномочиями создателя: иначе он просто не выполнит полезную задачу. В результате «теневой ИИ» превращается в теневых агентов — не разовый обмен данными с чат-ботом, а постоянно работающие процессы с доступом ко всему, что когда-то было выдано их владельцу.
Отдельный риск — агенты, создающие других агентов. Кодовый агент, получивший задачу в чате, способен подготовить и развернуть нового помощника почти так же, как открыть pull request. Оркестраторы разбивают работу на подагентов с собственными подключениями. Модель управления, в которой появление каждого агента предполагает ручную заявку человека, быстро перестаёт соответствовать реальности.
Политики без инвентаря не управляют ничем
Во многих компаниях управление агентами пока существует в виде политики допустимого использования, комитета раз в месяц и набора принципов. Но на базовые операционные вопросы — сколько агентов запущено сейчас, к каким данным они имеют доступ и кто за каждого отвечает — эти документы не дают ответа. OWASP в Agentic Skills Top 10 относит к категории «No Governance» ситуацию, когда навык развёрнут внутри сторонней платформы и недоступен внешнему сканеру. То есть инструменты безопасности, которые смотрят на периметр, могут не видеть большую часть среды, где живут агенты.
Практический подход начинается не с запрета, а с инвентаря. Компании нужно непрерывно находить агентов в конфигурациях приложений, OAuth-разрешениях, почтовых маршрутах, сетевых данных, браузерах и конечных точках. Затем — сопоставлять настройки платформ с безопасным состоянием, назначать владельца и жизненный цикл каждому агенту, учитывать фактические сценарии использования и применять принцип наименьших привилегий. Проверка простая: если случайно выбранный агент не может за день обрести конкретного владельца, инвентаря в рабочем смысле нет.
Уровень риска тоже нельзя назначать по одному признаку «это ИИ». Агент в изолированной среде разработки и агент, который отвечает клиентам, читает CRM и запускается из публичной формы, должны иметь разный приоритет даже при одинаковой модели. Только после обнаружения, оценки конфигурации, назначения владельца и понимания прав имеет смысл включать контроль во время выполнения: иначе он будет принимать решения вслепую.
Ставки растут и на уровне регулирования. В материале приводятся максимальные санкции EU AI Act: до 35 млн евро или 7% мирового годового оборота за запрещённые практики, а для других нарушений — до 15 млн евро или 3%. Опыт GDPR уже показал, что регулятору недостаточно политики на бумаге: British Airways и Marriott получили штрафы в 20 млн и 18,4 млн фунтов соответственно не за отсутствие деклараций, а за неспособность подтвердить достаточный уровень защиты на практике.
Главный вопрос для российских команд не в том, появится ли у бизнеса ещё один агент. Он уже может быть собран в CRM или корпоративном чате без отдельного проекта безопасности. Вопрос в другом: сможет ли компания увидеть всю цепочку от внешнего события до действий агента и доказать, кто отвечает за каждое её звено. Оригинальный разбор и упомянутые в нём материалы доступны у .