(သင်ခန်းစာ ဗီဒီယို နှင့် မြင်ကွင်းပုံကို Microsoft အကြောင်းအရာ အဖွဲ့မှ ပေါင်းစည်းပြီးနောက် ထည့်သွင်းမှာဖြစ်ပြီး၊ သင်ခန်းစာ ၁၄ / ၁၅ ဖော်မတ်နှင့် ကိုက်ညီပါသည်။)
ဒီသင်ခန်းစာမှာ ဖော်ပြသွားမှာက:
ဒီသင်ခန်းစာ ပြီးဆုံးလျှင် သင့်မှာ သိရှိပြီး:
Contoso Travel အတွက် AI အက်ဇင့်တစ်ခု စတင်အသုံးပြုထားသည်ဟု သင် စဉ်းစားပါ။ အက်ဇင့်သည် ဖောက်သည်တောင်းဆိုချက်များကို ဖတ်ပြီး၊ ဂျာနယ် API တစ်ခု သို့ ခေါ်ဆိုကာ ရွေးချယ်မှုများကို ရှာဖွေပြီး၊ ဖောက်သည်အစား ထိုင်ခုံများ ကြိုတင်ဘွတ်ကင်းသည်။ ရှစ်လပတ်ကာလကုန်တွင် အက်ဇင့်သည် ၅၀,၀၀၀ ဘွတ်ကင်းများကို လုပ်ဆောင်ခဲ့သည်။
ယနေ့မှာ စစ်ဆေးသူတစ်ယောက် လာရောက်သည်။ သူတို့က မေးတယ် - “သင့်အက်ဇင့် ဘာလုပ်ခဲ့လဲ ပြပါ။”
သင် အောက်ဆုံးမှတ်တမ်းဖိုင်များကို ပေးလက်ခံသည်။ စစ်ဆေးသူက ကြည့်ပြီး ပိုခက်တဲ့မေးခွန်းတစ်ခု မေးတယ် - “ဒီမှတ်တမ်းတွေကို ပြင်ဆင်ထားခြင်း မဟုတ်ကြောင်း ဘယ်လိုသိရမလဲ?”
ဒါဟာ စစ်ဆေးမှတ်တမ်း ပြဿနာ ဖြစ်တယ်။ ယနေ့အတော်များများသော အက်ဇင့်များမှာ အောက်ပါအရာများကို မှီခိုသည်။
အထက်ပါ သုံးမျိုးသည် ရှေ့မေးမြန်းသော စစ်ဆေးသူ၏ မေးခွန်းကို ဖြေရှင်းရန် မဟုတ်ဘဲ ဘယ်သူကိုမှ ယုံကြည်ရန်လိုအပ်သည် (သင်၊ သင့်မှု Cloud ပံ့ပိုးသူ၊ ဒေတာဘေ့စ်ရောင်းခိတ်။) အတွင်းပိုင်းအသုံးပြုရန်။ ယုံကြည်မှုရှိခြင်းသည် လက်ခံနိုင်သည်။ ဥပမာ - ငွေကြေး၊ ကျန်းမာရေးစောင့်ရှောက်မှု၊ EU AI တရားဥပဒေအရ တာဝန်ခံ အလုပ်လုပ်သော အခန်းကဏ္ဍများအတွက် မဖြစ်နိုင်။
ကွယ့်ရီဖိုဂရပ်ဖစ် လက်မှတ်များက အက်ဇင့် လုပ်ဆောင်ချက်တိုင်းကို တစ်ကိုယ်တော် စစ်ဆေးနိုင်စေသည်။ စစ်ဆေးသူသည် သင့်ကို ယုံကြည်ရန် မလိုတော့ပါ။ ဒါပေမယ့် သင့်၏ အများပြကျောက်လုပ်ထားသော Key နှင့် လက်မှတ်တစ်ခုသာ လိုအပ်သည်။
လက်မှတ်သည် အက်ဇင့် ဘာလုပ်ခဲ့သည်ကို မှတ်တမ်းတင်ထားသော JSON အရာဝတ္ထုဖြစ်ပြီး၊ ဒစ်ဂျစ်တယ် လက်မှတ်ဖြင့် လက်မှတ်ထိုးထားသည်။
flowchart LR
A[Agent သည် ကိရိယာတစ်ခုကိုခေါ်သုံးသည်] --> B[လက်ခံစာ payload တည်ဆောက်သည်]
B --> C[JSON RFC 8785 ကို canonicalize လုပ်သည်]
C --> D[SHA-256 hash]
D --> E[Ed25519 နှင့် လက်မှတ်ရေးသည်]
E --> F[လက်မှတ်ပါ လက်ခံစာ]
F --> G[စစ်ဆေးသူသည် အော့ဖ်လိုင်းတွင် စစ်ဆေးသည်]
G --> H{လက်မှတ်သည် တရားဝင်လား?}
H -- yes --> I[အတုမရနိုင်သော အထောက်အထား]
H -- no --> J[လက်ခံစာကို ရှံ့ရှောက်တင်ပြသည်]
စွမ်းဆောင်နိုင်သော လက်မှတ်အစုံက ဒီပုံစံပါသည်။
{
"type": "agent.tool_call.v1",
"agent_id": "contoso-travel-bot",
"tool_name": "lookup_flights",
"tool_args_hash": "sha256:a3f9c1...",
"result_hash": "sha256:7b2e1d...",
"policy_id": "contoso-travel-policy-v3",
"timestamp": "2026-04-25T14:30:00Z",
"sequence": 47,
"previous_receipt_hash": "sha256:9d4e6a...",
"signature": {
"alg": "EdDSA",
"sig": "c5af83...",
"public_key": "8f3b2c..."
}
}
အလုပ်လုပ်စေသော သုံးခုသော ကိုယ်ရည်ကိုယ်သွေးကဏ္ဍများမှာ -
လက်မှတ်။ လက်မှတ်ကို အက်ဇင့်၏ ရှေ့ဆောင် တံခါးပေါက်မှ Ed25519 ကိုယ်ပိုင် Key ဖြင့် လက်မှတ်ထိုးသည်။ ဆက်စပ် အများပြသူ၏ Key ဖြင့် မည်သူမဆို အော့ဖ်လိုင်း စစ်ဆေးနိုင်သည်။ တစ်ခုခုကို ပြင်ဆင်လျှင် လက်မှတ် မမှန်တော့ပါ။
canonical encoding။ လက်မှတ်ထိုးခြင်းမပြုမီ JSON canonicalization scheme (JCS, RFC 8785) ဖြင့် စာရင်းသွင်းသည်။ အကြောင်းအရာ တူညီသည့် သုံးစွဲမူ ကြာခြားမှု မရှိစေရန်ဖြစ်သည်။ Canonicalization မရှိသည့်အခါ JSON စီစဉ်ပုံစံမ်ွ အမျိုးမျိုးဖြစ်နိုင်ပြီး၊ အတူတူအရာအပေါ် လက်မှတ်များကွဲပြားနိုင်သည်။
Hash chaining. previous_receipt_hash ကဏ္ဍသည် လက်မှတ်တစ်ခုစီကို ယခင်လက်မှတ်နှင့် ချိတ်ဆက်ပေးသည်။ လက်မှတ်တစ်ခု ဖြုတ်ခြင်း သို့မဟုတ် အစဉ်အတိုင်း မဟုတ်စွာ ပြောင်းလဲခြင်းမှာ နောက်ထပ်လက်မှတ်တိုင်းကို ဖျက်စီးစေသည်။ တစ်ကိုယ်တော်လက်မှတ်များကို လွှဲပြောင်းနိုင်သော်လည်း ဖောက်ပြန်မှုကို အစဉ်အဆက်အဆင့်မှာ တွေ့ရသည်။
ဒီစပ်စု သုံးခုက အာမခံချက် သုံးခု ပေးသည် -
လက်မှတ်ထုတ်ဖို့ အထူးစာကြည့်တိုက် လိုအပ်ခြင်း မရှိပါ။ ကွယ့်ရီဖိုဂရပ်ဖစ် ပုံစံများတော့ ယေဘူယျလက်လီရလင်း ရရှိနိုင်ပြီး၊ ကုဒ်ပြီးထုတ် ရိုးရှင်းသော Python ဒစ်ဇိုင်းဖြစ်သည်။
code_samples/18-signed-receipts.ipynb မှ တွက်လှိမ့်လုပ်ငန်းများမှာ လုံးလုံးလေးဆင့် လုပ်ငန်းစဉ်များကို ရှင်းလင်းပေးသည်။ ရှင်းလင်းချက် အကျဉ်းချုပ်ကတော့ -
import json
import hashlib
import base64
from nacl import signing
from jcs import canonicalize # RFC 8785 ကန်နိုနီကယ် JSON
def b64url_nopad(data: bytes) -> str:
return base64.urlsafe_b64encode(data).decode("ascii").rstrip("=")
def sha256_canonical(obj) -> str:
"""SHA-256 of a Python object's JCS-canonical JSON form."""
return f"sha256:{hashlib.sha256(canonicalize(obj)).hexdigest()}"
# အမှတ်အသားရေးရန်သော key တစ်ခုကို ဖန်တီးရန် သို့မဟုတ် တင်သွင်းရန် (ထုတ်လုပ်ရေးတွင် key vault မှာ သိမ်းဆည်းပါ)
signing_key = signing.SigningKey.generate()
verify_key = signing_key.verify_key
# ငွေခံရငွေရလဒ် စာစုကို တည်ဆောက်ပါ (အမှတ်အသား မထည့်ထားသေး)
tool_args = {"origin": "SYD", "destination": "LAX"}
tool_result = [{"flight": "QF11", "price": 1850, "stops": 0}]
payload = {
"type": "agent.tool_call.v1",
"agent_id": "contoso-travel-bot",
"tool_name": "lookup_flights",
"tool_args_hash": sha256_canonical(tool_args),
"result_hash": sha256_canonical(tool_result),
"policy_id": "contoso-travel-policy-v3",
"timestamp": "2026-04-25T14:30:00Z",
"sequence": 0,
"previous_receipt_hash": None,
}
# ကန်နိုနီကယ်လုပ်ပြီး၊ ဟက်ခ်ဖတ်ပြီး၊ လက်မှတ်ထိုးပါ။
canonical_bytes = canonicalize(payload)
message_hash = hashlib.sha256(canonical_bytes).digest()
signature_bytes = signing_key.sign(message_hash).signature
# ဖွဲ့စည်းထားသော လက်မှတ်အရာဝတ္ထုကို တင်ပါ။
receipt = {
**payload,
"signature": {
"alg": "EdDSA",
"sig": b64url_nopad(signature_bytes),
"public_key": b64url_nopad(bytes(verify_key)),
},
}
ဒီနည်းလမ်းနဲ့ လက်မှတ်ထိုးခြင်း လုပ်ငန်းစဉ် အကုန်အကျယ်ဖြစ်သည်။ notebook အတွင်း လေ့လာမှုပြုလုပ်ချက်များမှာ အဆင့်ဆင့် လမ်းညွှန်ပေးသည်။
စစ်ဆေးခြင်းသည် လုပ်ငန်းစဉ် တစ်ခုနောက်ပြန်ဖြစ်သည်။
import base64
import hashlib
from nacl import signing
from nacl.exceptions import BadSignatureError
from jcs import canonicalize
def b64url_decode(s: str) -> bytes:
padding = "=" * ((4 - len(s) % 4) % 4)
return base64.urlsafe_b64decode(s + padding)
def verify_receipt(receipt: dict) -> bool:
# လက်မှတ်သည် ဖွဲ့စည်းတည်ဆောက်ထားသော အရာဝတ္တုတစ်ခုဖြစ်သည် - {"alg", "sig", "public_key"}။
sig_obj = receipt.get("signature")
if not sig_obj or sig_obj.get("alg") != "EdDSA":
return False
# သင့်လက်မှတ်ရေးထိုးခဲ့သော payload ကို ပြန်လည်တည်ဆောက်ပါ (လက်မှတ်ကို 제외၍ အားလုံး)။
payload = {k: v for k, v in receipt.items() if k != "signature"}
canonical_bytes = canonicalize(payload)
message_hash = hashlib.sha256(canonical_bytes).digest()
try:
verify_key = signing.VerifyKey(b64url_decode(sig_obj["public_key"]))
verify_key.verify(message_hash, b64url_decode(sig_obj["sig"]))
return True
except BadSignatureError:
return False
ဒီ function သည် လက်မှတ်တစ်ခုကို ယူပြီး လက်မှတ် မှန်ကန်သည့်အခါ True ပြန်ပေး၊ မမှန်ကန်ပါက False ပြန်ပေးသည်။ မည်သည့် အင်တာနက်ခေါ်ဆိုမှု၊ ဝန်ဆောင်မှုမူမရှိ၊ တတိယပုဂ္ဂိုလ် ဘယ်သူ့ကိုမျှ ယုံကြည်မှုပြုရန် မလိုအပ်ပါ။
ဖောက်ပြန်မှု ရှာဖွေခြင်း ကို တွေ့မြင်ရန်၊ notebook ၌ လုပ်ငန်းစဉ်က :
tool_args_hash ကဏ္ဍမှ အဲကွမ်တစ်-byte ပြင်ဆင်ခြင်း။ဒီဟာက လက်မှတ်တွေဟာ ဖောက်ပြန်မှုတွေ ကြည့်ရှု၍ ချိန်ဆသည့် အချက်အလက် ဖြစ်သည်ဟု ကိုယ်တိုင်ပြသခြင်း ဖြစ်သည်။
တစ်ချက် လက်မှတ်တစ်ခု တာဝန်ထမ်းဆောင်၏ လုပ်ဆောင်ချက် တစ်ခုကို ကာကွယ်ပေးသည်။ လက်မှတ်စနစ်ချိတ်ဆက်မှုက လုပ်ဆောင်ချက် စဉ်ဆက်ကို ကာကွယ်ပေးသည်။
flowchart LR
R0[ပေးမြောက်လက်မှတ် 0<br/>အစ] --> R1[ပေးမြောက်လက်မှတ် 1]
R1 --> R2[ပေးမြောက်လက်မှတ် 2]
R2 --> R3[ပေးမြောက်လက်မှတ် 3]
R1 -. previous_receipt_hash .-> R0
R2 -. previous_receipt_hash .-> R1
R3 -. previous_receipt_hash .-> R2
လက်မှတ်တစ်ခုစီတွင် ယခင် လက်မှတ်၏ hash မှတ်တမ်း ပါရှိသည်။ လက်မှတ် ၂ ကို ဖြုတ်ယူရန် တရားမဝင်သူက
previous_receipt_hash ကို ပြင်ဆင်သည်။ (လက်မှတ် ၃ ၏ လက်မှတ်ချောက်ကို ချွတ်စေသည်)ကိုယ်ပိုင်လက်မှတ်သည် hardware key vault ထဲတွင်ရှိကာ၊ လက်မှတ်တိုင်းနှင့်အတူ အများပြဇာတ်လမ်းကို ထုတ်ဝေထားပါက၊ အထက်ဖော်ပြသောတိုက်ခိုက်မှုများ သက်သာသည့်အကောင်အထည် မဖြစ်နိုင်ပါ။
notebook တွင်ဖော်ပြသည်မှာ-
previous_receipt_hash က သေချာ လက်မှတ် ယခင်အမှတ်နှင့် တူညီခြင်းကို အတည်ပြုခြင်းဒီအတိုင်း စစ်ဆေးသူ အပြင်ပိုင်းက ချို့ယွင်းခြင်း မရှိဘဲ စစ်ဆေးနိုင်သော စစ်ဆေးမှတ်တမ်းကို ထုတ်ဖော်နိုင်သည်။
ဒီအပိုင်းဟာ ဒီသင်ခန်းစာရဲ့ အရေးပါဆုံး အပိုင်းဖြစ်သည်။ လက်မှတ်များမှာ အင်အားရှိသော်လည်း အင်အားကန့်သတ်ချက်ရှိသည်။
လက်မှတ်များ သက်သေပြသော အရာသုံးခု
လက်မှတ်များ မသက်သေပြနိုင်သော အရာများ
မှန်ကန်မှု: အက်ဇင့်၏ လုပ်ဆောင်ချက်မှန်ကန်မှု များဟု မသတ်မှတ်နိုင်ပါ။ လက်မှတ်ကို မှားသောဖြေရှင်းချက်နဲ့လည်း လက်မှတ်ထိုးနိုင်သည်။
policy_id မှာဖော်ပြထားတဲ့ မူဝါဒကို တကယ့်မှာ သုံးသပ်ခဲ့တာ ဖြစ်မလား၊ သို့မဟုတ် စစ်ဆေးမယ်ဆိုရင် ဒီလုပ်ဆောင်ချက်ကို ခွင့်ပြုမှာဖြစ်မလား ဆိုတာပါ။ လက်ခံရရှိမှုမှာ တောင်းဆိုထားတာကို မှတ်တမ်းတင်ထားတဲ့အတွက် အတင်းအကျပ်ဖြစ်တာ မဟုတ်ပါ။ဒီနယ်နိမိတ်အရေးကြီးကြောင်းနှစ်ချက်ရှိတယ်။
error တစ်ခုလူသုံးများတာက “ကျွန်တော်တို့မှာ လက်ခံရရှိမှုရှိတယ်” ဆိုတာက “ကျွန်တော်တို့ အုပ်ချုပ်မှုရှိတယ်” ဆိုတာမဟုတ်ဘူး ဆိုတာပါ။ လက်ခံရရှိမှုက အခြေခံသင်္ချာတစ်ခုပဲဖြစ်ပါတယ်။ အုပ်ချုပ်မှုက သင့်ဆောက်လုပ်မယ့် စနစ်ဖြစ်ပါတယ်။
အထက်ပါ အချက် ၃ ကို အပိုင်းခြားရေးဖို့ တန်တဲ့ အကြောင်းအရာတစ်ခုပဲဖြစ်ပါတယ် - လုပ်ဆောင်ချက် လက်ခံရရှိမှုက “ဒီသော့ချက်က ဒီအကြောင်းအရာကို လက်မှတ်ထိုးတယ်” လို့ ပြောတယ်၊ “လူတစ်ယောက်က အတည်ပြုတယ်” မဟုတ်ပါဘူး။ အန္တရာယ်မြင့်လုပ်ဆောင်ချက်တွေ (ပြန်အမ်းငွေ, ဖျက်တောက်ခြင်း, ငွေလွှဲပြောင်းခြင်း) တွေ အတွက် အုပ်ချုပ်မှု တန်းတူသည် အဲ့ဒီမရှိသေးတဲ့ပြောချက်ကို များစွာတောင်းဆိုကြပါတယ်၊ အဲ့ဒါကို ဒီသင်ခန်းစာထဲမှာ သင်သွင်းပြီးသား အစိတ်အပိုင်းတွေနဲ့ ဖန်တီးနိုင်ပါတယ်။
နောက်တစ်ခု notebook code_samples/human-authorization-receipts.ipynb က ၂မုတ်ဆတ်တဲ့ လက်ခံရရှိမှု ဘောင်နည်း human.approval.v1 ဟာ သင်ခန်းစာရဲ့ လက်ခံရရှိမှုတွေနဲ့ တူညီတဲ့ အုံဖွဲ့ ရှိပါတယ် (Ed25519 နဲ့ canonical SHA-256 ပေါ် မူတည်ပြီး စာတိုက် signature ကို signed bytes အပြင်မှာ ထားတာ)။ နာမည်ရှိ အတည်ပြုသူက လုပ်ဆောင်မယ့် လုပ်ငန်းကို အပြည့်အစုံ canonical အနေဖြင့် လက်မှတ်ထိုးပြီး စတင်ဆောင်ရွက်ခေါ်ဆိုသွားမယ်။ အေးဂျင့် လုပ်ဆောင်မှု လက်ခံရရှိမှုမှာ လုပ်ဆောင်မှု digest တူညီပြီး parent_approval_ref ဖြစ်တဲ့ပြန်လည် အတည်ပြုချက်ရဲ့ receipt_hash ပါဝင်ပါတယ်၊ ဒါက previous_receipt_hash ကို သင်က မြင်ခဲ့သလို အထပ်တူ ဖြစ်ပါတယ်။ သုံးတဲ့ စနစ် verify_chain က authority များကို မတူတဲ့ pin ထားတဲ့ သော့ချက် စာရင်းတွေအောက်မှာ လုံခြုံစွာ စစ်ဆေးပါတယ် (အတည်ပြုသူ နှင့် အေးဂျင့် ချိတ်ဆက်ချက်)၊ ဒါကြောင့် ကုဒ်လမ်းကြောင်းမျှတယ်၊ ဒါပေမယ့် အာဏာပိုင်တွေတော့ မမျှတပါ။
ဒီ property ကို ဂရုစိုက်ပြောပြကြောင်း: လူတစ်ယောက်က ဒီတိကျပြီး တိကျတဲ့ လုပ်ဆောင်ချက်ကို အတည်ပြုထားပြီး၊ အေးဂျင့်က ထိုအတည်ပြုချက် အပြည့်အစုံကို လုပ်ဆောင်ထားတာ ဖြစ်ပါတယ်။ Notebook ရဲ့ ငြင်းပယ်ချက်များက ဒီ property ကို တိုက်ရိုက် လက်တွေ့ခွင့်ပြုပါတယ်။
အကြောင်းကြောင့် မတူညီတဲ့ အကြောင်းပြချက်နဲ့ မအောင်မြင်မှု အားလုံး နားချင်းဆိုင်ရာ အသုံးပြုသူက အာဏာလက်ရှိ ဖြစ်နေမဟုတ်ခြင်း ဒါမှမဟုတ် လုပ်ဆောင်ချက် ပြောင်းလဲခဲ့ခြင်းကို ခွဲခြားနိုင်ပါတယ်။ Notebook သင်ပေးတဲ့ rule ကတော့- လက်မှတ်ထိုးထားတဲ့ အတည်ပြုချက်ဟာ ကိုယ်ပိုင်အာဏာ မဟုတ်ပါ။ အာဏာဟာ လုပ်ဆောင်ချက်နှစ်ခုသည် အတည်ပြုသည့် canonical လုပ်ဆောင်ချက် တူညီပြီး ယခု လုပ်ဆောင်ချိန်တွင် ကြပ်မတ်ချိတ်ဆက်ထားရမယ်။ ဒီ pattern ကို ဒီသင်ခန်းစာလိုက်နာတဲ့ Internet-Draft (draft-farley-acta-signed-receipts) မှာ co-signature လမ်းကြောင်း က စံချိန်မတ်ပုံစံ ဖြစ်ပါတယ်။
ဒီသင်ခန်းစာမှာ Python ကုဒ်ကို ရည်ရွယ်ချက် အနည်းငယ်နဲ့ရေးထားတာ သင်ဒါမျှ မြင်မြင်တင်ပြီး နားလည်နိုင်ဖို့ပါ။ ထုတ်လုပ်ရာမှာ ရွေးချယ်စရာ နှစ်ခုရှိပါတယ်-
လုံခြုံရေး အသုံးအဆောင်များ ပေါ်မှာ တိုက်ရိုက် ဆောက်လုပ်ခြင်း။ အထက်မှာ မြင်ရတဲ့ ၅၀ စာသား က အများပြည်သူ အသုံးပြုမှုအတွက် လုံလောက်ပါတယ်။ PyNaCl (Ed25519) နဲ့ jcs package (canonical JSON) တွေက ပြန်လည် ထိန်းသိမ်းထားပြီး စစ်ဆေးထားတဲ့ library တွေဖြစ်ပါတယ်။
ထုတ်လုပ်မှုပြင်ဆင်ချက် အတွက် receipt library အသုံးပြုခြင်း။ အများအပြား ဖွင့်လှစ်-ရင်းမြစ် ပရောဂျက်များက အဲ့ဒီပုံစံကို နောက်ထပ် လုပ်ဆောင်ချက်များ (သော့ချက်လှည့်ပြောင်းခြင်း, batch စစ်ဆေးခြင်း, JWK Set ဖြန့်ဝေမှု, မူဝါဒ စက်မျိုးကွန်ယက်ပေါင်းစည်းခြင်း) နဲ့ ဆောင်ရွက်ထားကြသည်။
draft-farley-acta-signed-receipts, revision 02) ဖြစ်ပြီး သတ်မှတ်ချက် ကိစ္စတစ်ခုပင်ဖြစ်ခြင်း, အစီအစဉ်တစ်ခုဖြစ်တဲ့ (agent-governance-testvectors) ဖြင့် ပိုင်ရှင်များကတစ်ခုချင်း စစ်ဆေးပြုလုပ်နိုင်စေတဲ့ စံထားတပ်ဆင်မှု။protect-mcp (npm) နဲ့ @veritasacta/verify (npm) package များက receipt လက်မှတ်နှင့် offline စစ်ဆေးခြင်း အတွက် Node အခြေပြု အသုံးပြုပုံပေးပြီး MCP ဆာဗာတစ်ခုကို tamper-evident audit trail ဖြင့် ထုပ်ပိုးခြင်း, co-sign flow ဖမ်းဆီးထားခြင်း (desktop flow မှာ WebAuthn ပံ့ပိုးမှု)၊ ဥပမာ တူညီတဲ့ approval-receipt pattern ဟာ human-authorization notebook ကနေ အတူတူ ဖြစ်ပါတယ်။pip install nobulex) က Ed25519 + JCS လက်မှတ်ပုံစံကို Python မှ LangChain နှင့် CrewAI ပေါင်းစပ်မှုတွေနဲ့ ရရှိပါတယ်၊ စမ်းသပ်ရေး vector များနှင့် OWASP PR #2210 မှတစ်ဆင့် ပံ့ပိုးတဲ့ ကုသိုလ်အခြေအနေ သမိုင်းအစီအစဉ်များ ပါဝင်သည်။ကိုယ့်ကိုယ်ကို ဆောက်လုပ်ခြင်း နဲ့ library အသုံးပြုခြင်း တစ်ခုကို ရွေးသင့်တဲ့ ဆုံးဖြတ်ချက်ဟာ ကိုယ့်ရဲ့ JWT library ကို ကိုယ်တိုင်ရေးမယ်၊ စမ်းသပ်ပြီးသား library အသုံးပြုမယ်ဆိုတဲ့ ဆုံးဖြတ်ချက်နှစ်ခုနဲ့ တူညီပါသည်- နှစ်ခုလုံး ဆိုရလို့အသင့်တော်သည်။ library က အချိန်ကုန်သက်သာစေပြီး စစ်ဆေးထားမှု လျော့နည်းစေသည်။ မူရင်းဘောင်ကိုရိုက်ရေးခြင်းက စာရွက်တစ်စောင်အတွင်းရှိ primitive အားလုံးကို နားလည်စေသည်။ ဒီသင်ခန်းစာက မူရင်းဘောင်နဲ့ လမ်းကြောင်း သင်ပြထားတာဖြစ်ပြီး ရွေးချယ်ရာမှာ အခြေခံဖြစ်စေပါသည်။
လေ့ကျင့်ခန်းမလုပ်မီ သင့်နားလည်မှုကို စမ်းသပ်ပါ။
1. လက်ခံရရှိမှုကို agent ရဲ့ ပုဂ္ဂိုလ်ရေး Ed25519 သော့ချက်နဲ့ လက်မှတ်ထိုးထားပါတယ်။ စစ်ဆေးသူမှာ တူညီတဲ့ ပွာလ်စတိတ် သော့ချက်ပဲရှိလို့ပါ။ စစ်ဆေးသူဟာ လက်ခံရရှိမှုကို offline သတိပြုနိုင်မလား?
2. တရားမဝင်သူ တစ်ယောက်က လက်ခံရရှိမှုရဲ့ policy_id field ကို ပြင်ဆင်ပြီး ပို၍ခွင့်ပြုတဲ့ မူဝါဒနဲ့ ဖြစ်တယ်ဆို claim ပြုလုပ်လိုက်တယ်။ လက်မှတ်က ရှေ့ payload ပေါ်မှာပဲပါပဲ။ စစ်ဆေးချိန်မှာ ဘာဖြစ်မလဲ?
၃။ ရရှိခြင်းမှာ tool_args_hash နှင့် result_hash ကို ပါ၀င်စေခြင်းမှာ အကြောင်းရင်း မူရင်း အာဂျူမင့်များနှင့် ရလဒ်ကို မပါဝင်ခြင်း မည်သည့်ကြောင့်လဲ?
၄။ previous_receipt_hash ရှိသောအကွက်သည် ထိုရရှိခြင်းတိုင်းကို အရင်ရရှိခြင်းနှင့် ချိတ်ဆက်ပေးသည်။ တိုက်ခိုက်သူတစ်ဦးသည် လမ်းကြောင်းအလယ်၌ တစ်ခုခု ရရှိခြင်းကို ဆင်ခြေထောက်ခြင်းပြုခါ စက်ရုပ်ကို ဘာများ မစာရင် ဖြစ်နိုင်သနည်း?
၅။ ရရှိခြင်းကို သန့်ရှင်းစွာ စစ်ဆေးတယ်ဆိုတာ အေးဂျင့်လုပ်ဆောင်မှုမှန်ကန်မှု၊ အားသာမှု သို့မဟုတ် မူဝါဒနှင့် ကိုက်ညီမှု ဖြစ်ကြောင်း သက်သေပြပါသလား?
code_samples/18-signed-receipts.ipynb ကို ဖွင့်၍ သုံးသိပ်ပိုင်း ရေးဆွဲပြီး ပြီးဆုံးပါ။
၁။ ပိုင်း ၁: သင့်၏ ပထမဆုံးရရှိခြင်းကို လက်မှတ်ထိုးပြီး စစ်ဆေးပါ။ ၂။ ပိုင်း ၂: ရရှိခြင်းကို ချိုးဖောက်၍ သက်သေပြမှု မအောင်မြင်ခြင်းကို စောင့်ကြည့်ပါ။ ၃။ ပိုင်း ၃: ရရှိခြင်းသုံးခု ဆက်စပ်ပြီး လမ်းကြောင်း တည်ဆောက်ပြီး အစီအစဉ်ကျမှုကို စစ်ဆေးပါ။ ၄။ ပိုင်း ၄: Microsoft Agent Framework ဖြင့် တည်ဆောက်ထားသည့် agent ကို အသုံးပြု၍ ဒီဇိုင်းကို လက်ခလောင်တပ်ပြီး ၎င်းရရှိခြင်းကို လွတ်လပ်စွာ စစ်ဆေးပါ။
ရှည်လျားစိတ်ကူး ချဉ်းကပ်မှု ၁: သင့်ကိုယ်ပိုင် ရွေးချယ်ထားသော အကွက်တစ်ခုဖြင့် ရရှိခြင်း ပုံစံကို တိုးချဲ့ပါ (ဥပမာ၊ အရေးယူမှုအမှတ် တစ်ခုလည်းဖြစ်နိုင်သည်)၊ canonical လက်မှတ်ရေးခြင်း ကိရိယာကို အဲ့လို ထည့်သွင်းပြီး ၊ ရရှိခြင်းကို စစ်ဆေးရာတွင် ပြန်လည်အောင်မြင်ကြောင်း အတည်ပြုပါ။ ထို့နောက် လက်မှတ်ထိုးပြီးနောက် အကွက်ကို ပြောင်းလဲ၍ စစ်ဆေးမှု မအောင်မြင်ကြောင်း အတည်ပြုပါ။ ၎င်းသည် canonical encoding ၏ byte တစ်လုံးချင်းစီသည် လက်မှတ်ထိုးခြင်းကို မည်သည့်အခါ ကူညီပေးသည်ကို နားလည်ရန် အားထုတ်စေသည်။
ရှည်လျားစိတ်ကူး ချဉ်းကပ်မှု ၂: သင့်ရရှိခြင်း နှစ်ခုကို SHA-256 ဖြင့် hash နှိပ်ကပ်ပြီး (၎င်းတို့ရဲ့ canonical bytes များကို နှစ်ဖက်စီတွဲပြီး) စတုတ္ထရရှိခြင်း၏ အကွက်အသစ်တစ်ခုအဖြစ် ထည့်သွင်းပြီး လက်မှတ်ထိုးပါ။ ရရှိခြင်းသုံးခုလုံးသည် ပြန်လည် စစ်ဆေးမှုတွင် အောင်မြင်နေသောကြောင်း အတည်ပြုပါ။ သင်သည် တစ်ဆင့်တည်း အပါအ၀င် အဆိုပြုချက် တည်ဆောက်မှုကို ဖန်တီးလိုက်သည်။ တတိယရရှိခြင်းကို ခေါင်းဆောင်ထားသောသူသည် ပထမနှစ်ခု ရရှိခြင်း များသည် လက်မှတ်ထိုးထားသည့်အချိန်၌ ရှိကြောင်း သက်သေပြနိုင်ပြီး၊ ၎င်းတို့၏ အကြောင်းအရာများကို ဖော်ပြရန် မလိုအပ်ပါ။ ၎င်းသည် selective-disclosure ရရှိခြင်းများတွင် အဆင့်မြင့်စနစ်အဖြစ် အသုံးပြုသည် (Merkle commitments, RFC 6962)။
စာလုံးသိမ်းထားသည့်ရရှိခြင်းများသည် AI အေးဂျင့်များအတွက် audit trail တစ်ခုကို ပေးသည်၊ ၎င်းမှာ:
၎င်းတို့သည် input အတည်ပြုမှု၊ မူဝါဒအကောင်အထည်ဖော်မှု သို့မဟုတ် ကိုယ်ပိုင်အမှတ်တံဆိပ်အဆောက်အအုံ များကို အစားထိုးသည် မဟုတ်ပါ။ ၎င်းများမှာ ထိုအလွှာများအတွက် အခြေခံဖြစ်သည်။ လူကြီးမင်းတို့သည် သတ်မှတ်ထားသောလုပ်ငန်းစဉ်များတွင် AI အေးဂျင့်များအား တပ်ဆင်ပါက၊ အဖွဲ့အစည်းအများစုပါဝင်၍ သို့မဟုတ် အနာဂတ် စစ်ဆေးသူသည် သင့်ကို ယုံကြည်သည့်သူမဟုတ်ဘဲ ဖြစ်နိုင်သော နေရာများ၌၊ ရရှိခြင်းများသည် audit trail ကို တရားဝင်ကြောင်း သိသာစေသည်။
အရေးကြီးဆုံး စကားဝိုင်းမှာ - ရရှိခြင်းသည် မည်သူက ဘာပြောသည်ကို သက်သေပြသည်။ ၎င်းက ပြောကြားသည်ဟု ဆိုသည်မှာ မှန်ကန်သည် သို့မဟုတ် မှန်အောင် ဖြစ်သည်ဟု မသက်သေပြပါ။ ထိုကွာခြားချက်အား ကောင်းစွာ သိရှိထားပါ။ ၎င်းမှာ တရားဝင် မူလအရင်းအမြစ် စနစ်နှင့် မမှန်သော စနစ်ကြား ကွာခြားချက်ဖြစ်သည်။
သင်သည် ဒီသင်ခန်းစာမှ ပညာရယူပြီး အမှန်တကယ် စက်ရုပ်များတွင် ရရှိခြင်း-လက်မှတ်စနစ် အသုံးပြုရန် အဆင့်မြှင့်ရန် ပြင်ဆင်နေပါက -
https://your-org.example.com/.well-known/agent-keys.jsonMicrosoft Foundry Discord တွင် မိတ်ဆွေများနှင့် တွေ့ဆုံ၊ နေ့စဉ်လုပ်ရက် Office hours တက်ပါ၊ AI အေးဂျင့် မေးခွန်းများကို ဖြေကြားပါ။
ဒီသင်ခန်းစာသည် single-receipt signing နှင့် hash-chained sequences ကို ဖော်ပြပေးပြီး၊ governance အဆင့်မြင့်လာပြီးခြင်းအတိုင်း အခြားပုံစံများကို တွေ့ကြုံနိုင်ပါသည်။
authorization_*) နှင့် ပြီးပြီးနောက် (result_*) အပိုင်းလေးခြားပါသည်၊ ကိုယ်ပိုင် လက်မှတ်ဖြင့် ဒုတိယ အချိန်၌ သောက်ရောက်မှု လုပ်ကြံသူများမှ ထုတ်လုပ်သည်။ ၎င်းသည် ဒီသင်ခန်းစာတွင် သင်ကြားသော ရရှိခြင်း ပုံစံပေါ်တွင် ပေါင်းထည့်အသုံးပြုသည်။result_hash တွင် ထည့်သွင်းထားသော bytes များကို သံချပ်သည်။ တကယ့် payload များသည် တစ်ခုတည်းသော ကိရိယာခေါ်ဆိုမှုရလဒ်ထက် များစွာစွာ ပါဝင်နိုင်သည် - ဆုံးဖြတ်မှုမတိုင်မီ တုံ့ပြန်ချက်ရှာဖွေမှု (မော်ဒယ် ခန့်မှန်းချက်၊ ရွေးချယ်မှုများ၊ အထောက်အထား ၊ အန္တရာယ်အခြေအနေ၊ တာဝန်ခံမှု လမ်းကြောင်း၊ မြှောက်တင်မှု ရလဒ်) များကို payload အတွင်း အသီးသီးတွင် သိမ်းထားနိုင်သည်။ ၎င်းသည် ရရှိခြင်း ပုံစံကို အနည်းငယ်ထားပြီး domain အလိုက် payload schema များတိုးတက်နေစေသည်။signature.alg အကွက်တွင် ML-DSA-65 (NIST post-quantum signature standard) ကို ဆောက်လုပ်မှုလိုအပ်စဉ်တွင် ထည့်သွင်းနိုင်သည်။ receipt များကို နှစ်ဖက်လက်မှတ်ရေးရာကာလတစ်ခု သတ်မှတ်ရန် စီစဉ်ပါ။ပြောကြားချက် ဤစာတမ်းကို AI ဘာသာပြန်ဝန်ဆောင်မှု Co-op Translator အသုံးပြု၍ ဘာသာပြန်ထားပါသည်။ ကျွန်ုပ်တို့သည် တိကျမှန်ကန်မှုအတွက် ကြိုးပမ်းနေသော်လည်း၊ စက်ကိရိယာဘာသာပြန်ခြင်းများတွင် အမှားများ သို့မဟုတ် မှားယွင်းချက်များ ပါဝင်နိုင်ကြောင်း သတိပြုပါရန် လိုအပ်ပါသည်။ မူလစာတမ်းကို မူရင်းဘာသာဖြင့်သာ ယုံကြည်စိတ်ချရသော အချက်အလက်အဖြစ် သတ်မှတ်သင့်သည်။ အရေးကြီးသည့် သတင်းအချက်အလက်များအတွက် ပရော်ဖက်ရှင်နယ် လူသားဘာသာပြန်သူဝန်ဆောင်မှုကို အကြံပြုပါသည်။ ဤဘာသာပြန်ချက်ကို အသုံးပြုခြင်းမှ ဖြစ်ပေါ်လာသော နားလည်မှုကွာခြားမှုများ သို့မဟုတ် မမှန်ကန်သော အသုံးပြုမှုများအတွက် ကျွန်ုပ်တို့ တာဝန်မခံပါ။