ai-agents-for-beginners

သင်ခန်းစာဗီဒီယိုကြည့်ပါ: Cryptographic Receipts ဖြင့် AI Agents များကို လုံခြုံရေးထားခြင်း

(သင်ခန်းစာဗီဒီယိုနှင့်သင်ခန်းစာ ၁၄ / ၁၅ ပုံစံနှင့် ကိုက်ညီသော Microsoft အကြောင်းအရာအဖွဲ့မှ ပြင်ဆင်ပြီး ပေါင်းစပ်သည်နှင့်ရောတင်ပါမည်။)

Cryptographic Receipts ဖြင့် AI Agents များကို လုံခြုံရေးထားခြင်း

အဖွင့်အခန်း

ဒီသင်ခန်းစာမှာ ဖုံးလွှမ်းမှာမှာပါဝင်တာတွေက:

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

ဒီသင်ခန်းစာပြီးဆုံးတဲ့နောက် သင်မှာသိရှိမယ့်အရာတွေက:

ပြဿနာ: သင့် agent ၏ audit trail

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

ဒီနေ့ auditor တစ်ယောက် ရောက်ရှိလာသည်။ သူက ရိုးရှင်းသောမေးခွန်းတစ်ခုမေးသည်။ “သင့် agent ဘာလုပ်ခဲ့သလဲ ပြပါ။”

သင် log ဖိုင်များကို ပေးလွှတ်သည်။ Auditor သည် log များကို ကြည့်ပြီး ခက်ခဲသော မေးခွန်းတစ်ခုမေးသည်။ “ဒီ log များ ဘာသာပြန်မှား ါခြင်းမရှိကြောင်း ဘယ်လိုသိရမလဲ?”

၎င်းသည် audit-trail ပြဿနာဖြစ်သည်။ နေရာအများစု၌ agent တပ်ဆင်မှုများသည် အောက်ပါအရာများအပေါ် မှီငြမ်းသည်။

ဤအရာများထဲမှ မည်သည်မျှ auditor ၏မေးခွန်းကို အဖြေရှာမည်ဆိုလျှင် auditor သည် တစ်စုံတစ်ယောက် သို့မဟုတ် သင့်, cloud provider သို့မဟုတ် database vendor ကို ယုံကြည်ရမည်။ အတွင်းပိုင်းအသုံးပြုမှုအတွက် ယုံကြည်မှုသည် လက်ခံနိုင်သည်။ စည်းကမ်းထားသည့်လုပ်ငန်း (ဘဏ္ဍာရေး၊ ကျန်းမာရေးစောင့်ရှောက်ရေး၊ EU AI Act နှင့် တည်း) များအတွက် မဟုတ်ပါ။

Cryptographic receipts များသည် agent လုပ်ဆောင်မှုတိုင်းကို လွတ်လပ်စွာ စစ်ဆေးနိုင်ရန် ကူညီသည်။ Auditor သည် သင့်ကို ယုံကြည်ရန် မလိုအပ်ဘဲ public key နှင့် receipt ကိုသာ လိုအပ်သည်။

Cryptographic Receipt ဆိုတာဘာလဲ?

Receipt သည် agent က ဘာလုပ်ခဲ့သည်ကိုမှတ်တမ်းတင်ထားသော JSON object ဖြစ်ပြီး digital signature ဖြင့် အမှတ်ထိုးထားသည်။

flowchart LR
    A[အေးဂျင့်သည် ကိရိယာတစ်ခုကို ခေါ်ယူသည်] --> B[လက်ခံမှု အချက်အလက် ဖန်တီးသည်]
    B --> C[JSON RFC 8785 ကို Canonicalize ပြုလုပ်သည်]
    C --> E[Canonical bytes များကို Ed25519 ဖြင့် လက်မှတ်ထိုးသည်]
    E --> F[လက်မှတ်ပါ လက်ခံမှု]
    F --> G[စစ်ဆေးသူသည် အော့ဖ်လိုင်းမှ စစ်ဆေးသည်]
    G --> H{လက်မှတ်တရားဝင်သနည်း?}
    H -- yes --> I[ပြုပြင်ရန်မဖြစ်နိုင်သော အထောက်အထား]
    H -- no --> J[လက်ခံမှု ငြင်းပယ်ခံရသည်]

အနိမ့်ဆုံး receipt တစ်ခုက ဒီလိုဖြစ်သည်။

{
  "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..."
  }
}

အင်္ဂါရပ်သုံးခုသည် အလုပ်လုပ်သည်။

၁။ Signature ။ Receipt ကို agent ၏ gateway မှ Ed25519 personal key ဖြင့် အမှတ်ထိုးသည်။ ဒါ့နောက် public key ကို သိသူ မည်သူမဆို signature ကို offline စစ်နိုင်သည်။ အကယ်၍ ဘယ် field မဆို ပြင်ဆင်လျှင် signature မှားယွင်းသွားသည်။

၂။ Canonical encoding ။ အမှတ်ထိုးခြင်းမပြုမီ Receipt ကို JSON Canonicalization Scheme (JCS, RFC 8785) ဖြင့် စီစစ်ထားသည်။ ဒါက တူညီသော logical receipt ကို အခြား JSON serializer များက Byte level တွင် တူညီသည့် output ပေးပါသည်။ Canonicalization မရှိရင် JSON serializer မတူညီချင်း signature မတူသောပုံကို ထုတ်ပေးနိုင်သည်။

၃။ Hash chaining ။ previous_receipt_hash field သည် receipt တစ်ခုစီကို ယခင် receipt နှင့် ချိတ်ဆက်ထားသည်။ Receipt တစ်ခုကို ဖယ်ရှားခြင်း သို့မဟုတ် စီစဉ်မှုပြောင်းလဲခြင်းသည် အတိုင်းအဆင့်နောက်တစ်ခုတို့အား သက်ရောက်စေသည်။ Signature ကို ကျော်လွှားနိုင်ပေမယ့် Tampering ကို ချိုင်တန်းအဆင့်တွင် တွေ့ရှိနိုင်သည်။

အတူတကွ ဒီအင်္ဂါရပ်များက သုံးခုသော အာမခံချက်များ ပေးသည်။

Python မှာ Receipt ထုတ်လုပ်ခြင်း

Receipt ထုတ်လုပ်ရန် အထူးစာကြည့်တိုက် မလိုအပ်ပါ။ Cryptographic primitives များရရှိနိုင်ပြီး Logic မှာ 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 ကို ဖန်တီးခြင်း သို့မဟုတ် ဖိုင်ထဲမှ Load လုပ်ခြင်း (ကုန်ပစ္စည်း ထုတ်လုပ်ရာတွင် 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,
}

# JCS bytes ကို canonicalize ပြီး တိုက်ရိုက် လက်မှတ်ရေးပါ။ PureEdDSA သည် ပြင်ပတွင် hash မလုပ်ပါ။
canonical_bytes = canonicalize(payload)
signature_bytes = signing_key.sign(canonical_bytes).signature

# ဖွဲ့စည်းထားသော လက်မှတ် object ကို ပေါင်းထည့်ပါ။
receipt = {
    **payload,
    "signature": {
        "alg": "EdDSA",
        "sig": b64url_nopad(signature_bytes),
        "public_key": b64url_nopad(bytes(verify_key)),
    },
}

အဲဒါက အမှတ်အသားထိုးခြင်း လုပ်ငန်းစဉ် အားလုံး ဖြစ်သည်။ Notebook ၏ အက်ဆိုင်ဇ်များက လုပ်ငန်းစဉ်တိုင်းကို လမ်းညွှန်သည်။

Receipt ကိုစစ်ဆေးခြင်းနှင့် Tampering ရှာဖွေရေး

စစ်ဆေးခြင်းသည် လုပ်ဆောင်မှုပြန်လည် လုပ်ဆောင်ခြင်းဖြစ်သည်။

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 ကို ပြန်လည်တည်ဆောက်ပါ (signature ကို 제외၍ အားလုံး)။
    payload = {k: v for k, v in receipt.items() if k != "signature"}

    canonical_bytes = canonicalize(payload)

    try:
        verify_key = signing.VerifyKey(b64url_decode(sig_obj["public_key"]))
        verify_key.verify(canonical_bytes, b64url_decode(sig_obj["sig"]))
        return True
    except BadSignatureError:
        return False

ဒီ function က receipt တစ်ခုကို လက်ခံပြီး signature မှန်ကန်ရင် True ကို မမှန်ကန်ရင် False ထုတ်ပေးသည်။ Network call မလို၊ service မလို၊ တတိယပုဂ္ဂိုလ်အပေါ် ယုံကြည်မှုမလိုအပ်ပါ။

Tampering စစ်ဆေးမှုကို မြင်တွေ့ရန် notebook မှ လမ်းညွှန်သည်။

၁။ မှန်ကန်သော receipt ထုတ်လုပ်ပြီး စစ်ဆေးမှု အောင်မြင်မှုနှင့် အတည်ပြုခြင်း။ ၂။ tool_args_hash field ရဲ့ byte တစ်ခု ပြင်ဆင်ခြင်း။ ၃။ စစ်ဆေးမှု ပြန်လည် ပြုလုပ်ပြီး မအောင်မြင်ခြင်းကို ကြည့်ရှုခြင်း။

ဤသည်သည် receipt များသည် tamper-evident ဖြစ်ကြောင်း သက်သေပြချက် တစ်ခုဖြစ်သည်။ ဘယ်သူ့အားဖြင့်ဖြစ်ဖြစ် ပြင်ဆင်မှုတစ်ခုခုသည် signature က ပျက်စီးစေသည်။

Multi-Step Agents အတွက် Receipts ချိုင်ဆက်ခြင်း

Signed receipt တစ်ခုသည် လုပ်ဆောင်မှု တစ်ခုကိုကာကွယ်သည်။ Receipt ချိုင်တန်းသည် လုပ်ဆောင်မှုဆက်စပ်မှု ကို ကာကွယ်သည်။

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

Receipt တစ်ခုချင်းစီသည် ယခင် receipt ၏ hash ကို မှတ်တမ်းတင်ထားသည်။ Receipt ၂ ကို မကြားကြားဖျက်ရန် အပြစ်တစ်ဦးသည် မလိုအပ်သောကျင့်ဝတ်များတွင် တစ်ခုကို လုပ်ရမည်။

Private key ကို hardware key vault ထဲတွင် သိမ်းဆည်းပြီး public key များကို receipt တစ်ခုစီနှင့် ထုတ်ပြန်ပါက ဤတိုက်ခိုက်မှု နှစ်ခုစလုံးသည် ထိန်းသိရှိမှု မရှိဘဲ မဖြစ်နိုင်ပါ။

Notebook သည်

၁။ Receipt သုံးခု ချိုင်တန်းတည်ဆောက်ခြင်း။ ၂။ Receipt တစ်ခုချင်းစီ၏ previous_receipt_hash ကို နောက်ဆုံး receipt ၏ hash နဲ့ သက်ဆိုင်မှုစစ်ဆေးခြင်း။ ၃။ ချိုင်တန်း သောက်ပျက်မှု တစ်ခုကို အလယ်ခန်းတစ်ခုမှာ ပြုပြင်ပြီး ချိုင်တန်း ပျက်ကွက်ခြင်းကို တိတိကျကျ တွေ့မြင်ခြင်း။

၎င်းသည် သင့်အား ယုံကြည်မှုမလိုဘဲ အပြင်မှ auditor တစ်ဦးက စစ်ဆေးနိုင်သည့် audit trail တစ်ခု ဖန်တီးပေးသည်။

Receipt များသည် ဘာကို သက်သေပြသည် (နှင့် ဘာကို မသက်သေပြနိုင်)

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

Receipts များသည် သက်သေပြသောအရာ သုံးခုရှိသည်

၁။ Attribution: သတ်မှတ်ထားသော key တစ်ခုက သတ်မှတ်ထားသော payload ကို အမှတ်ထိုးခဲ့သည်။ ၂။ Integrity: Payload ကို အမှတ်ထိုးပြီးနောက် မပြောင်းလဲခဲ့ပါ။ ၃။ Ordering: Receipt က hash chain တွင် အရင် receipt အပြီးတွင် ရှိသည်။

Receipts များသည် မသက်သေပြနိုင်သောအရာများ:

၁။ မှန်ကန်မှု: Agent ၏ လုပ်ဆောင်မှုသည် မှန်ကန်သော လုပ်ဆောင်မှုဖြစ်ကြောင်း။ Receipt သည် မမှန်သော အဖြေတစ်ခုကိုလည်း တိကျသလောက် အမှတ်ထိုးနိုင်သည်။ ၂။ မူဝါဒလိုက်နာမှု: policy_id တွင် ဖော်ပြထားသော မူဝါဒသည် အကဲဖြတ်ထားကြောင်း သို့မဟုတ် စစ်ဆေးခဲ့ပါက လုပ်ဆောင်မှုကို ခွင့်ပြုမည်ဖြစ်ကြောင်း မသက်သေပြနိုင်ပါ။ Receipt သည် တင်ပြချက်ကို မှတ်တမ်းတင်သည်၊ အကောင်အထည်ဖော်မှုကို မလုပ်ပါ။ ၃။ key မကျော်လွန်သော ကိုယ်ပိုင် အထောက်အထား: Receipt က “ဒီ key က ဒီအကြောင်းအရာကို အမှတ်ထိုးခဲ့သည်” ဟုသာ ဖော်ပြသည်။ “ဒီလူကြီးမင်းက အာမခံခဲ့သည်” ဟု မဖော်ပြပါ။ Key ကို လူတစ်ဦး သို့မဟုတ် အဖွဲ့အစည်းတစ်ခုနှင့် ချိတ်ဆက်ရန် ကိုယ်ပိုင်အချက်အလက် လုပ်ငန်းစဉ်များ လိုအပ်သည် (directory, public key registry စသည်)။ ၄။ ထည့်သွင်းရကျိုးရလဒ်၏ မှန်ကန်မှု: Agent သည် ပြောင်းလဲမှုရှိသော prompt ကို လက်ခံပြီး အဲ့ဒါမူတည်ပြီး လုပ်ဆောင်လျှင် Receipt သည် လုပ်ဆောင်မှုကို သမာဓိရှိစွာ မှတ်တမ်းတင်သည်။ Receipt များက input validation အတွက် အစားထိုးမျဉ်းမဟုတ်ပါ။

ဒီ ကန့်သတ်ချက်သည် အကြောင်းကြောင့်အတွက် အရေးကြီးသည်။

ရိုးရာ အမှားတစ်ခုမှာ “Receipt များ ရှိသည်” ဆိုတာနဲ့ “ကျွန်ုပ်တို့ ဥပဒေအောက်မှာရှိသည်” ဆိုတာကို အတူတူ ထင်မှတ်သွားခြင်းဖြစ်သည်။ မဟုတ်ပါ။ Receipts သည် အခြေခံအုတ်မြစ် ဖြစ်ပြီး စီမံခန့်ခွဲမှုက သင့်ဖန်တီးထားသော စနစ်ဖြစ်သည်။

လူတစ်ယောက်က တိကျသော လုပ်ဆောင်မှုကို အတည်ပြုသည်ကို သက်သေပြခြင်း

အထက်ပါ အချက် ၃ ကို တစ်ပိုင်းခွဲဖော်ပြရန်တောင်းဆိုသည်။ လုပ်ဆောင်မှု receipt က “ဒီ key က ဒီအကြောင်းအရာကို အမှတ်ထိုးခဲ့သည်” ဆိုသည်၊ “လူတစ်ယောက်ကအာမခံခဲ့သည်” မဟုတ်ပါ။ အန္တရာယ်မြင့်လုပ်ဆောင်မှုများတွင် (ပြန်သွင်းငွေ၊ ဖျက်ပစ်ခြင်း၊ ငွေလွှဲပြောင်းခြင်း) Governance framework များမှာ တိတိကျကျ အဲ့ဒီ မပါဝင်သည့် စကားလုံးကိုလိုအပ်၍ သင်ဒီ သင်ခန်းစာမှာတည်ဆောက်ထားသော primitive များဖြင့် ထုတ်လုပ်နိုင်သည်။

‘code_samples/human-authorization-receipts.ipynb’ notebook သည် သင်ခန်းစာ receipt များနှင့် ရှေ့ဆက် envelope ပုံစံတူ human.approval.v1 ဆိုတဲ့ receipt အမျိုးအစား နှစ်ခုကို ထည့်သွင်းသည်။ အမည်ရှိသူအတည်ပြုသူက လုပ်ဆောင်မှု (canonical) ကျပြီး လုပ်ဆောင်မှု digest ပေါင်းပြီး signed ပြုလုပ်သည်။ Agent ၏ လုပ်ဆောင်မှု receipt တွင် တူညီသော လုပ်ဆောင်မှု digest နှင့် parent_approval_ref (အတည်ပြုခြင်း၏ receipt_hash) ပါဝင်သည်။ verify_chain တစ်ခုက အပေါ်တွင် ထုတ်ထားသော ဇယား ၂ ခုကို separate pinned key registries (အတည်ပြုသူ key များ နှင့် agent key များ) ဖြင့် လောလောဆယ် လမ်းကြောင်းတူကာ အာဏာပိုင် အတွက် မမျှဝေပါ။

ဤပိုင်ဆိုင်မှုသည် အတိအကျ ဖြစ်သော aserted မဟုတ်ဘဲ အကျိုးသက်ရောက်မှု ရှိသည်ကို ပြသသည်။

သွားမြောက်မှုတိုင်းမှာ မတူညီသော အကြောင်းပြချက်အခွင့်အလမ်းရှိပြီး auditor တစ်ယောက်အတွက် ခွင့်ငြင်းမှုဖတ်ရှုပြီး အာဏာအထောက်အထား စံချိန်ထဲ ကျော်လွန်သွားသော သို့မဟုတ် လုပ်ဆောင်မှု ပြောင်းလဲသွားသော သက်သေအသေအကြောင်း သိနိုင်စေသည်။ Notebook သင်ကြားသော စည်းကမ်းမှာ အမှတ်ချုပ်အတည်ပြုခြင်းတစ်ခုသည် အာဏာမဟုတ်ပါ။ အာဏာရှိနေပြီဆိုတာက Receipt နှစ်ခုမှ သိပ်သည်းသော canonical action ကို တူညီစွာ ဆိုင်းငံ့ထားစဉ်မှာ ရှိမှ ဖြစ်သည်။ လူတစ်ယောက်အတည်ပြုခြင်း receipt ကို သင်ခန်းစာအနေဖြင့် သင်ကြားခွင့်ရှိသော်လည်း draft-farley-acta-signed-receipts မှ Receipt အမျိုးအစား မဟုတ်ပါ။

ထုတ်လုပ်မှုအကြံပြုချက်များ

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

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

၂။ ထုတ်လုပ်မှု receipt စာကြည့်တိုက် အသုံးပြုပါ။ ပြင်ပ အစီအစဉ် တစ်ချို့သည် အတူတူ ဂျုံ့ပြုလုပ်ချက်များ အပိုဆောင်းပြီး key rotation, batch verification, JWK Set ဖြန့်ဝေမှု, မူဝါဒအင်ဂျင်များနှင့် ပေါင်းစည်းမှုတို့ပါဝင်သည်။

ကိုယ်တိုင်ပေါ်တွင် စာရေးခြင်း နှင့် စာကြည့်တိုက် အသုံးပြုခြင်းကြား ရွေးချယ်မှုသည် ကိုယ်တိုင် JWT စာကြည့်တိုက်ရေးခြင်း နှင့် စမ်းသပ်ပြီး ကျင့်သုံးထားသော တစ်ခုကို အသုံးပြုခြင်းထက် မတူညီပါ။ နှစ်မျိုးစလုံး သင့်တော်သည်။ စာကြည့်တိုက်သုံးခြင်းသည် အချိန်သက်သာစေပြီး audit surface ကို သက်သာစေသည်။ ကိုယ်တိုင်ရေးခြင်းသည် primitive အားလုံးကို နားလည်စေသည်။ ဒီသင်ခန်းစာသည် ကိုယ်တိုင်ရေး ခြင်းကို သင်ကြားသည်။ ဒါကြောင့် အောက်ပါရွေးချယ်မှုနှစ်ခုလုံးအတွက် အခြေခံထားသည်။

အသိပညာစစ်ဆေးမှု

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

၁။ Receipt ကို agent ၏ private Ed25519 key ဖြင့် signed ပြုသည်။ Auditor တွင် public key အားသာရှိသည်။ Auditor သည် ဖိုင်ကို offline မှ စစ်ဆေးနိုင်ပါသလား?

အဖြေ ဟုတ်ကဲ့။ Ed25519 စစ်ဆေးမှုသည် public key နှင့် signature တို့ကိုသာ လိုအပ်သည်။ Network call မလို၊ service မလို၊ သုံးတယ် တတိယပုဂ္ဂိုလ်အပေါ် ယုံကြည်မှုမလိုပါ။ ဒီဟာက receipt များကို air-gapped၊ အဖွဲ့အစည်းစုံ၊ low-trust audit ပတ်ဝန်းကျင်များတွင် အသုံးဝင်စေသည်။

၂။ တရားမဝင်သူတစ်ဦးက receipt ၏ policy_id field ကို ပိုမို ခွင့်ပြုမှုရှိသော policy သို့ ပြောင်းလဲခဲ့သည်။ Signature က မူလ payload ပေါ်မှာသာ ရှိသည်။ စစ်ဆေးမှုတွင် ဘာဖြစ်မလဲ?

အဖြေ အတည်ပြုမှု မအောင်မြင်ပါ။ လက်မှတ်ကို မူရင်း payload ၏ canonical bytes များပေါ်တွင်တွက်ချက်ထားသည်။ field များအား မည်သည့်ပုံစံဖြင့်မဆို ပြောင်းလဲသည်ဖြစ်ပါက ထို bytes များ ပြောင်းလဲသွားပြီး လက်မှတ်သည် မမှန်ကန်တော့ပါ။ ရန်သူသည် လက်ရှိမှန်ကန်သော လက်မှတ်အသစ်ထုတ်ရန် private key ကိုလိုအပ်ပါမည်၊ ၎င်းတို့တွင် မရှိပါ။

၃။ ရရှိမှုစာရွက်ထဲတွင် tool_args_hash နှင့် result_hash ကို ဗျူဟာအသုံးပြုသော raw argument များနှင့် result များခင်ရေးထားခြင်းမဟုတ်ဘဲ ထည့်သွင်းထားသော အကြောင်းရင်းကဘာလဲ?

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

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

အဖြေ ဖျက်သိမ်းထားသောရရှိမှုစာရွက်နောက်က ရရှိမှုစာရွက်များအားလုံးသာ မမှန်ကန်တော့ပါ။ ၎င်းတို့၏ `previous_receipt_hash` field များသည် လက်တွေ့ရှိနေသောအားဖြင့် မကိုက်ညီတော့ပါ (ဘယ်လောက်မှ မရှိတော့သော ရရှိမှုစာရွက်ကို တွဲထားသောကြောင့်၊ သို့မဟုတ် မတူညီသော ရရှိမှုစာရွက်နှင့် အစားထိုးညှိထားသောကြောင့်)။ ဖျက်သိမ်းမှုကို လျှို့ဝှက်ရန် ရန်သူသည် နောက်ထပ်ရရှိမှုစာရွက်တိုင်းအား ထပ်မံလက်မှတ်ရေးထိုးရမည် ဖြစ်ပြီး ၎င်းအားပြုလုပ်ရန် private key ကိုလိုအပ်ပါသည်။

၅။ ရရှိမှုတစ်ခုသည် သန့်ရှင်းစွာ အတည်ပြုလျှင် ၎င်းသည် agent ၏ လှုပ်ရှားမှုသည် မှန်ကန်၊ ခိုင်မာ သို့မဟုတ် မူဝါဒနှင့်ကိုက်ညီသည်ဟု သက်သေပြပါသလား?

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

လေ့ကျင့်မှု လက်တွေ့ကျင့်ပါ

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

၁။ အပိုင်း ၁: ပထမဆုံးရရှိမှုကို လက်မှတ်ရေးထိုး၍ အတည်ပြုပါ။ ၂။ အပိုင်း ၂: ရရှိမှုကို ပျက်ပြားအောင် ပြုလုပ်ပြီး အတည်ပြုမှု မအောင်မြင်မှုကို စမ်းသပ်ပါ။ ၃။ အပိုင်း ၃: ရရှိမှုစာရွက် သုံးခု ဆက်ပြီး ပြုလုပ်ပြီး စနစ်တကျ အစီအစဉ်ကို စစ်ဆေးပါ။ ၄။ အပိုင်း ၄: Microsoft Agent Framework ဖြင့် တည်ဆောက်ထားသော agent တွင် ဒီပုံစံကို ချိတ်ဆက်သုံး၍ ရရှိမှု စာရွက် လက်မှတ်ရေးထိုးထားသော state ဖြင့် tool call ကို wrap လုပ်ပြီး ပြီးပြီးနောက်မှာ ရရှိမှုကို လွတ်လပ်စွာ စစ်ဆေးပါ။

ထပ်ချဲ့ စိန်ခေါ်မှု ၁: သင့်ကိုယ်ပိုင် ရွေးချယ်ထားသော နောက်ထပ် field တစ်ခုဖြင့် ရရှိမှု schema ကို တိုးချဲ့ပါ (ဥပမာ၊ ဇယားကြားရန် request ID)၊ canonical signing logic တွင် ထည့်သွင်းပြီး၊ ရရှိမှုသည် verification ဖြင့် အောင်မြင်စွာ ခရက်လမ်း ချော်တတ်မှုရှိသည်ကို အတည်ပြုပါ။ ပြီးမှ ဖေါ်ပြချက် ကို ပြင်ဆင်ပြီး verification မအောင်မြင်ခြင်းကို အတည်ပြုပါ။ ဒီပုံစံသည် canonical encoding ၏ bytes တစ်လုံးချင်းစီသည် လက်မှတ်ကို ဘယ်လိုပုံစံဖြင့် သက်ရောက်မှုဖန်တီးသည်ကို နားလည်စေပါသည်။

ထပ်ချဲ့ စိန်ခေါ်မှု ၂: သင်၏ရရှိမှု နှစ်ခုကို SHA-256 hash ပြုလုပ်ပါ (၎င်းတို့၏ canonical bytes များကို သတ်မှတ်ထားသော အစီစဉ်ဖြင့် ပေါင်းစပ်ပါ)၊ ထို့နောက် ရရှိသော digest ကို တတိယရရှိမှု အတွင်းသို့ အသစ်သော field တစ်ခုအဖြစ် ထည့်ပါ။ တတိယရရှိမှုကို လက်မှတ်ရေးထိုးပြီး သုံးခုလုံး၏ round-trip verification အောင်မြင်မှုကို အတည်ပြုပါ။ ဒါဖြင့် တစ်ဆင့်ထည့်သွင်းပုံသက်သေကို ဖန်တီးထားသည့် ရရှိမှုတစ်ခု သင်တည်ဆောက်လိုက်သည်။ တတိယရရှိမှုကိုင်ဆောင်သူ မည်သူမဆို ပထမနှစ်ခုရှိခဲ့ကြောင်း အချိန်အခါတန်ပြီလက်မှတ်ရေးထိုးမှုဖြစ်ပါသည်ဟု သက်သေပြနိုင်သည်၊ ၎င်းတို့၏အကြောင်းအရာ မဖော်ပြဘဲဖြစ်ပါသည်။ ဒီမှာ selective-disclosure ရရှိမှုတွင် အသုံးပြုသော ပုံစံအဆင့်မြင့်မြင်ကွင်းများပါဝင်သည် (Merkle commitments, RFC 6962)။

နိဂုံးချုပ်

ကုဒ်ရေးရာနှင့် AI agent များအတွက် အတည်ပြုခြင်း လမ်းကြောင်း၊ဖြစ်စဉ်တစ်ခုကို ပံ့ပိုးပေးသည်။

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

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

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

သင် သင်ခန်းစာမှ ပြီးထွက်ကာ ရရှိမှု လက်မှတ်ရေးထိုးထားသော agent များကို အမှန်တကယ် deploy လုပ်ရန် ပြင်ဆင်နေပါက:

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

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

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

ဤသင်ခန်းစာသည် တစ်ချက်တည်း သက်သေစာကို လက်မှတ်ရေးထိုးခြင်းနှင့် hash-chained အစီအစဉ်ဖွဲ့ခြင်းတို့ကို ဖုံးကွယ်သည်။ ဤ primitive များကိုဂရုစိုက်၍ သင့်စီမံခန့်ခွဲမှု အဆင့်မြင့်လာသည်နှင့်အမျှ တွေ့ကြုံနိုင်သည့် အဆင့်မြင့်နည်းပညာအတော်များဘာသာစကားဖြစ်:

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

ယခင် သင်ခန်းစာ

Create Local AI Agents

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

This site is open source. Improve this page.