Безопасность Agentforce и модель общей ответственности

Краткий ответ

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

Главный риск заключается не в компрометации платформы. Это чрезмерно авторизованный агент, который раскрывает информацию не тому субъекту или выполняет действие, которое не должен был выполнять, — обе эти ошибки полностью лежат на стороне организации.

Распределение ответственности на практике

Новые риски, не существовавшие в традиционных CRM

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

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

Третий — утечка внутреннего контента во внешний канал. Статья, написанная для представителей, с дисконтными маржами или формулировками возражений, не должна попадать к клиенту, и разделение должно основываться на белом списке, а не на черном.

Четвертый — тихое расширение полномочий: добавление действия или разрешения для решения конкретной проблемы без прохождения процедуры утверждения.

Пять ключевых механизмов контроля

Поиск в контексте пользователя. Это единственный механизм контроля, и если он нарушен, все остальные бесполезны.

Раздельное разрешение для каждого Action, согласно принципу минимальных привилегий. Агент, получающий один широкий профиль, исключает любой будущий контроль.

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

Человеческое одобрение необратимого действия. Это механизм контроля, который превращает потенциальный сбой в своевременно остановленное событие.

Журнал аудита, связывающий пользователя, действие, источник и утверждающего. Без него нет ответа на аудиторский вопрос: «На основании чего агент это сделал?».

Общие принципы модели разрешений в Salesforce подробно описаны в документе Модель разрешений в Salesforce.

Что проверять перед запуском

Тестирование персон: те же десять-двадцать вопросов задаются в разных ролях — представитель, менеджер, ограниченный пользователь, внешний клиент — и ответы сравниваются. Любое несоответствие, не объясняемое разрешением, является проблемой.

Контентное Red Teaming: целенаправленные попытки извлечь несанкционированную информацию, выполнить запрещенное действие и обойти эскалацию. Сценарии пишутся один раз и сохраняются для повторного запуска в каждой версии.

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

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

О том, как эти тесты интегрируются в более широкую структуру тестирования, рассказывается в Тестирование Agentforce.

Сценарий: проблема, обнаруженная при тестировании персоны

Медицинская компания подготовила внутреннего агента для ответа на вопросы о процедурах. При тестировании персоны перед запуском было обнаружено, что пользователь с административной ролью получил ответ, основанный на процедуре, предназначенной только для медицинского персонала.

Причина не была в ошибке агента. Индекс был построен с использованием учетной записи интеграции с широким доступом, и поиск не был ограничен разрешениями пользователя. Потенциально то же раскрытие могло произойти по любому вопросу, связанному с этой областью.

Исправление включало два этапа: перенос поиска в контекст пользователя и явная пометка конфиденциальных документов, чтобы они не попадали в общий индекс. Тест был добавлен как постоянный сценарий, запускаемый перед каждым обновлением версии.

Риски и превентивные меры

Метрики безопасности

Структура утверждений, в рамках которой применяются механизмы контроля, подробно описана в документе Управление ИИ для Agentforce.

При необходимости сопровождения в определении модели ответственности и тестировании перед запуском, услуги Agentforce и AI — это практический путь для дальнейших действий.

Чек-лист безопасности перед запуском

• ☐ Документ о разделении ответственности подготовлен и утверждён
• ☐ Условия использования данных в модели задокументированы в письменной форме
• ☐ Поиск выполняется в контексте разрешений пользователя
• ☐ Тестирование персон выполнено для каждого уровня разрешений
• ☐ Для каждого Action есть отдельное разрешение и внутренняя валидация
• ☐ Необратимые действия требуют человеческого одобрения
• ☐ Во внешнем канале действует белый список контента
• ☐ Сценарии контентного Red Teaming написаны и выполнены
• ☐ Журнал аудита связывает пользователя, действие, источник и утверждающего
• ☐ Политика хранения журналов и содержания разговоров одобрена