AiHummer
ქართული
შესვლაპირადი კაბინეტი
v1.1.x
{ }Swagger

პირადი და საერთო სერთიფიკატები

v1.1.x · განახლდა 2026-07-05

ყველა AiHummer პირადობის მოწმობა — API-კლინი, ტოკენი, ვებჰუქის სეკრეტი — აქვს რეგიონი რომელიც განსაზღვრავს, ვისი საიდუმლოს გამოყენებით ხდება ინსტრუმენტის გამოძახება. არსებობს ორი სფერო: საერთო და პირადიმათ შორის სხვაობისა და გადაჭრის წესის გაგება არის გასაღები, რათა ყოველ სააგენტოს და თითოეულ მომხმარებელს მიეწოდოს ზუსტად ის წვდომა, რაც მათ სჭირდებათ, და არაფერი მეტი.

ორი წერტილოვანი სავიზირო

რეგიონი ეკუთვნის გამოიყენება, როდესაც
საერთო სამუშაო სივრცე ქმედება უნდა შესრულდეს ერთობლივი ანგარიში მიუხედავად იმისა, ვინ გამოიწვია იგი
პირადი გაყოფილი მომხმარებელი მოქმედება უნდა მიეწეროს კონკრეტულ პიროვნებას და შეზღუდული იყოს მისი საკუთარ სანქციით

ორივე ტიპი ცხოვრობს ერთ კოდირებულ საცავში (ჩანთის დაშიფრვა, 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] პირადი მონაცემები ყოველთვის პრიორიტეტულია ერთიდაიგივე მომხმარებლის საერთო მონაცემებთან მიმართებაში. სამუშაო სივრცის ანგარიშის მონაცემები — «რეზერვული ვარიანტი», არა ჩანაცვლება — მომხმარებელი, რომელმაც თავისი პირადი ანგარიში შეაერთა, მოქმედებს მისი საკუთარი ნებართვით.

როდის გამოვიყენოთ shared

აირჩიეთ ერთი საერთო ანგარიშის მონაცემები, როდესაც:

  • მოქმედება წარმოადგენს ორგანიზაციას, არა ცალკეულ პიროვნებას (კომპანიის საფოსტო ყუთი, ერთი 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 — hər მომხმარებელი მოქმედებს თავისი საკუთარი ავტორიზაციით. კოლექტიური ანგარიში, პირიქით, არის ერთი ანგარიში მთელი სამუშაო სივრცისათვის (მაგალითად, ერთი კორპორატიული ელფოსტის ყუთი ან CRM სერვისის ანგარიში, რომელსაც ყველა იყენებს.

ეს პრაქტიკაში დაყენება

მარტივად ვთქვათ:

  • ერთი კრედენციალი ყველასთვის (გაზიარებული). ოპერატორი საიდუმლოს ერთჯერადად ინახავს სამუშაო სივრცის დონე —-ზე საიდუმლოებები ეკრანი ან როგორც საერთო კავშირი. მაშინ ყველა აგენტი და მომხმარებელი მოქმედებს ერთი ანგარიშის ქვეშ (მაგალითად, a კომპანიის საფოსტო ყუთი).
  • თითოეულ ადამიანს მხოლოდ ერთი ანგარიში (პირადი) შეუძლია ჰქონდეს. მომხმარებელი დაკავშირებს თავის პირად ანგარიშს საშუალებით კავშირები (ასრულებს შესვლას OAuth-ის საშუალებით) — და იმ დროიდან მათი საკუთარი ზარები აღინიშნება მათი ავტორიზაციის ქვეშ, მაშინ როდესაც ყველა დანარჩენი გარდა ამისა, ინახავს საერთო.
  • ვის შეუძლია მიიღოს ეჯენტის წერილი ადგება არა აქ, არამედ არხები ეკრანი: გადამრთველი «პასუხის გაცემა მხოლოდ ცნობილ მომხმარლებზე».
  • პირადი პიროვნება/განცხადება კონკრეტული პირისთვის გამოდის გაერთიანებიდან პირადი კავშირები (ამ გვერდზე) აგენტის პარამეტრებით; შეიტანეთ საერთო კორპორატიული წესები საერთო ბლოკები.

დამატებითი არაფრის ჩართვა საჭირო არაა: დაშვების წესი (პირადი → სხვაგვარად საერთო) ავტომატურად მუშაობს.

როგორ ურთიერთქმედებს ეს კონექშენებთან და საცავთან

კავშირები არის ყველაზე გავრცელებული გზა პირადი მომხმარებლის მონაცემები შექმნილია: მომხმარებელი ასრულებს ავტორიზაციის პროცესს OAuth2 კოდით, გაცემული ტოკენი შეინახება შენახვაში, და ამ მომენტიდან ეს არის ზუსტად პირადი მომხმარებლის მონაცემები, რომელიც რეზოლვერი არჩევს ამ მომხმარებლისთვის. A ერთობლივად გამოყენებადი ანგარიში, პირიქით, ჩვეულებრივ არის სერიოზული სართი, რომელსაც ოპერატორი ინახავს ერთხელ სამუშაო სივრცის დონეზე.

ყველა შემთხვევაში საიდუმლო რჩება დაშიფრულ საცავში და არასოდეს ხვდება მოდელის კონტექსტში, დახმარების ტექსტში ან ჟურნალებში — მართვის სფერო განსაზღვრავს მხოლოდ მეთხოვა რომელ ჩანაწერზე მიუბრუნდეს მოქმედი მომხმარებელი.

სად შემდეგ?