មើលវីដេអូចំណងថ្នាក់៖ ការសន្តិសុខភ្នាក់ងារត្រូវបានគ្រប់គ្រងដោយសំបុត្រជាសញ្ញាឌីជីថល
(វីដេអូចំណងថ្នាក់ និងរូបតំណាងនឹងត្រូវបញ្ចូលដោយក្រុមមាតិកា Microsoft បន្ទាប់ពីការរួមបញ្ចូល តាមគំរូថ្នាក់ទី 14 / 15)
មេរៀននេះនឹងពិភាក្សា៖
បន្ទាប់ពីបញ្ចប់មេរៀននេះ អ្នកនឹងអាច៖
សូមសម្រម់ថា អ្នកបានចាត់តាំងភ្នាក់ងារ AI សម្រាប់ Contoso Travel។ ភ្នាក់ងារនេះអានសំណើររបស់អតិថិជន ហៅ API រហ៊ុនជើងហោះហើរដើម្បីស្វែងរកជម្រើស ហើយកក់កៅអីសម្រាប់អតិថិជន។ ត្រីមាសចុងក្រោយ អ្នកភ្នាក់ងារនេះបានដំណើរការការកក់ 50,000 ករណី។
ថ្ងៃនេះ អ្នកបញ្ជាក់ត្រួតពិនិត្យមកដល់។ ពួកគេចង់សួរចំៗ៖ “បង្ហាញពីអ្វីដែលភ្នាក់ងាររបស់អ្នកបានធ្វើ។”
អ្នកប្រគល់ឯកសារកំណត់ហេតុរបស់អ្នក។ អ្នកបញ្ជាក់មើលឯកសារនឹងសួរពិសេស៖ “តើធ្វើដូចម្តេចដើម្បីដឹងថាឯកសារបានកែប្រែមិនបានធ្វើឡើយ?”
នេះគឺជាបញ្ហាប្រវត្តិកំណត់ហេតុ។ ការចាត់តាំងភ្នាក់ងារឥឡូវនេះភាគច្រើនពឹងផ្អែកលើ៖
គ្មានអ្វីក្នុងចំណោមនេះអាចឆ្លើយសំណួររបស់អ្នកបញ្ជាក់ដោយគ្មានការទុកចិត្តនរណាម្នាក់ (អ្នក, អ្នកផ្តល់សេវាពពក, ឬអ្នកផ្គត់ផ្គង់មូលដ្ឋានទិន្នន័យ)។ សម្រាប់ការប្រើប្រាស់ក្នុងសកម្មភាពក្នុងស្រុក ការទុកចិត្តនោះជាទ្រព្យសម្បត្តិនឹងគ្រាន់តែទទួលយកបាន។ សម្រាប់សកម្មភាពដែលត្រូវបានគ្រប់គ្រង (ហិរញ្ញវត្ថុ, សុខាភិបាល, ឬអ្វីដែលត្រូវអនុវត្តតាមច្បាប់ AI របស់ EU) វាមិនអនុញ្ញាតឡើយ។
សំបុត្រជាសញ្ញាឌីជីថល ដោះស្រាយបញ្ហានេះដោយធ្វើឲ្យសកម្មភាពនីមួយៗរបស់ភ្នាក់ងារអាចផ្ទៀងផ្ទាត់ដោយឯករាជ្យបាន។ អ្នកបញ្ជាក់មិនចាំបាច់ដាក់ចិត្តលើអ្នកទេ។ ពួកគេចាំបាច់គ្រប់គ្រាន់តែមានគ្រាប់សាធារណៈ និងសំបុត្រតែម្តង។
សំបុត្រជាអ.obj.JSON ដែលកត់ត្រាពីសកម្មភាពភ្នាក់ងារ ហើយចុះហត្ថលេខាជាមួយហត្ថលេខាឌីជីថល។
flowchart LR
A[ភ្នាក់ងារហៅឧបករណ៍មួយ] --> B[បង្កើតទ្រង់ទ្រាយរបាយការណ៍]
B --> C[រក្សាទ្រង់ទ្រាយ JSON RFC 8785]
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..."
}
}
គុណលក្ខណៈបីរបស់វាធ្វើការងារ៖
ហត្ថលេខា។ សំបុត្រចុះហត្ថលេខាជាមួយក្របខ័ណ្ឌច្រកភ្នាក់ងារ ដោយប្រើគ្រាប់ Ed25519 ភាគហ៊ុនឯកជន។ នរណាមួយដែលមានគ្រាប់សាធារណៈដែលពាក់ព័ន្ធអាចផ្ទៀងផ្ទាត់ហត្ថលេខាដោយមិនប្រើអ៊ីនធឺណិត។ ការបំលែងនៅកន្លែងណាមួយក្នុងវាលលទ្ធផលនឹងធ្វើអោយហត្ថលេខាធ្វើការមិនត្រឹមត្រូវ។
កូដប្រែឯកសារcanonical។ មុនចុះហត្ថលេខា សំបុត្រត្រូវបានចំណាត់ថ្នាក់តាម JSON Canonicalization Scheme (JCS, RFC 8785)។ វាការពារថាវិធីសាស្រ្តពីការបញ្ចេញសញ្ញាដូចគ្នានៅក្នុងការប្រើប្រាស់ផ្សេងៗដោយផ្ដល់លទ្ធផលបិតជាឃ្លាំមើលដូចគ្នា។ ការមិនប្រើ canonicalization ធ្វើអោយ JSON ស្រីលីះរបស់ជ្រុងផ្សេងៗបង្កើតហត្ថលេខាផ្សេងគ្នាសម្រាប់មាតិកាដូចគ្នា។
ខ្សែស្រឡាយ Hash chaining។ វាល previous_receipt_hash តភ្ជាប់សំបុត្រពីមួយទៅមួយមុន។ ការដករឺប្ដូរតម្រៀបសំបុត្រមួយធ្វើឲ្យសំបុត្របន្ទាប់ៗទាំងអស់ខូចខាត។ ការក្លែងបន្លំក៏អាចបង្ហាញនៅលើកម្រិតខ្សែស្រឡាយ ទោះបីហត្ថលេខាឯកត្តិមួយចុះប្រាស់មិនត្រឹមត្រូវក៏ដោយ។
លក្ខណៈទាំងបីនេះផ្ដល់អោយនូវការធានា៣ៈ
អ្នកមិនចាំបាច់មានបណ្ណាល័យពិសេសដើម្បីផលិតសំបុត្រឡើយ។ គ្រឿង cryptographic សម្រាប់នេះមានស្រាប់ហើយលក្ខខណ្ឌត្រឹមបានច្រើនជួរដោយ Python មួយចំនួន។
ការអនុវត្តផ្នែកធ្វើជាក់ស្តែងនៅក្នុង code_samples/18-signed-receipts.ipynb នឹងជាមគ្គុទេសក៍ពេញលេញ។ សង្ខេប៖
import json
import hashlib
import base64
from nacl import signing
from jcs import canonicalize # JSON តាមស្តង់ដារ RFC 8785
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()}"
# បង្កើត ឬផ្ទុកកូនសោសំរាប់ហត្ថលេខា (នៅក្នុងផលិតកម្ម ដាក់ទុកក្នុងតោនកូនសោ)
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, ធ្វើ 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)),
},
}
នេះគឺជាចំណុចចុះហត្ថលេខាដែលពេញលេញ។ ការអនុវត្តក្នុងសៀវភៅរៀនគឺជាការឆ្លើយតបក្នុងជំហាននីមួយៗ។
ការផ្ទៀងផ្ទាត់គឺជាអ៉ុពេរ៉ាស់អាំងវឺសៈ៖
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)
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
មុខងារនេះទទួលយកសំបុត្រមួយ ហើយបង្វិលតម្លៃ True ប្រសិនបើហត្ថលេខាត្រឹមត្រូវ មិនមែនទេហើយផ្សេងទៀត។ មិនចាំបាច់ហៅបណ្តាញ គ្មានការពឹងពាក់សេវាកម្ម ឬការទុកចិត្តលើភាគីទីបី។
ដើម្បីឃើញការរកឃើញការក្លែងបន្លំ សៀវភៅរៀននេះនឹងបង្ហាញ៖
tool_args_hash។នេះគឺជាការបង្ហាញជាក់ស្តែងថាសំបុត្រមានលក្ខណៈគ្មានទំនុកចិត្ត: ការផ្លាស់ប្ដូរណាមួយ មិនថាតិចប៉ុណ្ណា គឺធ្វើឲ្យហត្ថលេខាបាត់បង់ភាពត្រឹមត្រូវ។
សំបុត្រចុះហត្ថលេខាដោយផ្ទាល់មួយការពារសកម្មភាពមួយ។ ខ្សែសំបុត្រមួយការពារតួ sequence មួយ។
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 ដោយស្ងាត់ សកម្មជនមួយត្រូវការប្ដូរឲ្យមាន៖
previous_receipt_hash របស់សំបុត្រ 3 (ធ្វើឲ្យហត្ថលេខានៃសំបុត្រ 3 ខូចខាត), ឬបើគ្រាប់ឯកជនស្ថិតក្នុង hardware key vault ហើយអ្នកបោះពុម្ពគ្រាប់សាធារណៈជាមួយគ្រប់សំបុត្រសម្រាប់រាល់ពេល ការវាយប្រហារទាំងពីរនេះពុំអាចអនុវត្តបានដោយគ្មានការរកឃើញ។
សៀវភៅរៀនបង្ហាញ៖
previous_receipt_hash នៃសំបុត្រនីមួយៗផ្គូផ្គងនឹង hash ពិតប្រាកដនៃសំបុត្រមុន។នេះជារបៀបដែលអ្នកផលិតប្រវត្តិ audit ដែលអ្នកបញ្ជាក់ខាងក្រៅអាចផ្ទៀងផ្ទាត់ដោយមិនត្រូវទុកចិត្តលើអ្នក។
នេះជាផ្នែកសំខាន់បំផុតនៃមេរៀននេះ។ សំបុត្រមានអំណាច ប៉ុន្តែមានកំណត់។
សំបុត្របញ្ជាក់អ្វី៣មុខ៖
សំបុត្រមិនបញ្ជាក់អ្វី៖
policy_id អាចមិនត្រូវបានវាយតម្លៃ ឬមិនអាចអនុញ្ញាតសកម្មភាពនេះបើត្រូវបានពិនិត្យ។ សំបុត្រកត់ត្រាអ្វីដែលបានថ្លែង មិនមែនអ្វីដែលបានអនុវត្ត។ព្រំដែននេះមានសារៈសំខាន់ពីរមូលហេតុ៖
កំហុសទូទៅគឺគិតថា “យើងមានសំបុត្រ” មានន័យថា “យើងមានអំណាចគ្រប់គ្រង។” វាមិនត្រឹមត្រូវទេ។ សំបុត្រជាគ្រឹះបន្ទាប់ ហើយអំណាចគ្រប់គ្រងគឺជាការបញ្ជំបង្កើតលើវា។
កែច្នៃចំណេះដឹងរបស់អ្នកមុនចូលទៅឧបករណ៍អនុវត្ត។
1. សំបុត្រត្រូវបានចុះហត្ថលេខាជាមួយគ្រាប់កូនសោ Ed25519 ផ្ទៃក្នុងភ្នាក់ងារ។ អ្នកបញ្ជាក់ទាន់តែមានគ្រាប់សាធារណៈតែប៉ុណ្ណោះ។ តើអ្នកបញ្ជាក់អាចផ្ទៀងផ្ទាត់សំបុត្របានដោយមិនប្រើអ៊ីនធឺណិតបានទេ?
2. អ្នកប្រហារប្ដូរវាល policy_id នៃសំបុត្រដោយថាគោលការណ៍ដោះស្រាយមានសិទ្ធិច្រើនជាងតែម្តង។ ហត្ថលេខាត្រូវបានគណនាលើ payload ដើម។ តើមានអ្វីកើតឡើងនៅពេលផ្ទៀងផ្ទាត់?
3. ហេតុអ្វីបានជាសំបុត្ររួមបញ្ចូល tool_args_hash និង result_hash ជំនួសargs និងលទ្ធផលដើម?
4. វាល previous_receipt_hash តភ្ជាប់សំបុត្រនីមួយៗទៅឲ្យសំបុត្រមុនរបស់វា។ បើអ្នកប្រហារពន្លាក់សំបុត្រមួយនៅកណ្តាលខ្សែស្រឡាយ សំបុត្រណាខូចខាត?
5. សំបុត្រផ្ទៀងផ្ទាត់បានស្អាត។ តើវាបញ្ជាក់ថាសកម្មភាពភ្នាក់ងារត្រឹមត្រូវ ឬមានសមត្ថភាពធ្វើតាមគោលការណ៍ទេ?
បើក code_samples/18-signed-receipts.ipynb និងបញ្ចប់ចំណុចទាំងបួន៖
ស្ថេរភាពលើកទី 2: លាយ SHA-256 ពីសំបុត្រពីរពីរបស់អ្នកជាមួយគ្នា (ភ្ជាប់បៃត៍កាណូណិចរបស់ពួកវា ក្នុងលំដាប់កំណត់) ហើយដាក់ហាសហើយវា ជាប្រឡាយថ្មីលើយោងទៅលើសំបុត្របីមុនចុះហត្ថលេខា។ ផ្ទៀងផ្ទាត់ថាសំបុត្រទាំងបីនៅតែអាចបញ្ចេញតាមការផ្ទៀងផ្ទាត់បាន។ អ្នកទើបតែបង្កើតភស្តុតាងបញ្ចូលមួយជំហានៈ អ្នកណាដែលកាន់សំបុត្របីនេះអាចបញ្ជាក់ថាសំបុត្រពីរដំបូងមាននៅពេលវាត្រូវបានចុះហត្ថលេខា ដោយមិនចាំបាច់បង្ហាញមាតិការបស់ពួកវាទេ។ នេះជាគំរូដែលសំបុត្របង្ហាញជ្រើសរើសប្រើប្រាស់នៅចាបបែងចែកក្នុងធំ (ការប្តេជ្ញាចិត្តMerkle, RFC 6962)។
សំបុត្រស្លាជ្ជមានវិភាគ កាតព្វកិច្ច AI ផ្តល់នូវខ្សែដំណើរការស្ថិតនៅក្រោមការត្រួតពិនិត្យ ដែល៖
ពួកវាមិនជាជំនួសសម្រាប់ការត្រួតពិនិត្យបញ្ចូល, អនុវត្តន៍គោលការណ៍ឬគ្រឹះស្ថានអត្តសញ្ញាណឡើយ។ ពួកវាជាមូលដ្ឋានសម្រាប់លើស្រទាប់ទាំងនោះ។ នៅពេលអ្នកបញ្ចេញអេហ្សង់នៅក្នុងបន្ទុកដែលមានការត្រួតពិនិត្យ, សំណុំការងារសហគ្រិន ច្រកផ្លូវការឬកន្លែងណាមួយដែលអ្នកនឹកស្មានមិនថាអ្នកមិនត្រូវជឿជាក់ពីអ្នកទេ អ្នកត្រូវប្រើសំបុត្រជាផ្លូវការ ដើម្បីធានាថាខ្សែដំណើរការត្រឹមត្រូវ។
អ្វីសំខាន់បំផុតគឺ៖ សំបុត្របញ្ជាក់ថា នរណាបាននិយាយអ្វី និងពេលណា។ វាមិនបញ្ជាក់ថាអ្វីដែលបាននិយាយគឺពិតឬត្រឹមត្រូវឡើយ។ ត្រូវរក្សាភាពខុសគ្នានេះឱ្យជាប់រឹងមាំ។ នេះជាការប្រៀបធៀបរវាងប្រព័ន្ធដើមប្រភពដែលស្មោះត្រង់ និងមួយដែលបញ្ឆោតបញ្ឆោញ។
នៅពេលអ្នករួចរាល់ក្នុងការសិក្សាពីមេរៀននេះទៅរកការបញ្ចេញអេហ្សង់ដែលបានចុះហត្ថលេខាសំបុត្រនៅបរិយាកាសពិតប្រាកដ៖
https://your-org.example.com/.well-known/agent-keys.json។ចូលរួមក្នុង Microsoft Foundry Discord ដើម្បីជួបជាមួយអ្នករស់រានមានជីវិតផ្សេងទៀត ចូលរួមម៉ោងការិយាល័យ និងទទួលបានចម្លើយសម្រាប់សំណួរអំពីអេហ្សង់ AI របស់អ្នក។
មេរៀននេះគ្របដណ្តប់ចោលការចុះហត្ថលេខាសំបុត្រតែមួយ និងខ្សែសង្វាក់ហាសបន្សំ។ អ្នកអាចប្រើបច្ចេកទេសដដែលដើម្បីបង្កើតគំរូកម្រិតខ្ពស់ជាច្រើន ដែលអ្នកប្រហែលជជួបប្រទៈពេលកំណត់គ្រប់គ្រងរបស់អ្នកកាន់តែច្រើនជាងមុន៖
authorization_*) និងបន្ទាប់រត់ (result_*) ជាមួយហត្ថលេខាឯករាជ្យ ដែលមានប្រយោជន៍ពេលសេចក្តីសម្រេចការអនុញ្ញាត និងលទ្ធផលដែលមើលឃើញត្រូវបានបង្កើតដោយអ្នកដឹកនាំផ្សេងគ្នា ឬពេលខុសគ្នា។ វាអាចបន្ថែមលើទ្រង់ទ្រាយសំបុត្រដែលបានបង្រៀននៅមេរៀននេះ។result_hash។ ផ្ទុកទិន្នន័យពិតជិតបានិយាយហៅតិចក្រៅលទ្ធផលឧបករណ៍មួយលើកតែមួយ ៖ ពិចារណាពីមុនសេចក្តីសម្រេច (ការព្យាករណ៍គំរូ, ជម្រើសបានពិចារណា, ភស្តុតាង និងភាពគ្រប់គ្រាន់របស់វា, ទីតាំងគោលការណ៍, ខ្សែដៃទទួលខុសត្រូវ, លទ្ធផលប្រពន្ធ័កំណត់ទ្វារ) អាចផ្តល់ជាច្រកទិន្នន័យទាំងមូលក្នុងផ្ទុក, បានចាក់សោដោយសំបុត្រតែមួយ។ នេះរក្សាទ្រង់ទ្រាយសំបុត្រឲ្យតិចបំផុត ខណៈអោយស្គីម៉ាផ្ទុកទិន្នន័យអាចរីកចម្រើនឆ្ពោះទៅកាន់ដែនកំណត់ផ្សេងៗ។signature.alg អាចពេញ ML-DSA-65 (ស្តង់ដាហត្ថលេខាក្រោយគុណវិបត្តិ NIST) នៅពេលអ្នកត្រូវបម្លែង។ គ្រោងការជាមួយរយៈពេលឆ្ពោះដល់ពេលដែលសំបុត្រត្រូវបានចុះហត្ថលេខាប្រកបដោយហត្ថលេខាពីររូប។ការបង្កើតអេហ្សង់បម្រើកុំព្យូទ័រ (CUA)
(ទន្ទឹមត្រូវបានកំណត់ដោយអ្នកថែរក្សាគ្រោងការសិក្សា)
ការបដិសេធ: ឯកសារនេះត្រូវបានបម្លែងភាសា ដោយប្រើសេវាបម្លែងភាសា AI Co-op Translator។ ទោះយើងខ្ញុំមានក្តីប្រាថ្នាឱ្យបានច្បាស់លាស់ តែសូមយល់ដឹងថាការបម្លែងដោយស្វ័យប្រវត្តិក៏អាចមានកំហុសឬភាពមិនត្រឹមត្រូវ។ ឯកសារដើមជាភាសាទីតាំងគួរត្រូវបានគេប្រើជាប្រភពច្បាស់លាស់។ សម្រាប់ព័ត៌មានសំខាន់ៗ សូមណែនាំឱ្យប្រើប្រាស់ការប្រែដោយមនុស្សជំនាញ។ យើងខ្ញុំមិនទទួលខុសត្រូវចំពោះការយល់ច្រឡំ ឬការបកស្រាយខុសបន្ទាប់ពីការប្រើប្រាស់ការបម្លែងនេះនោះទេ។