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

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

Два scope

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

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

Резолвинг по действующему пользователю с fallback на пространство

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

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

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

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

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

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

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

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

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

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

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

Связь с Connections и vault

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

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

Куда дальше

Connections (OAuth2 на пользователя) — как авторизуются персональные доступы.
BYOK и провайдеры LLM — ключи модели на арендатора.
Маркетплейс: обзор и тиры — навыки Tier-2 могут использовать персональные доступы.