Вы находитесь здесь:
Поддержание Trust посредством действий Agentforce в устаревшем конструкторе
Агенты, подключенные к каналам сотрудников, например, Lightning Experience, мобильному приложению Salesforce и Slack, ограничивают доступ к субагентам и действиям по умолчанию, в зависимости от контекста конечного пользователя. Агенты Agentforce Service, подключенные к каналам клиентов, например, расширенным каналам службы сообщений и расширенному чату, требуют дополнительной конфигурации для обеспечения безопасного доступа. Настраивая агента, важно продумать требования к безопасности и идентификации для сценария использования и предоставить агентам только действия и доступ, необходимые для выполнения задач, которые они могут выполнить автономно от имени клиентов. Для конфиденциальных действий рекомендуем встроить проверку клиента напрямую в поток действия.
Требуемые версии
| Доступно в версиях: Lightning Experience |
| Доступно в версиях: Enterprise Edition, Performance Edition, Unlimited Edition и Developer Edition. Требуемые дополнительные лицензии определяются типом агента. |
У вас есть полный контроль над действиями, которые могут предпринять ваши агенты, чтобы вы могли настроить работу с клиентами в соответствии с вашими потребностями. Чтобы повысить безопасность и обеспечить функционирование агентов в определенных границах, рекомендуем:
- Назначение агентам, подключающим каналы клиентов, минимальных полномочий пользователя, необходимых для выполнения их работы.
- Встраивание подтверждения подлинности и управления доступом напрямую в поток конфиденциальных действий.
Стандарты допустимости рисков и безопасности каждой компании уникальны, и нет единого способа внедрить проверку подлинности в внедрение агента. Например, в зависимости от политики компании, вы можете разрешить агенту обслуживания Agentforce принимать коды заказов в диалоговом режиме и предоставлять статусы заказов, не требуя официальной проверки подлинности. Однако, если вашему предприятию требуется доставка конфиденциальных или регламентированных материалов, вы можете потребовать от клиентов авторизации перед поиском сведений о заказе от их имени. Прежде чем настраивать агента, ознакомьтесь со стандартами безопасности и допустимости рисков компании. Чтобы предотвратить предоставление агентам общего доступа к данным за пределами заданной области, настройте их с учетом проверки подлинности и авторизации.
Действия и безопасность Agentforce
Когда агент подключен к каналам клиента, действия агента должны быть общедоступными или личными. Хотя Salesforce не имеет конкретного параметра для назначения действий общедоступными или личными, эта инфраструктура помогает вам концептуально разработать и внедрить стандарты безопасности вашей компании.
- Общедоступные действия
- Общедоступные действия — это действия, которые компания может выполнять от имени любого пользователя, независимо от его личности, без проверки подлинности. Например, действие «Ответить на вопросы с Knowledge» обычно считается общедоступным, особенно если оно основано на общедоступной информации, например, политике возврата. Поиск заказа также может быть общедоступным действием, если вам удобно это сделать без надежного подтверждения личности отправителя запроса. В таких случаях сведения, необходимые для идентификации определенного заказа, например, код заказа или адрес эл. почты, можно передать разговорным путем.
- Личные действия
- Личные действия требуют подтверждения подлинности отправителя запроса в соответствии с уровнем комфорта вашей компании, например, посредством проверки подлинности или общего доступа к идентифицирующим данным в сеансе службы сообщений. Обновление личных сведений о встречах, покупки или запрос услуг по контракту на поддержку являются типичными примерами личных действий, и мы не рекомендуем делать их общедоступными. Чтобы агент обслуживания Agentforce выполнил личное действие, пользователь, инициирующий действие, должен быть авторизован для доступа к действию, и его личность должна быть надежно подтверждена.
Рекомендации по безопасному внедрению частных действий
Чтобы повысить безопасность агентов, подключенных к каналам связи с клиентами, рекомендуем требовать от агентов подтверждения личности взаимодействующего с ними лица, прежде чем предпринимать личные действия от его имени.
Для особо конфиденциальных действий рекомендуем подтверждать подлинность посредством таких методов, как двухфакторная проверка подлинности, которая обрабатывает процесс проверки подлинности вне рамок разговора. Общий доступ к идентифицирующим данным в чате не является безопасным методом проверки, но выбранный метод зависит от допустимого риска и стандартов безопасности.
После подтверждения подлинности клиента идентифицирующие сведения могут быть сохранены в связанной записи MessagingSession. Перед выполнением личного действия агент может обратиться к записи MessagingSession для подтверждения личности и полномочий лица, с которым он взаимодействует. Этот процесс можно встроить напрямую в поток личных действий.
При создании агента, который подключается к каналам связи с клиентами и может выполнять личные действия, важно учитывать способы уменьшения риска. Хотя все сценарии использования отличаются, помните о следующих рекомендациях.
Единые стандартные параметры общего доступа определяют доступ пользователей к чужим записям. В сеансе агента с проверенным пользователем сеанс выполняется в контексте конечного пользователя, а OWD зависит от того, является ли пользователь внешним или внутренним. В сеансе агента с непроверенным пользователем сеанс выполняется в контексте пользователя агента и применяется OWD для внутренних пользователей.
Тщательно просмотрите OWD, полномочия пользователя-агента и конфигурацию агента, чтобы обеспечить правильный доступ к записи для конечных пользователей и вашего предприятия.
- Всем агентам, использующим запись пользователя агента, рекомендуем использовать фильтры и переменные для ограничения доступа к записям на уровнях субагента и действия. Эта стратегия защищает конфиденциальные данные, вне зависимости от OWD.
- Вы можете ограничить OWD для внутренних пользователей, чтобы ограничить доступ к записям для всех внутренних пользователей. Потом можно создать правила общего доступа для выборочного предоставления доступа, исключив пользователя-агента Einstein, при необходимости.
Следующие действия
Узнайте, как встроить проверку подлинности пользователя в действия частного агента, включительно со стандартным субагентом проверки подлинности клиента.
- Добавление идентификации пользователя к действиям Agentforce
При настройке агента, подключающегося к каналам связи с клиентами, чтобы он мог безопасно выполнять личные действия, убедитесь, что он подтвердил личность лица, с которым взаимодействует, в соответствии со стандартами вашей компании. - Проверка клиентов с помощью стандартных субагентов в устаревшем конструкторе
Прежде чем агент обслуживания Agentforce совершит личное действие от имени пользователя, Salesforce рекомендует проверить личность лица, с которым взаимодействует агент. Чтобы проверить подлинность непроверенного пользователя в сеансе агента, настройте использование агентом субагента проверки клиента или субагента проверки клиента обслуживания и ограничьте доступ к указанным вами субагентам и действиям. Вы можете требовать разные уровни проверки для разных субагентов и действий, в зависимости от требований безопасности вашего предприятия. - Пример внедрения безопасного агента обслуживания Agentforce
Сведения о внедрении безопасных агентов Agentforce Service определяются местом развертывания агента и связанными политиками проверки подлинности пользователя. Чтобы просмотреть основные схемы, рассмотрим пример.
