AI agent က ဘယ်လောက် permission ရှိသင့်လဲ။ enterprise တွေ အရင်ဆုံး မရင်ဆိုင်ချင်ပေမဲ့ ရှောင်လွှဲမရတဲ့ ခေါင်းစဉ်အသစ်

မန္တလေးက software company တစ်ခုရဲ့ engineer က internal AI assistant ကို order status ကြည့်နိုင်စေဖို့ database read-only permission ကို လွယ်လွယ်နဲ့ ပေးလိုက်တယ်။ အလွန် သင့်တော်တယ်။

နှစ်လ ကြာတော့ product manager က assistant ကို order note update လုပ်ဖို့လည်း ကူညီစေချင်တယ်။ engineer စဉ်းစားပြီး write permission ထည့်ပေးတယ်။ ဒါလည်း သင့်တော်တယ်လို့ ဆိုနိုင်တယ်။

နောက် တစ်လ ကြာတော့ တစ်ယောက်က refund ကို တိုက်ရိုက် ကိုင်စေလို့ ရမလား မေးတယ်။ ဒီအချိန်ကျမှ တစ်ယောက်က မေးဖို့ သတိရလိုက်တယ် - ဒီတော့ အခု ဒီ assistant ရဲ့ account က တကယ်တော့ ဘာ လုပ်နိုင်လဲ။

ဘယ်သူမှ မဖြေနိုင်ဘူး။

ဖြစ်ရပ် နောက်ခံ

ဒီနှစ်တွေ AI မိတ်ဆက်ပုံက အားလုံးနီးပါး တစ်ပုံစံတည်း - chat Q&A (read-only) အရင်လုပ်၊ content generation (system မထိ) ပြီးမှ၊ ပြီးတော့ tool ချိတ်စ (ကြည့်လို့ရ)၊ နောက်ဆုံး လုပ်ဆောင်ချက် စ (ပြင်လို့ရ)။

ရှေ့ သုံးအဆင့်မှာ permission ပြဿနာ မထင်ရှားဘူး။ စတုတ္ထအဆင့်ရောက်တော့ သဘောသဘာဝ လုံးဝ ပြောင်းသွားတယ် - AI agent က ကုမ္ပဏီ system ကို ကိုင်တွယ်တဲ့ "actor" ဖြစ်လာပြီး၊ သူက ဝန်ထမ်းလည်း မဟုတ်၊ ရိုးရာ service account လည်း မဟုတ်။

ရိုးရာ service account မှာ ရှင်းလင်း တည်ငြိမ်တဲ့ behavior pattern ရှိတယ် - နေ့တိုင်း မနက် သုံးနာရီ batch တစ်ခါ run၊ ဘာ လုပ်မလဲ program ထဲ hard-code ထား။ AI agent က မဟုတ်ဘူး။ သူက input အလိုက် ဘယ် tool ခေါ်မလဲ၊ ဘယ် data ပြင်မလဲ ဆုံးဖြတ်ပြီး၊ behavior space က ရေတွက်မရလောက်အောင် ကြီးတယ်။

ဒါက ပြဿနာ ရှိတဲ့ နေရာပါ။ ရှိပြီးသား access governance framework က "behavior ခန့်မှန်းနိုင်တဲ့ program" နဲ့ "psychological cost ရှိတဲ့ လူ" အတွက် ဒီဇိုင်းဆွဲထားတာ။ agent က နှစ်ခုစလုံး မဟုတ်ပါ။

အဓိက အချက်များ

agent ခေတ်ရဲ့ access governance မှာ ကိုင်တွယ်ရမယ့် ဒီဇိုင်း ပြဿနာ လေးခု ရှိတယ်လို့ ကျွန်တော် ထင်တယ် -

• identity independence - agent မှာ ကိုယ်ပိုင် account နဲ့ credential ရှိရမယ်၊ ဝန်ထမ်း identity ငှားမသုံးရ။ ဒါက နောက်ဆက်တွဲ control အားလုံးရဲ့ ကြိုတင်လိုအပ်ချက်။
• least privilege နဲ့ time-bound - task ပြီးဖို့ လိုတဲ့ permission ကိုသာ ပေး၊ ပြီးတော့ ကြာရှည် သက်တမ်းရှိတဲ့ key မဟုတ်ဘဲ time-bound temporary credential ကို တတ်နိုင်သမျှ ပေး။
• segregation of duties ကို non-human account မှာ apply - agent တစ်ခုက အလုပ်တစ်ခုတည်းရဲ့ "create" နဲ့ "approve" permission နှစ်ခုလုံး တစ်ချိန်တည်း မရှိသင့်။ ဒီ rule က agent မှာ လူထက် ပိုတင်းသင့်တယ်။
• complete audit trail - ဘယ်သူ trigger, ဘာ အခြေခံ, ဘာ ပြင်, လူ approve ရှိမရှိ။ စတုတ္ထအချက် အလွယ်ဆုံး ကျန်။

ERP permission နဲ့ segregation of duties ကိုင်တွယ်တဲ့ tool (ဥပမာ Pathlock) က မူလ လူအတွက် ဒီဇိုင်းဆွဲထားပြီး၊ အခု တူညီတဲ့ ပြဿနာ ရင်ဆိုင်နေတယ် - သူတို့ရဲ့ SoD rule base က non-human actor ကို ဘယ်လို ခြုံငုံမလဲ။ ဒါ industry တစ်ခုလုံး စမ်းသပ်နေဆဲ အဆင့်ပါ။

market သက်ရောက်မှု ဆန်းစစ်ချက်

Myanmar သုံးစွဲသူများအတွက် - ရိုးရိုး ဝန်ထမ်း ခံစားရမယ့် ပြောင်းလဲမှုက "agent က မကြာခဏ မလုပ်နိုင်ဘူးလို့ ပြော" တာပါ။ ဒါ function မလုံလောက်သလို ကြားရပေမဲ့၊ အများစုမှာ တမင် design လုပ်ထားတာပါ။

ဒီကိစ္စရဲ့ အကြောင်းရင်းကို ကုမ္ပဏီက ဝန်ထမ်းတွေဆီ ရှင်းရှင်း ပြောဖို့ လိုတယ်လို့ ကျွန်တော် ထင်ပါတယ်။ ဘယ်သူမှ မရှင်းပြရင် ဝန်ထမ်းရဲ့ တုံ့ပြန်မှုက ကျော်လွှားတာ ဖြစ်မယ် - ကိုယ်ပိုင် script ဖွင့်၊ ကိုယ်တိုင် data တစ်ခု ဆွဲထုတ်ပြီး လုပ်။ အဲဒါက တကယ့် security risk ပါ။ permission design က တရားဝင်အလုပ်ကို အလွန်နာကျင်စေရင် လူက သေချာ လမ်းရှာ ကျော်ပါလိမ့်မယ်။

enterprise application အတွက် - Myanmar enterprise မှာ ဒီခေါင်းစဉ်မှာ ချဲ့ကားခံရမယ့် structural အားနည်းချက် နှစ်ခု ရှိတယ်။

ပထမက permission က နှစ်ရှည် ထည့်ရုံသာ ဖျက်လေ့မရှိ။ ကုမ္ပဏီ အများစုရဲ့ permission management က "လိုရင် ထည့်၊ ထွက်မှ ဖျက်" ဖြစ်ပြီး၊ ဆယ်နှစ်ကျော် စုဆောင်းလာတော့ လက်ရှိအခြေအနေ ရှင်းဖို့တောင် project ကြီးတစ်ခုပါ။ ဒီ အခြေခံပေါ်မှာ agent ထပ်ထည့်တာက ပျက်နေတဲ့ foundation ပေါ် အဆောက်အအုံ ဆောက်တာနဲ့ တူတယ်။

ဒုတိယက IT နဲ့ business unit ရဲ့ တာဝန်/အခွင့်အာဏာ ဝိုးဝါးခြင်း။ "ဒီ agent မှာ ဘာ permission ရှိသင့်လဲ" ကို ဘယ်သူ ဆုံးဖြတ်ရမလဲ။ IT က business unit ကိစ္စလို့ ထင်၊ business unit က IT ရဲ့ professional လို့ ထင်။ ရလဒ်က ဘယ်သူမှ မဆုံးဖြတ်၊ အရင် ကြီးကြီးပေးထားလိုက်။

လက်တွေ့ကျတဲ့ နည်းက "agent registry" တစ်ခု သတ်မှတ်ဖို့ - တင်တဲ့ AI agent တိုင်းက အသုံးပြုမှု, ပိုင်တဲ့ permission, တာဝန်ခံ business unit head, နဲ့ review cycle ကို register လုပ်ရမယ်။ ဒီကိစ္စ system ဝယ်စရာ မလို၊ spreadsheet တစ်ခုနဲ့ စနိုင်တယ်၊ ဒါပေမဲ့ သူက အဓိကဆုံး မေးခွန်းကို ဖော်ထုတ်ပေးတယ် - agent တိုင်းမှာ လူ တာဝန်ခံ တစ်ယောက် ရှိရမယ်။

developer အတွက် - hard rule အဖြစ် ထားသင့်တဲ့ design ဥပဒေသ သုံးခု။

ပထမ၊ write permission ကို default ပိတ်ထား။ agent တင်တဲ့အခါ read ကိုသာ ပေး၊ write function က တစ်ခုချင်း လျှောက်၊ တစ်ခုချင်း အကဲဖြတ်။ ဒါ ရိုးရိုး development အကျင့် (test လွယ်ဖို့ အရင် full permission ပေး၊ နောက်မှ ပြန်သိမ်း) နဲ့ ဆန့်ကျင်ပေမဲ့၊ agent ရဲ့ test environment နဲ့ production environment က data မကြာခဏ မျှသုံးလို့ "နောက်မှ ပြန်သိမ်း" က များသောအားဖြင့် မဖြစ်တော့ပါ။

ဒုတိယ၊ destructive action ကို လူ approve မဖြစ်မနေ လို။ delete, refund, external customer ဆီ email ပို့, amount ပြင် - ဒီအမျိုးအစားတွေ "agent အဆင်သင့်လုပ်၊ လူ confirm နှိပ်" အဖြစ် design ရမယ်။ ဒါ AI ကို မယုံလို့ မဟုတ်ဘဲ ဒီကိစ္စတွေရဲ့ error cost က မညီမျှလို့ပါ - confirm တစ်ခါ ပိုနှိပ်တဲ့ cost နည်းပြီး၊ customer ဆီ email မှားပို့တဲ့ cost မြင့်တယ်။

တတိယ၊ "reject" ကိုပါ မှတ်ထား။ system အများစုက အောင်မြင်တဲ့ operation ကိုသာ record လုပ်တယ်။ ဒါပေမဲ့ agent က ဘာ လုပ်ဖို့ ကြိုးစားပြီး permission က တားခံရလဲ ဆိုတာ အလွန်တန်ဖိုးရှိတဲ့ signal ဖြစ်တယ် - prompt injection attack ကို ကိုယ်စားပြုနိုင်သလို၊ သင့် permission design က လက်တွေ့ လိုအပ်ချက်နဲ့ မကိုက်တာကိုလည်း ကိုယ်စားပြုနိုင်တယ်။ နှစ်မျိုးလုံး လူ ကြည့်ဖို့ လိုတယ်။

အနာဂတ် ဖွံ့ဖြိုးမှု လမ်းကြောင်း

ဖြစ်မယ်လို့ ထင်တဲ့ ကိစ္စ သုံးခု။

ပထမ၊ "agent identity" က သီးခြား identity category ဖြစ်လာမယ်။ လက်ရှိ identity management system က "လူ" နဲ့ "service account" နှစ်မျိုး ခွဲထားပြီး၊ agent က ဘယ်တစ်ခုမှ လုံးဝ မပါဘူး။ အနာဂတ် IAM product မှာ purpose declaration, behavior boundary, expiry ပါတဲ့ agent identity type သီးသန့် ပေါ်လာသင့်တယ်။

ဒုတိယ၊ access governance tool တွေ agent ကို SoD analysis ထဲ ထည့်လာမယ်။ ဒါ ရှိပြီးသား vendor အတွက် ရှင်းလင်းတဲ့ product gap ဖြစ်ပြီး startup အတွက် အခွင့်အလမ်းလည်း ဖြစ်တယ်။

တတိယ၊ regulation လိုက်လာမယ်၊ ဒါပေမဲ့ finance နဲ့ healthcare ကနေ အရင်စမယ်။ ဒီနှစ် industry က "ဘယ်သူ့ ဆုံးဖြတ်ချက်" ကို အတင်းကြပ်ဆုံး တောင်းဆိုလို့၊ agent permission design ရှင်းပြခိုင်းခံရမယ့် ပထမ industry အုပ်စု ဖြစ်မယ်။

ပိုသတိထားတဲ့ observation တစ်ခု ထပ်ဖြည့်မယ် - လက်ရှိ market မှာ agent governance ဆွေးနွေးမှုက technical အလွန်ဆန်တယ် - OAuth scope ပြော၊ sandbox ပြော၊ policy engine ပြော။ ဒါပေမဲ့ enterprise တွေကို တကယ်ပိတ်နေတာက ပိုရှေ့က ပြဿနာ - ကုမ္ပဏီထဲမှာ agent ဘယ်နှစ်ခု run နေလဲ ဘယ်သူမှ မသိ။ ဒါ ဆယ်နှစ်က shadow IT နဲ့ တူညီတဲ့ ပြဿနာဖြစ်ပြီး ဖြေရှင်းနည်းလည်း တူ - inventory အရင်လုပ်။

TheAI Academy အနှစ်ချုပ်နဲ့ သုံးသပ်ချက်

အစပိုင်းက မန္တလေး ဥပမာဆီ ပြန်လာမယ်။ သူတို့ နောက်ဆုံး လုပ်တာ အလွန်ရိုးရှင်းတယ် - assistant ရဲ့ account ကို မျှသုံး service account ကနေ dedicated account အဖြစ် ပြောင်း၊ refund function ကို "assistant အဆင်သင့်လုပ်၊ customer service confirm" အဖြစ် ပြင်၊ ပြီးတော့ agent အားလုံးကို မျှသုံး form တစ်ခုမှာ register။

နှစ်ပတ် ကုန်တယ်၊ tool ဘာမှ မဝယ်ဘူး။

သုံးသပ်ချက် - agent permission ကိစ္စက အကောင်းဆုံး အချိန်က သူ မတင်ခင်၊ ဒုတိယ အကောင်းဆုံး အချိန်က အခုပါ။ ကိစ္စတက်မှ design လုပ်ရင် ကိုင်တွယ်ရမှာ technical ပြဿနာတင် မဟုတ်တော့ပါ။

Myanmar စာဖတ်သူများအတွက် တိကျတဲ့ အကြံ၊ နောက်ပတ်ကတည်းက လုပ်နိုင်တဲ့ သုံးခု -

ပထမ၊ agent inventory တစ်ခါ လုပ်ပါ။ ကုမ္ပဏီထဲမှာ အခု AI agent ဘယ်နှစ်ခု run နေလဲ။ ကိုယ်စီ ဘာ account သုံးလဲ။ ဘယ်သူ တာဝန်ခံလဲ။ ဒီ table ကို list ထုတ်ရုံနဲ့ ကုမ္ပဏီ အများစုက ဘယ်သူမှ မမှတ်မိတဲ့ တစ်ခုနှစ်ခု run နေဆဲ တွေ့ပါလိမ့်မယ်။

ဒုတိယ၊ write permission ပြန်သိမ်း၊ ပြန်လျှောက်ခိုင်း။ ဒါ ညည်းညူခံရမယ်၊ ဒါပေမဲ့ တန်ပါတယ်။ ပြန်သိမ်းပြီးရင် တချို့ agent ရဲ့ write permission က ဘယ်တုန်းကမှ မသုံးခဲ့တာ တွေ့မယ် - အဲဒါ သက်သက် risk ဖြစ်ပြီး ကိုက်ညီတဲ့ တန်ဖိုး မရှိပါ။

တတိယ၊ agent တိုင်းရဲ့ လူ တာဝန်ခံ သတ်မှတ်ပါ။ IT မဟုတ်ဘဲ ဒီ agent ကို တကယ်သုံးတဲ့ business unit head ပါ။ ဒီလူက "ဒီ agent ဘာလို့ ဒီ permission လိုလဲ" ဖြေနိုင်ရမယ်။ မဖြေနိုင်တာက ပြန်သိမ်းသင့်တာပါ။

နောက်ထပ်ဖတ်ရန် - AI agent မမိတ်ဆက်ခင် data ဘယ်နှစ် version ရှိလဲ က data ဘက် ပြင်ဆင်မှု ပြော၊ AI စာရင်းစစ်ခန်းထဲ ဝင်လာပြီ က internal control automation ရဲ့ နယ်နိမိတ် ပြော၊ AI agent observability နဲ့ governance က တင်ပြီးနောက် monitoring ပြော။

အချက်အလက် ရင်းမြစ်

• NIST AI Risk Management Framework
• OWASP Top 10 for LLM Applications
• Pathlock တရားဝင် product ရှင်းလင်းချက်

public information အရ စုစည်းထားပြီး official ကို အခြေခံပါတယ်၊ ဒီဆောင်းပါးက general အကြံပြုချက်ဖြစ်ပြီး၊ environment တစ်ခုချင်းရဲ့ control design ကို ကိုယ့် risk assessment အလိုက် ဆောင်ရွက်ပါ။