Штатная связка Salesforce Agentforce выявила риск внешнего ввода
Исследователи в августе 2026 года описали штатную цепочку в Salesforce, где Email-to-Case или Web-to-Case создаёт обращение из входящего сообщения, Flow передаёт его данные в промпт Agentforce, а ответ агента возвращается в комментарий и исходящее письмо. Такая последовательность создаёт маршрут от публичного интернета к инструкциям внутреннего агента и обратно, хотя отдельные функции работают по документации.
Риск возникает на стыке функций платформы
Email-to-Case и Web-to-Case применяются для приёма обращений клиентов, в том числе в авиакомпаниях и гостиницах. Flow в Agentforce рекомендован Salesforce как механизм реакции агента на события: создание записи или обновление обращения может передавать данные в его запрос.
В описанном сценарии внешнему неаутентифицированному отправителю доступна цепочка «письмо — запись обращения — промпт агента — действие агента — комментарий — ответ». Авторы материала подчёркивают, что это не эксплойт и не следствие неверной настройки: уязвимый контекст формируется при сочетании предусмотренных возможностей.
На итоговый риск влияют включённые каналы приёма обращений, срабатывающие триггеры, объекты, открытые гостевым пользователям, маршруты передачи недоверенных данных в автоматизацию и используемая агентом версия модели. Фильтр промптов не обязательно различает происхождение текста и сам по себе не знает, что конкретный ввод пришёл через Email-to-Case.
Почему разовой проверки поставщика недостаточно
Проверка поставщика во время закупки не охватывает агент, который появился в платформе позднее. Авторы отмечают, что агенты всё чаще создаются бизнес-подразделениями и действуют с правами создателей: маркетинг может поручить им отчёты по воронке продаж, а финансы — сверку счетов.
Отдельная проблема — видимость. В документе OWASP Agentic Skills Top 10 категория «No Governance» описывает навык, развёрнутый и управляемый в сторонней платформе, который недоступен внешним сканерам. Поэтому политика, комитет или анкета не отвечают на прикладные вопросы: сколько агентов работает, к каким данным они имеют доступ и кто отвечает за каждый из них.
Что должно стать основой контроля
Авторы предлагают выстраивать управление снизу вверх: начать с постоянно обновляемого обнаружения агентов в конфигурациях приложений, OAuth-разрешениях, сети, конечных устройствах, почте и браузере. Следующий уровень — оценка настроек платформ, включая каналы входящих данных и доступ гостевых пользователей, связанных с триггерами агентов.
Далее каждому агенту требуются идентичность, назначенный владелец и жизненный цикл. Контроль использования должен показывать, кто создаёт агентов, через какой интерфейс и с какими данными, а ограничения — учитывать фактическую потребность в правах и контекст развертывания. Рантайм-контроль имеет смысл только при наличии этих сведений.
Для бизнеса практический вывод состоит в проверке не только модели или промпта, но и всей прикладной цепочки вокруг агента. В Salesforce это означает отдельно просмотреть Email-to-Case, Web-to-Case, Flow, гостевые права и правила передачи содержимого обращений в Agentforce, а затем закрепить за каждой такой автоматизацией владельца.