AiHummer
Беларуская
Увайсці
v1.0.x
{ }Swagger

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

v1.0.x · абноўлена 2026-06-26

Кожныя ўліковыя даныя, якія трымае AiHummer — API-ключ, токен, сакрэт вебхука — маюць ахоп, які вызначае, з чыім сакрэтам выконваецца выклік інструмента. Існуе два ахопы: агульны і асабісты. Разуменне розніцы і парадку вырашэння паміж імі — гэта ключ да таго, каб даць кожнаму агенту і кожнаму карыстальніку менавіта той доступ, які яны павінны мець, і не больш.

Два ахопы

Ахоп Належыць Выкарыстоўваецца, калі
Агульны Працоўнай прасторы Дзеянне павінна выконвацца пад адным агульным акаўнтам незалежна ад таго, хто яго запусціў
Асабісты Асобнаму карыстальніку Дзеянне павінна быць прыпісана пэўнаму чалавеку і абмежавана яго ўласнай аўтарызацыяй

Абодва віды жывуць у тым жа зашыфраваным сховішчы (envelope encryption, AES-256-GCM, ключ для кожнага арандатара пад майстар-ключом); розніца толькі ў тым, да каго вырашаецца сакрэт, а не ў тым, як ён захоўваецца ці абараняецца.

Вырашэнне па дзеючым карыстальніку з адкатам да працоўнай прасторы

У момант ходу, калі інструменту патрэбны ўліковыя даныя, AiHummer вырашае іх па дзеючым карыстальніку — чалавеку, ад імя якога выконваецца ход — і адкочваецца да ўліковых даных працоўнай прасторы (агульных), калі ў карыстальніка няма асабістых:

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

Гэта адзінае правіла дае вам гнуткія паводзіны: прадастаўце толькі агульныя ўліковыя даныя, і ўсе іх выкарыстоўваюць; дазвольце асобам дадаваць свае, і яны аўтаматычна атрымліваюць перавагу для гэтага чалавека, тады як усе астатнія працягваюць выкарыстоўваць агульныя.

[!NOTE] Асабістыя заўсёды перамагаюць над агульнымі для аднаго карыстальніка. Уліковыя даныя працоўнай прасторы — гэта адкат, а не перавызначэнне — карыстальнік, які падключыў свой уласны акаўнт, дзейнічае са сваёй уласнай аўтарызацыяй.

Калі выкарыстоўваць агульныя

Выбірайце агульныя ўліковыя даныя, калі:

  • Дзеянне прадстаўляе арганізацыю, а не асобу (карпаратыўны паштовы скрыню, адзіны сэрвісны акаўнт CRM, ключ білінгу).
  • Вы хочаце паслядоўныя паводзіны незалежна ад таго, хто запусціў агента.
  • Выдача і ратацыя аднаго сакрэту цэнтралізавана прасцей, чым наладка для кожнага карыстальніка.

Калі выкарыстоўваць асабістыя

Выбірайце асабістыя ўліковыя даныя, калі:

  • Дзеянне павінна быць прыпісана пэўнаму чалавеку і абмежавана тым, што гэтаму чалавеку дазволена рабіць.
  • Розныя карыстальнікі павінны бачыць розныя даныя праз аднаго агента і інструмент.
  • Вам патрэбны адкліканне і аўдыт для кожнага карыстальніка, незалежна ад усіх астатніх.

Асабістыя ўліковыя даныя — гэта звычайна асобныя акаўнты, якія супрацоўнік падключае сам праз Падключэнні. З каробкі яны ўключаюць, напрыклад, 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), якім карыстаюцца ўсе.

Як гэта ўзаемадзейнічае з Падключэннямі і сховішчам

Падключэнні — гэта самы распаўсюджаны спосаб узнікнення асабістых уліковых даных: карыстальнік завяршае OAuth2 authorization-code flow, выдадзены токен запячатваецца ў сховішчы, і з гэтага моманту гэта менавіта тыя асабістыя ўліковыя даныя, якія рашальнік выбірае для гэтага карыстальніка. Агульныя ўліковыя даныя, наадварот, — гэта звычайна сакрэт, які аператар захоўвае аднойчы на ўзроўні працоўнай прасторы.

Ва ўсіх выпадках сакрэт застаецца ў зашыфраваным сховішчы і ніколі не трапляе ў кантэкст мадэлі, промпт ці логі — ахоп толькі кантралюе, да якога запісу ў сховішчы вырашаецца дзеючы карыстальнік.

Куды далей