ai-agents-for-beginners

သင်ခန်းစာဗီဒီယိုကြည့်ရန်: ရေးမူဇယားထောက်ခံချက်များဖြင့် AI အေးဂျင့်များကို လုံခြုံစေရန်

(သင်ခန်းစာဗီဒီယိုနှင့် thumbnail ကို Microsoft အကြောင်းအရာအသင်းက ပေါင်းစည်းပြီးနောက် ထည့်သွင်းမည်၊ သင်ခန်းစာ 14 / 15 ပုံစံနှင့် ကိုက်ညီစေရန်)

ရေးမူဇယားထောက်ခံချက်များဖြင့် AI အေးဂျင့်များကို လုံခြုံစေရန်

နိဒါန်း

ဤသင်ခန်းစာတွင် ဖော်ပြသွားမည့်အကြောင်းအရာများမှာ-

သင်ယူရန်ရည်မှန်းချက်များ

ဤသင်ခန်းစာပြီးမြောက်စဉ်၊ သင်သည်အောက်ပါအရာများကို သိရှိမည်-

ပြဿနာ- သင့်အေးဂျင့်၏ Audit Trail

Contoso Travel အတွက် AI အေးဂျင့်တစ်ခုကို တပ်ဆင်ထားကြောင်း စဉ်စားကြည့်ပါ။ အဲဒီ အေးဂျင့်သည် ဖောက်သည်တောင်းဆိုချက်များကို ဖတ်ရှု၊ လေယာဉ်ခရီးစဉ် API ကို ခေါ်ယူပြီး ရွေးချယ်မှုများကို ရှာဖွေ၊ ဖောက်သည်အတွက် နေရာထိုင်ခုံများကို ကြိုတင်စာရင်းသွင်းသည်။ မကြာသေးမီလပိုင်းက အဲဒီအေးဂျင့်သည် ၅၀,၀၀၀ ခန့် စီမံခန့်ခွဲခဲ့သည်။

ယနေ့ အထောက်အထား စစ်ဆေးသူတစ်ဦး ရောက်လာသည်။ ၎င်းသည် ရိုးရိုးသောမေးခွန်းတစ်ခုမေးသည်- “သင့်အေးဂျင့် အသုံးပြုမှုများကို ပြကာပေးပါ။”

သင်သည် သင်၏ log ဖိုင်များကို ပေးအပ်သည်။ စစ်ဆေးသူက ၎င်းကို ကြည့်ပြီး ပိုခက်ခဲသောမေးခွန်းကို မေးသည်- “ဤ log များကို တည်းဖြတ်ခြင်းမပြုကြောင်း မည်သို့သိပါသနည်း။”

ဒါက audit-trail ပြဿနာဖြစ်သည်။ ယနေ့အိပ်မက်အများစုသည် အောက်ပါအရာများအား မူတည်သည်-

ဤအရာများသည် စစ်ဆေးသူ၏မေးခွန်းကို ဖြေဆိုခြင်းအတွက် တစ်ဦးချင်း ယုံကြည်မှုလိုအပ်စေသည်။ အတွင်းရေး အတွက် ယုံကြည်မှုသည် လက်ခံနိုင်စရာဖြစ်ပေမည့် စည်းကမ်းတင်းကြပ်သော လုပ်ငန်းခွင်များ (ဘဏ္ဍာရေး၊ ကျန်းမာရေး၊ EU AI သဘောတူညီချက်) အတွက် မဖြစ်နိုင်ပါ။

ရေးမူဇယားထောက်ခံချက်များသည် အေးဂျင့် လှုပ်ရှားချက်တစ်ခုချင်းစီကို လွတ်လပ်စွာ စစ်ဆေးနိုင်စေသည်။ စစ်ဆေးသူသည် သင်အား မယုံကြည်ရပါ။ ၎င်းတို့သည် သင့် သို့မဟုတ်တက်ခဲ့သော public key နှင့် ထောက်ခံချက်ကိုသာလိုအပ်သည်။

ရေးမူဇယားထောက်ခံချက်란 မည်သည်နည်း။

ထောက်ခံချက်သည် အေးဂျင့်သည် မည်သည့် လုပ်ဆောင်မှု ပြုလုပ်သည်ကို မှတ်တမ်းတင်ထားသော JSON objects တစ်ခုဖြစ်ပြီး ဒစ်ဂျစ်တာလက်မှတ်ဖြင့် လက်မှတ်ထိုးထားပါသည်။

flowchart LR
    A[အေဂျင့်က ကိရိယာတစ်ခုကို အသုံးပြုသည်] --> B[လက်ခံသည့် ဒေတာ ဖန်တီးခြင်း]
    B --> C[JSON RFC 8785 ကို canonicalize ပြုလုပ်ခြင်း]
    C --> D[SHA-256 ဟပ်]
    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..."
  }
}

အောက်ပါပစ္စည်း ၃ ခုက လုပ်ဆောင်မှုများထမ်းဆောင်သည်-

  1. လက်မှတ်။ ထောက်ခံချက်ကို agent ရဲ့ gateway မှ Ed25519 ပုဂ္ဂလိက key ဖြင့် လက်မှတ်ထိုးသည်။ ကိုက်ညီသော public key ရှိသူ မည်သူမဆို လက်မှတ်ကို အော့ဖ်လိုင်းတွင် စစ်ဆေးနိုင်သည်။ ခွဲခြမ်း တည်းဖြတ်မှု မည်သည့် နယ်မြေတစ်ခုကိုမဆို လက်မှတ်ကို မမှန်ကန်စေပါ။

  2. Canonical encoding။ လက်မှတ်ထိုးမီ JSON Canonicalization Scheme (JCS, RFC 8785) ကို အသုံးပြု၍ ထောက်ခံချက်ကို စီးရီးလိုင်းချပြီး ဝင်ခွင့်ပေးသည်။ ထိုသည်နှင့် မညီသော Code လုပ် နည်းရှောင်ခြင်းဖြင့် လိုဂျစ်ဖြစ်သော ထောက်ခံချက် နှစ်ခုမှာ တူညီသော ဆိုက်ဘာအထွတ်အထိပ် ဖြစ်ပါလိမ့်မည်။ canonicalization မရှိပါက JSON serializers မတူညီသော လက်မှတ်များ ထုတ်ပေးမည်။

  3. Hash chaining။ previous_receipt_hash နယ်ပယ်သည် ထောက်ခံချက်တစ်ခုချင်းစီအား မှီခိုမှုပေးပါသည်။ ထောက်ခံချက်တစ်ခုဖယ်ရှားခြင်း သို့မဟုတ် ပြန်စီစဉ်ခြင်းက ထိုထောက်ခံချက်အပြီးတွင်ရှိသည့် ထောက်ခံချက်များအားလုံး ပြိုကွက်စေနိုင်သည်။ တစ်ဦးချင်း လက်မှတ်များကို ကျော်လွန်သွားခြင်းကိစ္စ ဖြစ်မဖြစ် သည် chain အဆင့်တွင် ပြသနိုင်ပါသည်။

ဤပစ္စည်းများသည် သုံးမျိုးသော အာမခံချက်များကို ပံ့ပိုးပေးသည်-

Python တွင် ထောက်ခံချက် ထုတ်လုပ်ခြင်း

ထောက်ခံချက်ထုတ်လုပ်ရန် ပုံမှန်စာကြည့်တိုက်၊ စာကြည့်တိုက်မလိုပါ။ ရေးမူဇယားနည်းပညာများသည် အများပြည်သူသိရှိနိင်ပြီး လိုဂျစ်ကို 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 vault တွင်သိမ်းဆည်းပါ)
signing_key = signing.SigningKey.generate()
verify_key = signing_key.verify_key

# လက်ခံရရှိမှု payload ကိုတည်ဆောက်ပါ (လက်မှတ်မရှိသေးပါ)
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,
}

# တိကျစွာသတ်မှတ်ပါ၊ hash လုပ်ပါ၊ လက်မှတ်ထိုးပါ။
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 အောက်ပါအတိုင်း လမ်းဖြင့်ပြသပါသည်-

  1. မှန်ကန်သော ထောက်ခံချက် ထုတ်လုပ်ခြင်းနှင့် စစ်ဆေးမှုအောင်မြင်ခြင်း သိရှိခြင်း
  2. tool_args_hash နယ်ပယ်၏ တစ်ဘိုက်ကို ပြုပြင်ခြင်း
  3. ထပ်မံစစ်ဆေးပြီး မအောင်မြင်ခြင်း ကို တွေ့မြင်ခြင်း

ဤသည်သည် ထောက်ခံချက်များသည် ကိုက်ကြောင်းပြန်လုပ်ခြင်းမရှိကြောင်း၏ လက်တွေ့ထောက်ခံချက်ဖြစ်သည်။ မည်သည့် ပြုပြင်မှုဖြစ်ဖြစ် လက်မှတ် ဖျက်ဆီးသည်။

မျိုးစုံအဆင့်အတန်းအေးဂျင့်များအတွက် ထောက်ခံချက် စည်းဝေးမှု

တစ်ခုသော လက်မှတ်ထိုးထားသော ထောက်ခံချက်သည် လုပ်ဆောင်ချက်တစ်ခုကို ကာကွယ်သည်။ ထောက်ခံချက်များ တွဲဖက်ထားခြင်းသည် အစဉ်လိုက် အဆင့်လိုက် ကာကွယ်ပေးသည်။

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 ) ကို မှတ်တမ်းတင်ထားသည်။ ထောက်ခံချက် 2 ကို မဖြစ်မနေ ဖယ်ရှားချင်ပါက-

ပုဂ္ဂလိက key ကို hardware key vault တွင် သိမ်းဆည်းပြီး နောက်ထောက်ခံချက်တစ်ခုစီမှာ public key ကို ထုတ်ပြန်ထားပါက ၎င်းတိုင်းပြိုင်မှုများ မဖြစ်နိုင်ပါ။

notebook တွင်

  1. သုံးထောက်ခံချက် အခြေအနေတစ်ခု တည်ဆောက်မှု
  2. ထောက်ခံချက် တစ်ခုချင်းစီ၏ previous_receipt_hash သည် ယခင်ထောက်ခံချက်၏ ဟက်နှင့် ကိုက်ညီမှု စစ်ဆေးမှု
  3. အလယ်ပိုင်းထောက်ခံချက်တစ်ခုစတင် ပြင်ဆင်ပြီး စည်းဝေးမှုဘက်တွင် ချိတ်ဆက်မှုပျက်စီးမှု ကြည့်ရှုခြင်း

ဖြင့် လမ်းကြောင်းပြသည်။

ဤနည်းဖြင့် စစ်ဆေးသူများသည် သင့်ကို ယုံကြည်ခြင်းမလိုဘဲ စစ်ဆေးနိုင်သော audit trail ထုတ်လုပ်နိုင်သည်။

ထောက်ခံချက်များ၏ သက်သေပြချက်များ (နှင့် မပြုနိုင်သည့်အရာများ)

ဤအပိုင်းသည် သင်ခန်းစာအတွက် အရေးကြီးဆုံး သတင်းအချက်အလက်ဖြစ်သည်။ ထောက်ခံချက်များသည် ဆွဲဆောင်မှုရှိသော်လည်း ၎င်း၏ အာဏာအကန့်အသတ်ရှိသည်။

ထောက်ခံချက်များသည် သက်သေပြသည်-

  1. မှတ်တိုင်ထားချက်: သတ်မှတ်ထားသော key သည် သတ်မှတ် payload ကို လက်မှတ်ထိုးခဲ့သည်။
  2. တည်ကြည်မှု: payload သည် လက်မှတ်ထိုးခဲ့ချိန်မှ မပြောင်းလဲခဲ့ပါ။
  3. အစဉ်အလာ: ထောက်ခံချက်သည် hash chain အတွင်း ဤအတိုင်းလာခဲ့သည်။

ထောက်ခံချက် မသက်သေပြနိုင်သည့်အရာများ-

  1. တိကျမှန်ကန်မှု: အေးဂျင့်၏ လုပ်ဆောင်ချက်သည် မှန်ကန်သော လုပ်ဆောင်ချက် ဖြစ်ကြောင်း။ မှားယွင်းသော အဖြေတွင်လည်း လက်မှတ်ထိုးနိုင်သည်။
  2. မူဝါဒလိုက်နာမှု: policy_id တွင် မှတ်သားထားသည့် မူဝါဒကို အကဲဖြတ်ခဲ့ခြင်းကို သက်သေပြခြင်း မဟုတ်၊ စစ်စစ်ကောက်မယ်ဆိုလျှင် ခွင့်ပြုမည်ဟု သိရှိခြင်း မဟုတ်ပါ။ ထောက်ခံချက်သည် တောင်းဆိုချက်ကိုမှတ်တမ်းတင်သည်၊ ကိုယ်တိုင် အကောင်အထည်ဖော်မှုမဟုတ်ပါ။
  3. key ပြင်ပ အတည်ပြုမှတ်တမ်း: ထောက်ခံချက်မှာ “ဤ key သည် ဤအကြောင်းအရာကို လက်မှတ်ထိုးသည်” ဟုသာ ပြောသည်။ “ဤလူသည် အတည်ပြုခဲ့သည်” ဟုမဟုတ်ပါ။ key နှင့် လူတစ်ဦး သို့မဟုတ် အဖွဲ့အစည်း ဆက်စပ်ရန် သီးခြား မှတ်ပုံတင်စနစ် လိုအပ်သည်။
  4. အတတ်ပညာအကြောင်းအရာ တိကျမှန်ကန်မှု: အေးဂျင့်သည် ခြောက်လှမ်း ချိုးယွင်းသော prompt လက်ခံပြီး လုပ်ဆောင်သည်ဆိုလျင် ထောက်ခံချက်သည် လုပ်ဆောင်ချက်ကို တိကျစွာမှတ်တမ်းတင်သည်။ ထောက်ခံချက်သည် input အတည်ပြုမှုအစား မဟုတ်ပါ။

ဤအတွင်းနယ်မြေသည် အဓိက အကြောင်းရင်းနှစ်ခုကြောင့် အရေးကြီးသည်-

တစ်ခုသော အထင်သားလွဲမှားမှုမှာ “ကျွန်ုပ်တို့တွင် ထောက်ခံချက်များ ရှိသည်” ဆို ခံယူခြင်းသည် “ကျွန်ုပ်တို့ ထိန်းချုပ်မှုရှိသည်” ဆိုသော အဓိပ္ပါယ်မသည်ဖြစ်သည်။ ထောက်ခံချက်များသည် အခြေခံကျသော အခြေခံပြုမှုဖြစ်ပြီး၊ ထိန်းချုပ်မှုသည် ၎င်းတို့ပေါ်တွင် တည်ဆောက်သည့် စနစ်ဖြစ်သည်။

ထုတ်လုပ်မှုအညွှန်း

ဤသင်ခန်းစာရှိ Python ကုဒ်သည် ရိုးရိုးရှင်းရှင်းဖြစ်ပြီး စာကြောင်းတိုင်းကို ဖတ်၍ အတွေးအခေါ်ရှင်းလင်းစေရန်ဖြစ်သည်။ ထုတ်လုပ်မှုတွင် ရွေးချယ်စရာ နှစ်ခုရှိသည်-

  1. ရေးမူဇယားနည်းပညာများအပေါ် တိုက်ရိုက် တည်ဆောက်ခြင်း။ အပေါ်တွင် မြင်သော ၅၀ စာကြောင်းသည် အများပြည်သူသုံးမှုအတွက် လုံလောက်သည်။ PyNaCl (Ed25519) နှင့် jcs package (canonical JSON) သည် သေချာစောင့်ရှောက် ထိန်းသိမ်းနေသည့် စာကြည့်တိုက်များဖြစ်သည်။

  2. ထုတ်လုပ်မှုနယ်ပယ်ကုဒ် စာကြည့်တိုက် အသုံးပြုခြင်း။ အများအပြား open-source project များသည် ထပ်တူပုံစံကို အပြည့်အဝပါ features (key rotation, batch verification, JWK Set ဖြန့်ဝေမှု, policy engines နှင့် ပေါင်းစပ်မှု) ဖြင့် ချမှုးထုတ်ထားသည်-

    • ဤသင်ခန်းစာတွင် အသုံးပြုသည့် ထောက်ခံချက် ပုံစံသည် IETF Internet-Draft (draft-farley-acta-signed-receipts) အဖြစ် စတင်ခဲ့ပြီး သတ်မှတ်ချက်များဖြစ်နေသည်။
    • Microsoft Agent Governance Toolkit သည် Cedar-based policy ဆုံးဖြတ်ချက်များနှင့် ထောက်ခံချက်စုစည်းထားပြီး အဆုံးအစ ပြည့်စုံသော ဥပမာကို ထို repository အတွင်း Tutorial 33 တွင် မြင်တွေ့နိုင်သည်။
    • protect-mcp (npm) နှင့် @veritasacta/verify (npm) packages များသည် Node များတွင် receipt လက်မှတ်ခြင်းနှင့် အော့ဖ်လိုင်းစစ်ဆေးခြင်းကို ပြုလုပ်ပေးသော library များဖြစ်သည်၊ MCP server များကို tamper-evident audit trail ဖြင့် ထုပ်ပိုးရန် ပါရင် သုံးနိုင်သည်။

ကိုယ်တိုင်ရေးသားခြင်း နှင့် library အသုံးပြုခြင်းတို့၏ ရွေးချယ်မှုသည် ကိုယ်တိုင် JWT library ရေးခြင်း နှင့် စမ်းသပ်ပြီး အသုံးပြုသော JWT library သုံးခြင်းတို့၏ ရွေးချယ်မှုနှင့် တူညီသည်- နှစ်ခုလုံး သင့်တော်သည်။ library သည် အချိန် ကြပ်မတ်ခြင်းနှင့် audit အန္တရာယ် လျှော့ချပေးသည်။ ကိုယ်တိုင်ရေးခြင်းသည် တိုင်ပင်ဆွေးနွေးစရာ အရာတွေကို နားလည်စေသည်။ ဤသင်ခန်းစာသည် ကိုယ်တိုင်ရေးခြင်းမှတဆင့် နည်းလမ်းကို သင်ကြားသည်။

သိမြင်မှု စစ်ဆေးခြင်း

လေ့ကျင့်ခန်းအလုပ်စတင်ရန် မတိုင်မီ နားလည်မှုကို စစ်ဆေးပါ။

1. ထောက်ခံချက်ကို အေးဂျင့်၏ ပုဂ္ဂလိက Ed25519 key ဖြင့် လက်မှတ်ထိုးသည်။ စစ်ဆေးသူသည် public key သာရှိသည်။ စစ်ဆေးသူသည် ထောက်ခံချက်ကို အော့ဖ်လိုင်းတွင် စစ်ဆေးနိုင်မလား?

ဖြေကြားချက် ရှင်းလင်း၊ Ed25519 စစ်ဆေးမှုသည် public key နှင့် လက်မှတ်ထိုးထားသော bytes များသာ လိုအပ်သည်။ အင်တာနက် ခေါ်ဆိုမှု၊ ဝန်ဆောင်မှု ထံမပေးဆောင်ရ၊ တတိယပါတီကို ယုံကြည်ရန်မလိုအပ်ဘဲ စစ်ဆေးနိုင်သည်။ ဤသည်မှာ ရေးမူဇယားထောက်ခံချက်များသည် လေယာဉ်ပိတ်ခဲ့သော (air-gapped)၊ အဖွဲ့အစည်းများစွာ ပါဝင်ရာ သို့မဟုတ် ယုံကြည်မှုနည်းသော audit ပြုလုပ်မှုတွင် အသုံးဝင်စေသော အင်္ဂါရပ်ဖြစ်သည်။

2. တိုက်ခိုက်သူသည်ထောက်ခံချက်၏ policy_id နယ်ပယ်ကို ပိုအာဏာ သတ်မှတ်ထားသည့် မူဝါဒဖြင့် ပြောင်းလဲပြောဆိုလိုသည်။ လက်မှတ်သည် မူလ payload ပေါ်မှာသာ ရေးထိုးထားသည်။ စစ်ဆေးမှုတွင် အဘယ်အရာ ဖြစ်မည်နည်း?

ဖြေကြားချက် စစ်ဆေးမှု မအောင်မြင်ပါ။ လက်မှတ်သည် မူလ payload ၏ canonical bytes ပေါ် တည်ပြီးတွက်ချက်ထားသည်။ နယ်ပယ်တစ်ခုကို ပြင်ဆင်သည်ဆိုလျှင် canonical bytes ပြောင်းလဲသွားပြီး SHA-256 hash ပြောင်းသွား၊ လက်မှတ်မမှန်ဖြစ်သည်။ တိုက်ခိုက်သူသည် အသစ်သော လက်မှတ်မှန်ရရန် ပုဂ္ဂလိက key လိုအပ်ပြီး မရှိပါ။

3. ထောက်ခံချက်တွင် tool_args_hash နှင့် result_hash ကို တိုက်ရိုက် arguments နှင့် result မထားဘဲ ထည့်သည့် အကြောင်းရင်း?

ဖြေကြားချက် ၂ ချက်ရှိသည်။ ပထမ- ထောက်ခံချက်ကို သိမ်းဆည်းသိုလှောင်ခြင်း သို့မဟုတ် ပို့ဆောင်မှု လုပ်ရာတွင် raw အကြောင်းအရာ (PII, စီးပွားရေး ဒေတာ) စွန့်ပစ်ခြင်းနှင့် တက်ကြွမှု ဖြစ်နိုင်သည်။ Hashing သည် ထောက်ခံချက်ကို လူသိငယ်အောင်ထားပြီး၊ စစ်ဆေးသူသည် hash သည် ကွဲပြားတင်ရှိသော အကြောင်းအရာအား ကိုက်ညီကြောင်း သေချာစေသည်။ ဒုတိယ- hash များ၏ အရွယ်အစား သတ်မှတ်ထားပြီး ထောက်ခံချက်သည် ရှေ့နောက် ဝင်ငွေနှင့် ထွက်ငွေ အရွယ်အစား မကြီးလှပါ။

4. previous_receipt_hash နယ်ပယ်သည် ထောက်ခံချက်တစ်ခုချင်းစီကို ယခင်ထောက်ခံချက်နှင့် ချိတ်ဆက်သည်။ တိုက်ခိုက်သူသည် စတင် နှလုံးရေသွားခြင်းမပြုသော ရှေ့အလယ်က ထောက်ခံချက်တစ်ခုကို ဖျက်လိုက်ပါက မည်သည့် အရာ မမှန်မကန်သွားမလဲ?

ဖြေကြားချက် ဖျက်လိုက်သော ထောက်ခံချက်နောက်တွင်ရှိသည့် ထောက်ခံချက်များ အားလုံးပျက်ကွက်သွားသည်။ ၎င်းတို့၏ `previous_receipt_hash` နယ်ပယ်များသည် သက်ဆိုင်ရာ လူ့လမ်းကြောင်းနှင့် မကိုက်ညီသည် (စာရင်းအစေခံ ထောက်ခံချက် မရှိတော့ခြင်း သို့မဟုတ် မတူညီသော ယခင်ထောက်ခံချက်ကို ချိတ်ဆက်ထားခြင်း)။ ဖျက်ခြင်းကို ဖုံးကွယ်ရန် တိုက်ခိုက်သူသည် အခြားထောက်ခံချက်များအားလုံးကိုပြန်လက်မှတ်ထိုးရမည်။ ဤသည်မှာ ပုဂ္ဂလိက key လိုအပ်သည်။

5. ထောက်ခံချက် စစ်ဆေးမှု အောင်မြင်သည်။ ၎င်းသည် အေးဂျင့်၏ လုပ်ဆောင်ချက်မှန်ကန် သလား၊ သဘောတူညီမှု လိုက်နာထားသလား သက်သေပြသနည်း?

ဖြေကြားချက် မဟုတ်ပါ။ လက်မှတ်မှန်ကန်ခြင်းသည် သုံးမျိုးသော အရာများကို သက်သေပြသည်- မှတ်တိုင်ထားချက် (ဤ key သည် ဤအကြောင်းအရာကို လက်မှတ်ထိုးသည်), တည်ကြည်မှု (အကြောင်းအရာမပြောင်းလဲ), သွားလာမှုစဉ် (ထောက်ခံချက်သည် အဲဒီထောက်ခံချက်နောက်က) ဖြစ်သည်။ ၎င်းသည် လုပ်ဆောင်ချက်မှန်ကန်မှု၊ `policy_id` တွင်ဖော်ပြထားသော မူဝါဒ အကဲဖြတ်မှု ဖြစ်ခဲ့ခြင်း သို့မဟုတ် အေးဂျင့်သည် စည်းမျဉ်းအစည်းများအား တိကျစွာ လိုက်နာထားခြင်း မဟုတ်ပဲ ဖြစ်သည်။ ထောက်ခံချက်များသည် အေးဂျင့် လုပ်ရပ်ကို audit ပြုလုပ်နိုင်စေသော်လည်း မှန်ကန်မှုအထောက်အထား မဟုတ်ပါ။ ၎င်းသည် သင်ခန်းစာအတွက် အဓိက အတွင်းနယ်မြေပင် ဖြစ်သည်။

လေ့ကျင့်ခန်း

code_samples/18-signed-receipts.ipynb ကို ဖွင့်ပြီး အောက်ဖော်ပြပါ အပိုင်း ၄ ခုလုံးကို ပြီးစီးပါ-

  1. အပိုင်း ၁: သင့်ပထမဆုံးထောက်ခံချက်ကို လက်မှတ်ထိုး နှင့် စစ်ဆေးပါ။
  2. အပိုင်း ၂: ထောက်ခံချက်ကို ပြင်ဆင်ပြီး စစ်ဆေးမှု မအောင်မြင်ခြင်းကို မှတ်သားပါ။
  3. အပိုင်း ၃: သုံးထောက်ခံချက် စည်းဝေးမှု တည်ဆောက်ပြီး စည်းဝေးမှု တည်ကြည်မှုကို စစ်ဆေးပါ။
  4. အပိုင်း ၄: Microsoft Agent Framework ဖြင့် တည်ဆောက်ထားသော အေးဂျင့်တစ်ခုတွင် ဤနည်းစနစ်ကို သုံးပြီး ကိရိယာခေါ်ဆိုမှုတွင် ထောက်ခံချက် လက်မှတ်ထိုးပြီး ထောက်ခံချက်ကို လွတ်လပ်စွာ စစ်ဆေးပါ။

ရှည်လျားသော စိန်ခေါ်မှု ၁- သင်၏ရိုးရာ ထောက်ခံချက် schema ကို မိမိ စိတ်ကြိုက် အသစ်သော နယ်ပယ်တစ်ခုဖြင့် အဆက်မပြတ် တိုးချဲ့ပါ (ဥပမာ- လမ်းကြောင်း အတိအလင်းဖော်ပြရန် တောင်းဆိုချက် ID)၊ canonical signing logic ဖြင့် ထောက်ခံချက်ကို update ပြုလုပ်ပြီး ထောက်ခံချက်သည် verification မှ အဆင်ပြေစွာ ကျော်ဖြတ်ကြောင်း သေချာစေပါ။ ထို့နောက် လက်မှတ်ထိုးပြီးနောက် နယ်ပယ်ကို ပြင်ဆင်ပြီး verification မအောင်မြင်ဘဲ ကြည့်ပါ။ ၎င်းက canonical encoding ၏ ဘိုက်တစ်ခုချင်းစီသည် လက်မှတ်ထိုးမှုတွင် မည်သို့ ပါဝင်သည်ကို နားလည်စေပါသည်။ Stretch challenge 2: သင့်ရဲ့ လက်ခံမှတ်တမ်း နှစ်ခုကို SHA-256 ဖြင့်ဟက် (အဲဒီလက်ခံမှတ်တမ်းတွေ၏ canonical bytes ကို သေချာသတ်မှတ်ထားတဲ့ အလိုလို အဆက်တွဲပြုလုပ်ခြင်း) ပြီးတဲ့နောက် ဒုတိယလက်ခံမှတ်တမ်းသို့ အသစ်ထည့်သွင်းတဲ့ field အနေနဲ့ ထည့်သွင်းပြီး လက်မှတ်ရေးထိုးပါ။ အဲဒီလက်ခံမှတ်တမ်းသုံးခုအားလုံးကို တစ်ကြိမ်ထဲ ပြန်လည်စစ်ဆေးနိုင်ကြောင်း အတည်ပြုပါ။ သင်သည် တစ်ဆင့် တည်း ပါဝင်မှု အထောက်အထားကို တည်ဆောက်လိုက်ပြီဖြစ်သည်။ တတိယလက်ခံမှတ်တမ်းကို ဖွင့်အသုံးပြုသူမည်သူမဆို ပထမနှစ်ခုရှိနေသည်ဟု အမှန်တရားပြနိုင်ပြီး၊ ၎င်းတို့၏ အကြောင်းအရာများကို ဖေါ်ပြရန် မလိုအပ်ပဲ ဖြစ်သည်။ ၎င်းသည် selective-disclosure လက်ခံမှတ်တမ်းများတွင် များပြားစွာ အသုံးပြုသော နမူနာဖြစ်သည် (Merkle commitments, RFC 6962)။

နိဂုံးချုပ်

ကွန်ပြူတာလက်ခံမှတ်တမ်းများသည် AI စက်တွေကို အောက်ပါအတိုင်း စစ်ဆေးနိုင်တဲ့ လမ်းကြောင်းကို ပေးစွမ်းသည်။

၎င်းတို့သည် input validation၊ policy enforcement သို့မဟုတ် identity infrastructure များအစားထိုးရန် မဟုတ်ပါ။ ၎င်းတို့သည် အဆိုပါအလွှာများအတွက် အခြေခံအရင်းအမြစ် ဖြစ်သည်။ သင်သည် အဆင့်ချုပ်ထားသော အလုပ်တွင် agents များကို မိတ်ဆက်အသုံးပြုနေပါက၊ စည်းကမ်းကျင့်သုံးမှုများ၊ အဖွဲ့အစည်းစုံလင်သော workflow များ သို့မဟုတ် ဘာမှတ်တမ်းများအား အာမခံရမည့် နေရာများတွင် auditing စနစ်မဖြစ်မနေ လိုအပ်သည့်အခါမှာ၊ လက်ခံမှတ်တမ်းများဖြင့် သင်၏ audit trail ကို စစ်မှန်မှန်ကန်စေပါ။

အဓိကအချက်မှာ မည်သူက ဘာစကားပြောခဲ့သည်၊ ဘယ်အချိန်မှာ ဆိုသည်ကို သိရှိစေသည်။ အဲဒါက စကားကို မှန်ကန်မှု သို့မဟုတ် မှန်ကန်မှုကို သက်သေပြခြင်း မဟုတ်ပါ။ ဒီကွာခြားချက်ကို ကာကွယ်ထားပါ။ ၎င်းဟာ တိကျမှန်ကန်သော လမ်းကြောင်းစနစ်နဲ့ အတုအယောင်ဖြစ်ပုံ ကွာခြားချက် ဖြစ်သည်။

ထုတ်လုပ်မှု စစ်ဆေးစာရင်း

သင်သည် ဤသင်ခန်းစာမှ တက်ကြွစွာ မိတ်ဆက်ပြီး လက်မှတ်ရေးထိုးထားသော agent များကို ပေါ်တင် အသုံးပြုရန် ပြင်ဆင်နေသည်ဆိုပါက -

AI Agent များ လုံခြုံရေးကို ပိုမိုမေးမြန်းလိုပါသလား?

တခြား သင်ယူသူများနှင့် တွေ့ဆုံလိုက်ပါ၊ office hours တွင် ပါဝင်တက်ရောက်လိုက်ပါ၊ AI Agents မေးခွန်းများကို ဖြေရှင်းပေးမယ့် Microsoft Foundry Discord တွင် ဝင်ရောက်ပါ။

ဤသင်ခန်းစာအပြင်

ဤသင်ခန်းစာတွင် တစ်ခုတည်းသော လက်ခံမှတ်တမ်းရေးထိုးခြင်းနှင့် ဟက်ချိန်းလိုက်စဉ်များကို ဖော်ပြထားပါသည်။ တူညီသော primitive များကို အသုံးပြု၍ သင်၏ အုပ်ချုပ်မှုစနစ်တိုးတက်လာသည်နှင့်အမျှ တွေ့ကြုံရမည့် နောက်ထပ် Advanced နမူနာများမှာ -

အပိုအရင်းအမြစ်များ

Previous Lesson

Building Computer Use Agents (CUA)

Next Lesson

(To be determined by curriculum maintainers)

ပြောကြားချက် ဤစာတမ်းကို AI ဘာသာပြန်ဝန်ဆောင်မှု Co-op Translator အသုံးပြု၍ ဘာသာပြန်ထားပါသည်။ ကျွန်ုပ်တို့သည် တိကျမှန်ကန်မှုအတွက် ကြိုးပမ်းနေသော်လည်း၊ စက်ကိရိယာဘာသာပြန်ခြင်းများတွင် အမှားများ သို့မဟုတ် မှားယွင်းချက်များ ပါဝင်နိုင်ကြောင်း သတိပြုပါရန် လိုအပ်ပါသည်။ မူလစာတမ်းကို မူရင်းဘာသာဖြင့်သာ ယုံကြည်စိတ်ချရသော အချက်အလက်အဖြစ် သတ်မှတ်သင့်သည်။ အရေးကြီးသည့် သတင်းအချက်အလက်များအတွက် ပရော်ဖက်ရှင်နယ် လူသားဘာသာပြန်သူဝန်ဆောင်မှုကို အကြံပြုပါသည်။ ဤဘာသာပြန်ချက်ကို အသုံးပြုခြင်းမှ ဖြစ်ပေါ်လာသော နားလည်မှုကွာခြားမှုများ သို့မဟုတ် မမှန်ကန်သော အသုံးပြုမှုများအတွက် ကျွန်ုပ်တို့ တာဝန်မခံပါ။

This site is open source. Improve this page.