Персональные и общие доступы — AiHummer Документация

У каждого доступа, который хранит AiHummer — API-ключа, токена, секрета вебхука — есть область доступа (в API — scope), определяющая, под чьим секретом выполняется вызов инструмента. Область доступа бывает двух видов: общая (shared) и персональная (personal). Понимание разницы между ними и порядка выбора — ключ к тому, чтобы дать каждому агенту и каждому пользователю ровно тот доступ, который им положен, и не больше.

Две области доступа

Область доступа	Принадлежит	Когда использовать
Общая (shared)	Рабочему пространству	Действие должно выполняться под одной общей учётной записью независимо от того, кто его инициировал
Персональная (personal)	Конкретному пользователю	Действие должно быть привязано к авторизации конкретного человека и ограничено ею

Оба вида живут в одном зашифрованном хранилище секретов (конвертное шифрование, AES-256-GCM, ключ на арендатора под мастер-ключом); разница лишь в том, для кого выбирается секрет, а не в том, как он хранится и защищён.

Выбор по действующему пользователю с резервным общим доступом

Во время обработки запроса, когда инструменту нужен доступ, AiHummer выбирает его по действующему пользователю — тому, от чьего имени обрабатывается запрос, — и использует общий доступ рабочего пространства, если персональный отсутствует:

нужен доступ ─▶ есть персональный доступ у действующего пользователя?
                 ├─ да  ─▶ использовать персональный доступ
                 └─ нет ─▶ использовать общий доступ (рабочего пространства)

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

[!NOTE] Персональный доступ имеет приоритет над общим для одного и того же пользователя. Доступ пространства — это резервный вариант, а не замена: пользователь, подключивший свою учётную запись, действует со своей авторизацией.

Когда использовать общий

Выбирайте общий доступ, когда:

Действие представляет организацию, а не отдельного человека (корпоративный почтовый ящик, единая служебная учётная запись CRM, биллинговый ключ).
Нужно одинаковое поведение независимо от того, кто инициировал агента.
Выпускать и ротировать один секрет централизованно проще, чем настраивать его на каждого пользователя.

Когда использовать персональный

Выбирайте персональный доступ, когда:

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

Персональные доступы — это, как правило, личные учётные записи, которые сотрудник подключает сам через подключения. «Из коробки» к ним относятся, например, Gmail, Google Calendar, Google Contacts, Google Drive, Google Tasks, YouTube, Outlook Mail, Outlook Calendar, OneDrive, Microsoft To Do, Todoist, Asana, Jira Cloud, ClickUp, GitLab, Linear, monday.com, Fitbit, Oura Ring, Strava, Spotify и Samsung SmartThings — каждый пользователь действует под своей авторизацией. Общий же доступ — это одна учётная запись рабочего пространства (например, корпоративный почтовый ящик или служебная учётная запись CRM), которой пользуются все.

Пример: два сотрудника и один общий доступ к CRM

В рабочем пространстве настроен общий доступ к CRM — служебная учётная запись, под которой агент может искать клиентов и создавать сделки.

Анна подключила через подключения свой личный Google Calendar и ничего больше. Когда Анна просит агента «поставь встречу с клиентом», календарное действие идёт под её авторизацией (персональный доступ), а поиск клиента в CRM — под общей служебной учётной записью (персонального доступа к CRM у Анны нет — используется резервный общий).
Борис ничего не подключал. Все его действия — и календарь, если общий доступ к нему настроен, и CRM — идут под общими доступами рабочего пространства.

Итог: одна и та же связка «агент + инструменты» ведёт себя по-разному для двух сотрудников, при этом правило одно — персональный доступ имеет приоритет, общий используется как резервный.

Как настроить на практике

Коротко, «для человека»:

Один доступ на всех (общий). Оператор один раз сохраняет секрет на уровне рабочего пространства — на экране Секреты или как общее подключение. Так все агенты и пользователи действуют под одной учётной записью (например, корпоративная почта).
Свой доступ у каждого (персональный). Пользователь сам подключает свою учётную запись через подключения (проходит вход OAuth) — и с этого момента его собственные вызовы идут под его авторизацией, а у остальных остаётся общий доступ.
Кто может писать агенту настраивается не здесь, а на экране Каналы: переключатель «Отвечать только известным пользователям».
Свой профиль/поведение для конкретного человека достигается сочетанием персональных подключений (этот раздел) и настроек агента; общие правила компании выносите в общие блоки.

Ничего дополнительно «включать» не нужно: правило выбора (персональный → иначе общий) работает автоматически.

Связь с подключениями и хранилищем секретов

Подключения — самый частый способ появления персонального доступа: пользователь проходит поток OAuth2 authorization-code, выданный токен запечатывается в хранилище секретов, и с этого момента это и есть тот самый персональный доступ, который выбирается для этого пользователя. Общий же доступ — это обычно секрет, который оператор сохраняет один раз на уровне рабочего пространства.

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

Куда дальше

Подключения пользователей через OAuth 2.0 — как авторизуются персональные доступы.
BYOK и провайдеры LLM — ключи модели на арендатора.
Маркетплейс: обзор и уровни — навыки уровня 2 могут использовать персональные доступы.