AI აგენტის prompt injection: ფილტრი ვერ ცვლის ნებართვების შემოწმებას

|ავტორი: QUASA-ს სარედაქციო გუნდი|4 წთ საკითხავი| 2
AI აგენტის prompt injection: ფილტრი ვერ ცვლის ნებართვების შემოწმებას

ხელსაწყოებით მოქმედ AI აგენტს prompt injection-ისგან მხოლოდ ტექსტის ფილტრით ვერ დაიცავთ: მოდელს შეუძლია მოქმედება შემოგთავაზოთ, მაგრამ შესრულების კოდმა ცალკე უნდა შეამოწმოს მომხმარებლის უფლება, ოპერაცია და მისი არგუმენტები. OWASP-ის მითითება პირდაპირ და არაპირდაპირ ჩასმულ მითითებებს განასხვავებს და ნებართვების შემოწმებას მოდელის გარეთ, ხელსაწყოს შესრულებამდე ითხოვს.

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

გამიჯნეთ დავალება და მიღებული შინაარსი

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

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

შეზღუდეთ ხელსაწყოები დავალების ფარგლებით

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

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

გაატარეთ მოთხოვნა დოკუმენტიდან მოქმედებამდე

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

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

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

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

მოდელის გამოსავალი დანიშნულების მიხედვით დაამუშავეთ

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

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

აღრიცხეთ გადაწყვეტილებები და გამოცადეთ საზღვრები

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

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

დანერგვისას საკონტროლო სია ერთი მოთხოვნის გზას მიჰყვება:

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

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

გაზიარება:

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

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

0