AI აგენტებს საკუთარი იდენტობა ექნებათ — 12 კომპანია წესებზე შეთანხმდა

|ავტორი: QUASA-ს სარედაქციო გუნდი|4 წთ საკითხავი| 1
AI აგენტებს საკუთარი იდენტობა ექნებათ — 12 კომპანია წესებზე შეთანხმდა

Okta-მ 2026 წლის 22 სექტემბრის ოფიციალურ განცხადებაში ლას-ვეგასიდან Blueprint Alliance-ის შექმნა და AI აგენტების უსაფრთხოების ღია, მრავალმომწოდებლიანი საცნობარო არქიტექტურის გამოქვეყნება გამოაცხადა; 12 დამფუძნებელია AWS, CrowdStrike, Databricks, Docker, Google Cloud, Lovable, Okta, Proofpoint, Salesforce, ServiceNow, Wiz და Zscaler, ხოლო GE Appliances და World Central Kitchen კოალიციაში სტრატეგიული მრჩევლები არიან. შეთანხმება საერთო პრინციპებსა და არქიტექტურას ეხება, რომლის მიხედვითაც თითოეულ აგენტს საკუთარი შემოწმებადი იდენტობა უნდა მიენიჭოს.

Virtualization Review-ის მიმოხილვა ალიანსის მოდელს ოთხ საკითხად აღწერს: აგენტის აღმოჩენა, მისი უფლებები, მუშაობისას ქცევა და საფრთხეზე რეაგირება. საჯაროდ წარმოდგენილი შედეგი საცნობარო არქიტექტურაა; მისი გამოცხადებისას კონკრეტული მრავალმომწოდებლიანი ინტეგრაციები და მათი მუშაობის შედეგები გამოქვეყნებული არ ყოფილა. საწარმოს შეუძლია ჩარჩოს გაცნობა, მაგრამ სხვადასხვა მწარმოებლის პროდუქტებს შორის უსაფრთხოების კონტროლის შეთანხმებული მუშაობა ჯერ გამოსაქვეყნებელი ტესტებით უნდა შეფასდეს.

რატომ სჭირდება აგენტს ცალკე იდენტობა

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

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

აღმოჩენა და უფლებები: არქიტექტურის პირველი ორი კითხვა

აღმოჩენა გულისხმობს შიდა გუნდების მიერ შექმნილი, SaaS სერვისებიდან შემოსული და დაუმტკიცებლად გაშვებული აგენტების მოძებნას. შემდეგ მოდის მათი კატალოგში აღრიცხვა, მდგომარეობის შემოწმება და პასუხისმგებელი მხარის მითითება. ეს ნაბიჯი უფლებების მართვის წინაპირობაა: უცნობ აგენტს ვერც განსაზღვრულ პოლიტიკას მიაბამ და ვერც მისი გაუქმების შედეგს დაინახავ. საცნობარო არქიტექტურა აგენტების უსაფრთხოების მდგომარეობის მუდმივ შეფასებასაც ითვალისწინებს, რათა არასწორი კონფიგურაცია ან დაუცველი კომპონენტი მხოლოდ ინციდენტის შემდეგ არ გამოჩნდეს.

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

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

მიმდინარე ქცევა და ზუსტი რეაგირება

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

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

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

რა დაადასტურებს მრავალმომწოდებლიან თავსებადობას

ალიანსი MCP-ის, OCSF-ის, SSF-ისა და CAEP-ის გამოყენებით სისტემებს შორის სიგნალების გაცვლასა და ერთობლივი საცნობარო ინტეგრაციების გამოქვეყნებას გეგმავს. ეს სახელები სხვადასხვა ნაწილისთვის არის მნიშვნელოვანი: MCP აგენტისა და ინსტრუმენტის კავშირს ეხება, OCSF უსაფრთხოების მონაცემების საერთო ფორმას, SSF და CAEP კი მოვლენებისა და წვდომის ცვლილების სიგნალების გადაცემას. თითოეულის მხარდაჭერა პროდუქტში ჯერ არ ნიშნავს, რომ აღმოჩენა, უფლებამოსილება, დაკვირვება და შეჩერება სხვადასხვა მწარმოებლის სისტემებში უწყვეტ ჯაჭვად მუშაობს.

CrowdStrike-ის ბიზნესის დირექტორმა დენიელ ბერნარდმა თქვა „No single technology or vendor can secure the agentic era alone“, ხოლო კომპანიის წარმომადგენელმა Security Point Break-ს განუმარტა, რომ Okta-სთან მოქმედი ორმხრივი ინტეგრაცია ალიანსამდე არსებობდა და სპეციალურად Blueprint-ისთვის ახალი კავშირი მათ ჯერ არ აუგიათ. ეს განსხვავება მნიშვნელოვანია: არსებული ორი პროდუქტის კავშირი გამოსადეგი საწყისია, მაგრამ ვერ აჩვენებს, როგორ იმუშავებს ახლად შეთანხმებული წესები მონაწილეთა უფრო ფართო კომბინაციაში.

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

ასევე წაიკითხეთ:

გაზიარება:

გამოიწერეთ ჩვენი ბიულეტენი

მიიღეთ უახლესი ამბები Web3-ის, AI-სა და კრიპტოს შესახებ პირდაპირ თქვენს ელფოსტაზე.

0