Асабістыя супраць сумесных уліковых дадзеных

need credential ─▶ personal credential for the acting user?
                     ├─ yes ─▶ use the personal credential
                     └─ no  ─▶ fall back to the shared (workspace) credential

Кожныя ўліковыя даныя AiHummer — ключ API, токен, сакрэт вэбхука — маюць **сфера** што вызначае, з чыймі сакрэтамі працуе выклік інструмента. Ёсць два абсягі: **сумесны** і **асабісты**Разуменне розніцы і парадку вырашэння паміж імі з'яўляецца ключом да таго, каб кожная агенцыя і кожны карыстальнік атрымлівалі менавіта той доступ, які ім сапраўды патрэбны, і нічога болей. ## Дзве сферы | Сфера | Належыць | Выкарыстоўваецца, калі | |---|---|---| | **Сумесны** | Рабочае месца | Дзеянне павінна выконвацца пад адным агульным уліковым запісам, незалежна ад таго, хто яго актываваў. | | **Асабісты** | Адзін карыстальнік | Дзеянне павінна прыпісвацца канкрэтнай асобе і быць абмежавана яе ўласным дазволам | Абодва тыпы живуць у тым жа зашыфраваным сховішчы (шыфраванне канверта, AES-256-GCM, асобны ключ для кожнага арандатара пад галоўным ключом); розніца толькі ў тым, *каму* адпавядае сакрэт, а не ў тым, як ён захоўваецца або абараняецца. ## Рашэнне выконваючага карыстальніка з магчымасцю вяртання на працоўную прастору У момант павароту, калі інструмент патрабуе ўліковых дадзеных, AiHummer гэта вырашае **ад імя карыстальніка, які выконвае дзеянне** — асоба, ад імя якой адбываецца чэргаванне — і вяртаецца назад да **рабочае прастора** (сумесны) рэквізіт, калі ў карыстальніка няма асабістага: ```text need credential ─▶ personal credential for the acting user? ├─ yes ─▶ use the personal credential └─ no ─▶ fall back to the shared (workspace) credential ``` Гэтае адзінае правіла забяспечвае гнуткую паводзіны: прапануйце толькі агульную аўтэнтыфікацыю, і ўсе будуць яе выкарыстоўваць; дазвольце асобам дадаваць свае ўласныя, і яны аўтаматычна будуць мець перавагу для гэтага чалавека, у той час як усе астатнія працягваюць выкарыстоўваць агульную. > [!NOTE] > Асабістае заўсёды перамагае агульнае для таго ж карыстальніка. Рэкамендацыі працоўнага прасторы > запасны варыянт, а не перапісванне — карыстальнік, які падключыў уласны рахунак, дзейнічае > з уласнага дазволу. ## Калі выкарыстоўваць shared Выберыце а **сумесны** пасведчанне калі: - Дзеянне прадстаўляе арганізацыю, а не асобу (карпаратыўны паштовы скрыню) адзін уліковы запіс сэрвісу CRM, ключ білінгу - Вы хочаце стабільнай паводзінаў незалежна ад таго, хто выклікаў агента. - Выпуск і цэнтралізаванае абнаўленне аднаго сакрэту прасцей, чым наладка для кожнага карыстальніка. ## Калі выкарыстоўваць асабістае Выберыце а **асабісты** пасведчанне калі: - Дзеянне павінна быць прыпісана канкрэтнаму чалавеку і абмежавана тым, што гэты чалавеку дазволена рабіць - Розныя карыстальнікі павінны бачыць розныя дадзеныя праз аднаго і таго ж агента і інструмент. - Вам патрэбнае адаменне і аўдыт для кожнага карыстальніка асобна, незалежна ад усіх іншых. Асабістыя ўліковыя дадзеныя звычайна ўяўляюць сабой асобныя ўліковыя запісы, праз якія супрацоўнік падключаецца самастойна. [Злучэнні](/be/v1.0/access/connections-oauth2)Па змоўчанні гэта ўключае, напрыклад, 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), якую выкарыстоўваюць усе. ## Настройка на практыцы Простымі словамі: - **Адзін аўтэнтыфікацыйны дакумент для ўсіх (агульны).** Аператар захоўвае сакрэт адзін раз на ўзровень працоўнага прастору — на [Сакрэты](/be/v1.0/webui/marketplace#secrets-vault) экран ці як агульнае злучэнне. Тады ўсе агенты і карыстальнікі дзейнічаюць пад адным уліковым запісам (напрыклад, карпаратыўная паштовая скрыня - **Адзін дакумент на чалавека (асабісты).** Карыстальнік падключае ўласны рахунак праз [Злучэнні](/be/v1.0/access/connections-oauth2) (завяршае ўваход праз OAuth) — і з таго часу іх уласныя званкі праходзяць пад іх аўтарызацыяй, у той час як усе іншы захоўвае агульны. - **Хто можа пісаць агенту** прысвечана не тут, а на [Каналы](/be/v1.0/webui/channels#access-control-reply-only-to-known-users) экран: пераключальнік «Адказваць толькі вядомым карыстальнікам» - **Асабістая персаналія/паводзіны для канкрэтнай асобы** паходзіць ад камбінавання асабістыя сувязі (гэтая старонка) з наладамі агента; увядзіце агульнакампанійскія правілы [сумесныя блокі](/be/v1.0/webui/skills-prompts). Нішто дадатковае для «ўключэння»: правіла вырашэння (асабісты → альбо агульны) працуе аўтаматычна. ## Як гэта ўзаемадзейнічае з Падключэннямі і сховішчам [Злучэнні](/be/v1.0/access/connections-oauth2) з'яўляюцца самым распаўсюджаным спосабам **асабісты** Крэдытнае сведчанне ўзнікае наступным чынам: карыстальнік завяршае працэс аўтарызацыі па кодзе OAuth2, выдадзены токен зашчапляецца ў сховішчы, і з гэтага моманту гэта дакладна асабістае крэдытнае сведчанне, якое рашальнік выбірае для гэтага карыстальніка. У адрозненне ад гэтага, агульнае крэдытнае сведчанне звычайна з'яўляецца сакрэтам, які аператар захоўвае адзін раз на ўзроўні працоўнай прасторы. У ўсіх выпадках сакрэт захоўваецца ў зашыфраваным сховішчы і ніколі не трапляе ў кантэкст мадэлі, падказку або журнал — абсяг толькі кантралюе, да якой запісы сховішча звяртаецца карыстальнік, які дзейнічае. ## Куды далей - [Злучэнні (OAuth2 для кожнага карыстальніка)](/be/v1.0/access/connections-oauth2) — як Асабістыя дакументы аўтарызаваны. - [Пастаўшчыкі BYOK і LLM](/be/v1.0/access/byok-providers) — ключы па мадэлі на кожнага арандатара. - [Агляд рынку і ўзроўні](/be/v1.0/marketplace/overview-tiers) — Узровень 2 Навыкі могуць выкарыстоўваць асабістыя рэквізіты.