Агенту нельзя давать права администратора: как настроить Headless 360

Чтобы безопасно настроить Salesforce Headless 360 MCP, сначала активируйте сервер в песочнице, зарегистрируйте для клиента отдельное внешнее приложение и настройте OAuth 2.0 с доказательством владения ключом для обмена кодом — PKCE. Запрашивайте область mcp_api, а refresh_token, offline_access добавляйте только тогда, когда клиенту действительно нужно возобновлять сеанс без повторного входа.

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

Сначала ограничьте полномочия пользователя

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

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

До регистрации клиента составьте список необходимых действий. Условному помощнику, который готовит сводку по сделкам, достаточно чтения согласованных объектов, полей и записей. Управление пользователями, назначение разрешений и изменение конфигурации в такой набор не входят.

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

Зарегистрируйте приложение для конкретного клиента

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

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

1. Скопируйте точный адрес возврата из настроек выбранного клиента. Адрес в запросе авторизации должен совпадать с зарегистрированным значением.
2. Добавьте обязательную область mcp_api. Область обновления токена включайте только для клиента, которому нужен длительный сеанс.
3. Потребуйте PKCE. Если публичный клиент не способен безопасно хранить секрет, не делайте передачу секрета обязательной для получения и обновления токена.
4. Сохраните приложение и передайте клиенту его потребительский ключ. Используемый секрет храните вне репозитория, настроек общего доступа и журналов.
5. Дождитесь применения конфигурации и только после этого диагностируйте отказ авторизации как ошибку клиента.

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

Разделите допуск к приложению и доступ к данным

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

Разрешения на объекты, поля и рабочие операции держите в другом минимальном наборе. Такое разделение позволяет независимо закрыть вход через конкретный клиент, не меняя деловые права пользователя. Оно также соответствует общему принципу ограничения полномочий ИИ-агента.

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

Подключитесь к песочнице и выполните отрицательные тесты

После активации сервера используйте адрес https://api.salesforce.com/platform/mcp/v1/sandbox/platform/headless-360 для песочницы. Для рабочей организации предусмотрен адрес https://api.salesforce.com/platform/mcp/v1/platform/headless-360. В клиенте укажите потребительский ключ зарегистрированного приложения и запустите интерактивную авторизацию.

Начните с чтения подготовленных тестовых данных. Проверяйте не только доступность объекта, но и состав возвращаемых полей и записей: успешный ответ ещё не доказывает, что границы доступа настроены правильно.

1. Выполните разрешённый запрос и зафиксируйте ожидаемый результат без чувствительных данных.
2. Запросите объект или поле, закрытые для тестового пользователя. Закрытые сведения не должны появиться в ответе.
3. Попробуйте административное действие, не входящее в согласованный сценарий, например назначение набора разрешений тестовой учётной записи.
4. Если запрещённая операция прошла, остановите внедрение и повторно проверьте все источники полномочий пользователя.
5. Тестируйте запись только на специально подготовленных данных и с явным подтверждением в клиенте.

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

Свяжите журналы с отзывом токена

Журнал клиента должен позволять сопоставить событие с пользователем, приложением и операцией. Рекомендуемый минимум — время, внутренний идентификатор запроса, название операции, результат и код ошибки. Не записывайте токены, секреты и открытые чувствительные значения полей; содержимое запросов маскируйте по принятой политике обработки данных.

Средства управления использованием OAuth позволяют просматривать подключения внешних клиентских приложений и отзывать доступ на уровне токена, пользователя или приложения.

1. Авторизуйте тестового пользователя и выполните разрешённую операцию.
2. Откройте сведения об использовании внешних клиентских приложений и найдите нужную регистрацию и пользователя.
3. Отзовите тестовый токен, затем повторите запрос из прежнего сеанса. Старый токен не должен дать доступ; клиент может запросить новую авторизацию.
4. Проверьте аварийный сценарий: отзовите доступ приложения, снимите с пользователя набор допуска и попробуйте подключиться снова.
5. Сопоставьте отказ с журналом клиента и аудитом организации, не раскрывая секреты в записях.

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

Читайте также:

• ИИ-агенту нельзя давать все права: как ограничить возможный ущерб
• Gemini 3.5 Flash Cyber нельзя просто подключить по API — вот кому он доступен
• Доступ к каналу в Дзене без пароля: редактору не нужны права администратора