पाठ भिडियो हेर्नुहोस्: क्रिप्टोग्राफिक रसिदहरूसँग AI एजेन्टहरूलाई सुरक्षित पार्नुहोस्
(Microsoft कन्टेन्ट टिमले मर्ज पछि पाठ भिडियो र थम्बनेल थप्नेछ, जुन पाठ १४ / १५ को ढाँचासँग मेल खानेछ।)
यस पाठले समेट्नेछ:
यस पाठ पूरा गरेपछि, तपाईं जान्नुहुनेछ कसरी:
कल्पना गर्नुहोस् तपाईंले Contoso Travel को लागि AI एजेन्ट तैनाथ गर्नुभएको छ। एजेन्ट ग्राहकको अनुरोध पढ्छ, उडान API कल गर्छ विकल्पहरू खोज्न, र ग्राहकको तर्फबाट सिट बुक गर्छ। अघिल्लो चौमासिकमा, एजेन्टले ५०,००० बुकिङहरू प्रशोधन गर्यो।
आज एउटा अडिटकर्ता आउँछ। उनी सोध्छन्: “तपाईंको एजेन्टले के गर्यो देखाउनुहोस्।”
तपाईं आफ्नो लग फाइलहरू दिनुहुन्छ। अडिटकर्ता त्यसलाई हेरेर थप गाह्रो प्रश्न सोध्छ: “मलाई कसरी थाहा हुन्छ यी लगहरू सम्पादन भएका छैनन्?”
यो हो अडिट-ट्रेल समस्या। आजका धेरै एजेन्ट तैनाथीहरूले निर्भर गर्छन्:
यीमध्ये कुनैले पनि अडिटकर्ताको प्रश्न उत्तर दिन सक्दैन बिना अडिटकर्ताले कसैमाथि विश्वास गर्नु पर्ने (तपाईं, तपाईंको क्लाउड प्रदायक, तपाईंको डाटाबेस विक्रेता)। आन्तरिक प्रयोगका लागि त्यो विश्वास स्वीकार्य हुन्छ। नियन्त्रित कार्यभारहरू (वित्त, स्वास्थ्य सेवा, EU AI एक्ट अन्तर्गत पर्ने कुनै पनि) का लागि त्यो हुँदैन।
क्रिप्टोग्राफिक रसिदहरूले यो समस्या समाधान गर्छन् किनकि प्रत्येक एजेन्ट क्रियालाई स्वतन्त्र रूपमा प्रमाणित गर्न सकिन्छ। अडिटकर्ताले तपाईंमाथि विश्वास गर्नु पर्दैन। उनीहरूलाई केवल तपाईंको सार्वजनिक कुञ्जी र रसिद चाहिन्छ।
रसिद एक JSON वस्तु हो जसले एजेन्टले के गर्यो दर्ता गर्छ, डिजिटल हस्ताक्षरसँग साइन गरिएको।
flowchart LR
A[एजेन्टले उपकरण चलाउँछ] --> B[रसीद पेलोड तयार पार्नुहोस्]
B --> C[JSON RFC 8785 क्यानोनिकलाइज गर्नुहोस्]
C --> D[SHA-256 ह्यास]
D --> E[Ed25519 साइन गर्नुहोस्]
E --> F[हस्ताक्षरसहित रसीद]
F --> G[लेखा परीक्षकले अफलाइन प्रमाणित गर्दछ]
G --> H{हस्ताक्षर मान्य छ?}
H -- हो --> I[छेपी-प्रमाणित प्रमाण]
H -- होइन --> 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 निजी कुञ्जीसँग साइन गरेको हुन्छ। सम्बन्धित सार्वजनिक कुञ्जीसँग जोसुकैले असञ्जालमा हस्ताक्षर प्रमाणित गर्न सक्छ। कुनै पनि फिल्डमा छेडछाडले हस्ताक्षर अमान्य पार्छ।
क्यानोनिकल एन्कोडिङ। साइन गर्नुअघि रसिद JSON क्यानोनिकलाइजेसन स्किम (JCS, RFC 8785) प्रयोग गरी सिरियलाइज्ड हुन्छ। यसले सुनिश्चित गर्छ कि एउटै तर्कसंगत रसिद उत्पादन गर्ने दुईवटा कार्यान्वयनले ठ्याक्कै एउटै बाइट आउटपुट दिन्छन्। क्यानोनिकलाइजेसन नहुँदा फरक JSON सिरियलाइजरहरूले फरक हस्ताक्षर उत्पादन गर्थे।
ह्याश चेनिङ। 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()}"
# एक सायनिङ कुञ्जी उत्पादन गर्नुहोस् वा लोड गर्नुहोस् (उत्पादनमा, कुञ्जी भॉल्टमा भण्डारण गर्नुहोस्)
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)),
},
}
यो नै सम्पूर्ण साइनिङ पाइपलाइन हो। नोटबुकमा कसरतहरूले प्रत्येक चरणमा मार्गदर्शन गर्छन्।
प्रमाणीकरण विपरित प्रक्रिया हो:
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 = {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 फर्काउँछ, नत्र False। कुनै नेटवर्क कल, कुनै सेवा निर्भरता छैन, र कुनै तेस्रो पक्षमाथि विश्वास आवश्यक छैन।
छेडछाड पत्ता लगाउने क्रियामा हेर्न, नोटबुकले यी चरणहरू देखाउँछ:
tool_args_hash फिल्डको एक बाइट परिमार्जन गर्ने।यो व्यवहारिक प्रदर्शन हो कि रसिदहरू छेडछाड-प्रमाणित छन्: कुनै पनि सानो परिमार्जनले हस्ताक्षर बिगार्छ।
एकल साइन गरिएको रसिदले एक कार्यको सुरक्षा गर्छ। रसिदहरूको चेनले श्रृंखलाको सुरक्षा गर्छ।
flowchart LR
R0[रसीद ०<br/>जेनिसिस] --> R1[रसीद १]
R1 --> R2[रसीद २]
R2 --> R3[रसीद ३]
R1 -. previous_receipt_hash .-> R0
R2 -. previous_receipt_hash .-> R1
R3 -. previous_receipt_hash .-> R2
हरेक रसिद अगाडिको रसिदको ह्याश दिन्छ। यदि कसैले रसिद २ लाई चुपचाप हटाउन खोज्यो भने, उनीहरूले या त:
previous_receipt_hash फिल्डलाई परिवर्तन गर्नुपर्नेछ (रसिद ३ को हस्ताक्षर भंग हुन्छ), वायदि निजी कुञ्जी हार्डवेयर कुञ्जी भॉल्टमा छ र तपाईं प्रत्येक रसिदसँग सार्वजनिक कुञ्जी प्रकाशित गर्नुहुन्छ भने, यी दुबै आक्रमणहरू पत्ता नलागी सम्भव छैनन्।
नोटबुकले देखाउँछ:
previous_receipt_hash ले पहिलाको रसिदको वास्तविक ह्याशसँग मेल खान्छ भनेर प्रमाणित गर्ने।यसो गर्दा एउटा बाह्य अडिटकर्ताले तपाईंमाथि भरोसा नगरी पनि अडिट ट्रेल प्रमाणित गर्न सक्छ।
यो यस पाठको सबैभन्दा महत्त्वपूर्ण खण्ड हो। रसिदहरू शक्तिशाली छन् तर तिनीहरूको शक्ति सीमित छ।
रसिदहरूले तीन कुरा प्रमाणित गर्छन्:
रसिदहरूले प्रमाणित गर्दैनन्:
policy_id मा उल्लिखित नीतिलाई साँच्चै मूल्यांकन गरिएको थियो वा यो कार्यलाई अनुमति दिने थियो। रसिदले दावी प्रदर्शित गर्छ, लागू गरिएन।यो सिमा महत्त्वपूर्ण छ दुई कारणले:
साधारण गल्ती हो “हामीसँग रसिदहरू छन्” भनेको “हामी सुशासनवालाहरु हौं” भन्ने मान्नु। हुँदैन। रसिद आधार हो। सुशासन त्यो प्रणाली हो जुन तपाईं माथि बनाउनुहुन्छ।
यस पाठको Python कोड जानाजानी न्यूनतम छ ताकि तपाईं प्रत्येक पंक्ति पढेर के भइरहेको छ बुझ्न सक्नुहुन्छ। उत्पादनमा दुई विकल्पहरू हुन्:
क्रिप्टोग्राफिक आधारभूतमा सिधै निर्माण गर्ने। माथिका ५० पंक्तिहरू धेरै प्रयोगक लागि पर्याप्त छन्। PyNaCl (Ed25519) र jcs प्याकेज (क्यानोनिकल JSON) राम्रोसँग मर्मत र अडिट गरिएका पुस्तकालयहरू हुन्।
उत्पादन रसिद पुस्तकालय प्रयोग गर्ने। कयौं खुला स्रोत परियोजनाहरूले यो ढाँचाको अतिरिक्त सुविधा (कुञ्जी रोटेसन, ब्याच प्रमाणीकरण, JWK सेट वितरण, नीति ईन्जिनसँग एकीकरण) सहित कार्यान्वयन गर्छन्:
draft-farley-acta-signed-receipts) हो जुन अहिले मापदण्ड प्रक्रियामा छ।protect-mcp (npm) र @veritasacta/verify (npm) प्याकेजहरूले Node आधारित रसिद साइन र अफलाइन प्रमाणीकरण कार्यान्वयन गर्छन्, कोही पनि MCP सर्भरलाई छेडछाड-प्रमाणित अडिट ट्रेलका लागि झुम्क्याउन उपयुक्त।आफ्नो JWT पुस्तकालय लेख्ने वा विश्वसनीय एक प्रयोग गर्ने निर्णयसँग मिल्दोजुल्दो निर्णय हो: दुवै ठीक छन्; पुस्तकालयले समय बचाउँछ र अडिट सतह घटाउँछ; शून्यबाट लेख्नेले प्रत्येक आधारभूत बुझ्न बाध्यता ल्याउँछ। यो पाठ शून्यबाट सिकाउँछ ताकि दुबै बाटो तयार गर्न सकियोस्।
व्यावहारिक अभ्यास अघि तपाईको बुझाइ टेस्ट गर्नुहोस्।
१. रसिद एजेन्टको निजी Ed25519 कुञ्जीसँग साइन गरिएको छ। अडिटकर्तासँग केवल सार्वजनिक कुञ्जी छ। के अडिटकर्ताले रसिद अफलाइन प्रमाणित गर्न सक्छ?
२. आक्रमणकारीले रसिदको policy_id फिल्ड परिमार्जन गरी दाबी गरे कि यो कम कडा नीतिले शासन गरिएको थियो। हस्ताक्षर मूल पेलोडमा थियो। प्रमाणीकरणमा के हुन्छ?
३. रसिदमा कच्चा आर्गुमेन्ट र नतिजाको सट्टा tool_args_hash र result_hash किन समावेश छन्?
४. previous_receipt_hash फिल्डले रसिदलाई पूर्ववर्ती रसिदसँग लिंक गर्छ। यदि आक्रमणकारीले चेनको बीचको एउटा रसिद चुपचाप हटायो भने के अमान्य हुन्छ?
५. रसिद सफा प्रमाणित भयो। के यसले एजेन्टको कार्य सहि, ध्वनि, वा नीति अनुरूप भएको प्रमाणित गर्छ?
code_samples/18-signed-receipts.ipynb खोल्नुहोस् र सबै चार सेक्सनहरू पूरा गर्नुहोस्:
विस्तृत चुनौती १: रसिद स्किमामा आफ्नो रोजाइको अतिरिक्त फिल्ड (जस्तै, ट्रेसिङका लागि अनुरोध ID) थप्नुहोस्, क्यानोनिकल साइनिङ तर्क अद्यावधिक गर्नुहोस् र रसिद प्रमाणिकरणमा अडराउन्ड सुनिश्चित गर्नुहोस्। त्यसपछि साइन पश्चात् फिल्ड परिमार्जन गरी प्रमाणीकरण विफल हुनु पुष्टी गर्नुहोस्। यसले तपाईंलाई बुझ्न बाध्य बनाउनेछ कि क्यानोनिकल एन्कोडिङका प्रत्येक बाइटले हस्ताक्षरमा कसरी योगदान गर्छ। स्ट्रेच चुनौती २: आफ्ना दुई भौचरहरूलाई सँगै 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 पोस्ट-क्वान्टम हस्ताक्षर मानक) बोकेको हुन सक्छ जब स्थानान्तरण आवश्यक पर्छ। यस्तो संक्रमण अवधिको योजना बनाउनुस् जहाँ भौचरहरू दुबै हस्ताक्षर गरिएका हुन्छन्।Building Computer Use Agents (CUA)
(पाठ्यक्रम व्यवस्थापकहरूले तय गर्ने)
अस्वीकरण: यो दस्तावेज़ AI अनुवाद सेवा Co-op Translator प्रयोग गरेर अनुवाद गरिएको हो। हामी सही हुन प्रयास गर्छौं, तर कृपया जानकार हुनुस् कि स्वचालित अनुवादमा त्रुटिहरू वा अशुद्धताहरू हुन सक्छन्। मूल दस्तावेज़ यसको मूल भाषामा आधिकारिक स्रोत मानिनुपर्छ। महत्वपूर्ण जानकारीका लागि व्यावसायिक मानव अनुवाद सिफारिस गरिन्छ। यस अनुवादको प्रयोगबाट उत्पन्न कुनै पनि गलत बुझाइ वा त्रुटिको लागि हामी जिम्मेवार छैनौं।