
ԱԲ գործակալը գործիքներ է ստանում․ ինչպես սահմանափակել վնասի շառավիղը

ԱԲ գործակալին գործիքների անվտանգ հասանելիություն տալու համար յուրաքանչյուր առաջադրանքի համար սահմանեք, թե նա ինչ կարող է կարդալ, փոխել կամ ուղարկել։ Այդ սահմանները կիրառեք գործիքի իրավունքներում, յուրաքանչյուր կանչի պարտադիր ստուգման մեջ և կատարման միջավայրում։ Հետևանք ունեցող գործողությունը թող սպասի մարդու հաստատմանը, որպեսզի մոլորեցնող մուտքից ծնված որոշումը անմիջապես չվերածվի արտաքին փոփոխության։
Տեղակայման հերթականությունն է՝ քարտեզագրել գործողություններն ու տվյալները, նեղացնել թույլտվությունները, կանչերից առաջ կիրառել ստուգումներ, առանձնացնել հաստատում պահանջող քայլերը, մեկուսացնել ֆայլային ու ցանցային հասանելիությունը և գրանցել ամբողջ ընթացքը։ Յուրաքանչյուր սահման փորձարկեք նաև վնասակար բովանդակությամբ. սովորական առաջադրանքի հաջող կատարումը դեռ չի ցույց տալիս, թե ինչ կլինի, երբ գործակալը սխալ հրահանգի հետևի։
Քարտեզագրեք գործողությունները և վստահության սահմանները
Նախ գրանցեք գործակալի բոլոր գործիքները և դրանցով հնարավոր գործողությունները՝ կարդալ, ստեղծել, փոխել, ուղարկել կամ ջնջել։ Յուրաքանչյուրի կողքին նշեք տվյալների տիրույթը, արտաքին համակարգը և այն անձին, որի անունից գործակալը գործում է։ Առանձին նշեք նամակից, կայքից, պահոցից կամ գործիքի պատասխանից եկող բովանդակությունը. այն կարող է անհրաժեշտ լինել առաջադրանքին, բայց ինքնուրույն իրավունք չի տալիս փոխելու օգտատիրոջ նպատակը։
Anthropic-ի՝ NIST-ին ներկայացրած վերլուծությունը գործակալի անվտանգությունը դիտարկում է մոդելի, գործիքների, դրանց աշխատանքը կառավարող շերտի և կատարման միջավայրի մակարդակներում։ Թույլտվությունների քարտեզում այդ տարբերությունը գործնական նշանակություն ունի. մոդելին տրված հրահանգը նկարագրում է ցանկալի վարքը, գործիքի իրավունքը որոշում է հնարավոր գործողությունը, իսկ միջավայրը սահմանում է հասանելի ռեսուրսների արտաքին եզրը։ Ստուգման ժամանակ փորձեք նույն արգելված գործողությունը խնդրել և՛ անմիջական հարցմամբ, և՛ գործակալին փոխանցված արտաքին տեքստի միջոցով։
Տվեք նվազագույն գործիքներ և նեղ իրավունքներ
Ընդհանուր, լայն իրավունքներով միացումը բաժանեք առաջադրանքին համապատասխան գործիքների։ Պայմանական օրինակով՝ նամակներն ամփոփող գործակալին սկզբում պետք է միայն անհրաժեշտ փոստարկղի ընթերցման իրավունք։ Նամակ ուղարկելը, հասցեատերերի ամբողջ ցանկը կարդալը կամ հաղորդագրություններ ջնջելը առանձին հնարավորություններ են, որոնք չպետք է բխեն ընթերցման իրավունքից։ Նույն բաժանումը կիրառեք ֆայլերի ուղիների, տվյալների բազայի աղյուսակների և արտաքին ծառայությունների նկատմամբ։
Սահմանափակեք նաև թույլատրված գործիքի ներսի ընտրությունը՝ հասցեատերերը, ֆայլերի ուղիները, հարցման ծավալն ու տվյալների շրջանակը։ Եթե համակարգը թույլ է տալիս, օգտագործեք առաջադրանքին կապված կարճատև հավատարմագրեր և գործակալին մի փոխանցեք հիմնական ծառայության մշտական գաղտնիքները։ Մնացորդային ռիսկը թույլատրված սահմանների ներսում է. ընթերցման իրավունք ունեցող գործակալը դեռ կարող է սխալ ամփոփել գաղտնի նամակը կամ այն փոխանցել մեկ այլ թույլատրված գործիքով։ Փորձարկման համար տվեք սահմաններից դուրս հասցեատեր, ուղի և տվյալների խումբ ու համոզվեք, որ մերժումը կիրառվում է նաև արտաքին ծառայության իրավասությունների մակարդակում։
Ստուգեք յուրաքանչյուր կանչը մինչև կատարումը
Գործիքի մուտքային ստուգումը պետք է համեմատի կանչի անունն ու փաստարկները օգտատիրոջ թույլտվության և ընթացիկ առաջադրանքի սահմանների հետ։ Այն պետք է կանգնեցնի չթույլատրված ուղին, նոր հասցեատիրոջը կամ չափազանց լայն հարցումը՝ մինչև գործիքը որևէ փոփոխություն անի։ Ելքային ստուգումը կարող է սահմանափակել գործիքի պատասխանի հետագա օգտագործումը կամ հեռացնել զգայուն տվյալները, սակայն դրանով արդեն ուղարկված նամակը կամ ջնջված գրառումը հետ չի բերվի։
OpenAI Agents SDK-ի փաստաթղթավորումը տարբերակում է գործակալի սկզբնական մուտքի ու վերջնական ելքի ստուգումները յուրաքանչյուր պաշտպանված function tool-ի կանչին կցվող ստուգումներից։ Զուգահեռ մուտքային ստուգման ընթացքում գործակալը կարող է արդեն token ծախսել կամ գործիք կանչել. blocking ռեժիմում ստուգումն ավարտվում է գործարկումից առաջ։ Նույն փաստաթղթավորումից երևում է նաև կիրառման սահմանը. այդ tool guardrail շղթան չի ընդգրկում hosted և ներկառուցված կատարման բոլոր գործիքները։ Ուստի բարձր հետևանքով կանչի համար ստուգումը տեղադրեք նաև ծառայության թույլտվությունների կամ միջավայրի սահմանում և փորձարկեք, որ մերժված կանչից հետո արտաքին համակարգում փոփոխություն չկա։
Հետևանք ունեցող գործողությունը կապեք մարդու որոշմանը
Հաստատում պահանջեք գործողության պահին և ներկայացրեք հաստատողին վերջնական փաստարկները՝ ինչ է արվելու, որ տվյալների նկատմամբ և ում հասցեով։ Պայմանական նամակի դեպքում մարդը պետք է տեսնի իրական հասցեատիրոջը և ուղարկվող բովանդակության իմաստը, ոչ միայն «ուղարկել նամակ» ընդհանուր պահանջը։ Հաստատումը կապեք հենց այդ կանչին. եթե հասցեատերը կամ գործողության ծավալը փոխվի, նախորդ համաձայնությունը այլևս բավարար չէ։
Anthropic-ի գործակալների վստահելիության քննարկումը բացատրում է, որ ավելի բաց միջավայրն ավելացնում է prompt injection-ի մուտքերը, իսկ ավելի շատ գործիքները՝ հնարավոր հետևանքները։ Այն նաև նկարագրում է գործողությունների թույլտվությունն ու մարդու վերահսկողությունը, թեև բազմաթիվ անորոշ հաստատման հարցումները կարող են սովորական ձևականություն դառնալ։ Հաստատումը պահեք հատկապես դժվար հետ շրջվող քայլերի համար՝ ուղարկում, զանգվածային փոփոխություն կամ ջնջում։ Փորձարկման մեջ գործակալին տվեք արտաքին տեքստ, որը հորդորում է փոխել հասցեատիրոջը. հաստատման փուլում պետք է երևա վերջնական հասցեատերը, իսկ մերժումը պետք է դադարեցնի կանչը։
Մեկուսացրեք ֆայլերը, գաղտնիքները և ելքային ցանցը
Գործակալին տվեք առանձին կատարման միջավայր՝ միայն անհրաժեշտ ֆայլերով և գրելու համար նախատեսված սահմանափակ տարածքով։ Եթե նա կարող է կոդ գործարկել, նույն սահմանները պետք է գործեն նաև այդ կոդի համար. այլապես գործընթացը կարող է հասնել տվյալին մի ճանապարհով, որը գործիքի կանչի ստուգումը չէր տեսնում։ Հավատարմագրերը պահեք միջավայրից և գործակալի տեսանելի բովանդակությունից հնարավորինս առանձնացված, իսկ առաջադրանքների միջև մաքրեք ժամանակավոր վիճակը։
Ելքային ցանցային կապը թույլատրեք միայն անհրաժեշտ ուղղություններով։ Թույլատրված հասցեների ցանկը նեղացնում է տվյալների դուրսբերման ուղիները, սակայն թույլատրված հասցեով արտահոսքի ռիսկը մնում է և պահանջում է տվյալների շրջանակի առանձին սահմանափակում։ Փորձարկեք չթույլատրված տիրույթին միանալը և մեկուսացված տարածքից դուրս ֆայլ կարդալը. երկուսն էլ պետք է մերժվեն անկախ նրանից, թե գործակալը ինչպես է նկարագրում իր գործողությունը։ Վերագործարկումից հետո ստուգեք նաև, որ նախորդ առաջադրանքի տվյալներն ու հավատարմագրերը հաջորդին հասանելի չեն։
Պահպանեք գործողությունների պատմությունը և փորձարկեք ամբողջ շղթան
Աուդիտի մատյանում գրանցեք առաջադրանքի նույնացուցիչը, օգտատիրոջ թույլտվության հիմքը, կանչված գործիքը, փաստարկների անհրաժեշտ մասը, ստուգման արդյունքը, մարդու որոշումը և արտաքին ծառայության պատասխանի կարգավիճակը։ Գրանցեք նաև մերժված փորձերը. առանց դրանց դժվար է հասկանալ՝ գործակալը ինչ է փորձել անել և որ սահմանն է աշխատել։ Մատյանի հասանելիությունն ու պահպանման ժամկետը սահմանեք առանձին, որպեսզի դիտարկելիությունը չվերածվի գաղտնի տվյալների ավելորդ պատճենման։
Ամբողջ շղթայի համար օգտագործեք պայմանական փորձ՝ գործակալը կարդում է թույլատրված նամակ, որի ներսում հրահանգ կա գաղտնի տվյալն այլ հասցեով ուղարկելու։ Հետևեք, թե որ շերտն է կանգնեցնում ուղարկումը, արդյոք հաստատում պահանջող քայլը սպասում է մարդու որոշմանը, և արդյոք մեկուսացված միջավայրն արգելում է շրջանցող ցանցային կապը։ Մատյանը պետք է ցույց տա փորձերի ու մերժումների հերթականությունը՝ առանց գաղտնի բովանդակությունն ամբողջությամբ կրկնօրինակելու։ Այդ փորձը կրկնեք, երբ փոխվում են գործիքները, նրանց իրավունքները կամ միջավայրի ցանցային կանոնները. յուրաքանչյուր նոր հասանելիություն փոխում է նաև հնարավոր վնասի սահմանը։
Առնչվող հոդվածներ


RAG թե fine-tuning․ փաստերի համար վերապատրաստումը հաճախ սխալ ընտրություն է

LangGraph թե CrewAI․ գրաֆային վերահսկո՞ւմ, թե դերային թիմ

Leonardo AI թե Midjourney․ երբ «ստուդիան» հաղթում է «տեսախցիկին»

n8n թե Zapier․ պարզությունը վճարովի է, վերահսկողությունը՝ աշխատատար

Claude Code թե Codex․ մեկ հաղթող չկա՝ առաջադրանքն է որոշում
Բաժանորդագրվեք մեր տեղեկագրին
Ստացեք Web3-ի, ԱԲ-ի և կրիպտոյի վերջին լուրերն անմիջապես ձեր էլ. փոստին։