पाठ भिडियो हेर्नुहोस्: क्रिप्टोग्राफिक रसिदहरूसँग AI एजेन्टहरू सुरक्षित बनाउने
(पाठ भिडियो र थम्बनेल मर्ज पछि माइक्रोसफ्ट सामग्री टोलीले थप्नेछ, पाठ १४ / १५ ढाँचासँग मेल खाने।)
यस पाठले समेट्नेछ:
यस पाठ पूरा गरेपछि, तपाईं जान्नुहुनेछ:
कल्पना गर्नुहोस् तपाईंले 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 ८७८५) प्रयोग गरेर सिरियलाइज हुन्छ। यसले दुई फरक इम्प्लिमेन्टेसनहरूले एउटै तार्किक रसिदका लागि बिट्स समान बनाउन सुनिश्चित गर्दछ। क्यानोनिकलाइजेशन बिना, फरक 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[रसिद 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
प्रत्येक रसिदले अघिल्लो रसिदको ह्यास रेकर्ड गर्छ। दोस्रो रसिदलाई हर फुस्रो रूपमा हटाउन हमलावरले यीमध्ये एक गर्नुपर्नेछ:
previous_receipt_hash फिल्ड परिवर्तन गर्ने (रसिद ३ को हस्ताक्षर तोडिन्छ), वायदि निजी कुञ्जी हार्डवेयर कुञ्जी भल्टमा छ र तपाईंले प्रत्येक रसिदसँग सार्वजनिक कुञ्जी प्रकाशित गर्नुहुन्छ भने यी कुनै पनि हमलावर पत्ता नलाग्न नसक्ने छन्।
नोटबुकले देखाउँछ:
previous_receipt_hash अघिल्लो रसिदको वास्तविक ह्याससँग मेल खाने पुष्टि गर्ने।यसरी तपाईंले बाह्य अडिटरले विश्वास नगरिकन प्रमाणीकरण गर्न सक्ने अडिट ट्रेल उत्पादन गर्नुहुन्छ।
यो यस पाठको सबैभन्दा महत्त्वपूर्ण भाग हो। रसिदहरू शक्तिशाली छन् तर तिनीहरूको शक्ति सीमित छ।
रसिदहरूले तीन कुरा प्रमाणित गर्छन्:
रसिदहरूले प्रमाणित गर्दैनन्:
policy_id मा देखाइएको नीति साँच्चिकै मूल्यांकन भयो वा यो क्रियालाई अनुमति दिन्थ्यो कि छैन। रसिदले दावी गरिएको कुरा मात्र रेकर्ड गर्छ, जुन लागू भएको होइन।यो सीमा दुई कारणले महत्त्वपूर्ण छ:
सामान्य गल्ती हो बुझ्नु कि “हामीसँग रसिदहरू छन्” भनेको “हामी नियन्त्रित छौं”। होइन। रसिदहरू आधार हुन्। शासन (Governance) तपाईंले त्यसमा बनाउनु भएको प्रणाली हो।
यस पाठको Python कोड जानकार तीसरी साइड पुस्तकालय नचलाइ सबै लाइनहरू पढ्न र बुझेका हेतुले अति न्यूनतम छ। उत्पादनमा तपाईंसँग दुई विकल्प छन्:
क्रिप्टोग्राफिक प्रिमिटिभहरूमा सिधै बनाउने। माथि देखाएको ५० पंक्ति धेरै उपयोगी केसहरूका लागि पुग्छ। PyNaCl (Ed25519) र jcs प्याकेज (क्यानोनिकल JSON) राम्रोसँग मर्मत गरिएको र अडिट गरिएको पुस्तकालयहरू हुन्।
उत्पादन रसिद पुस्तकालय प्रयोग गर्ने। धेरै खुला स्रोत परियोजनाले त्यहि ढाँचामा थप सुविधा (कुञ्जी रोटेसन, ब्याच प्रमाणीकरण, JWK सेट वितरण, नीति इन्जिनसँग एकीकरण) कार्यान्वयन गरेका छन्:
draft-farley-acta-signed-receipts) मा छ र मानक प्रक्रिया अन्तर्गत छ।protect-mcp (npm) र @veritasacta/verify (npm) प्याकेजहरूले रसिद हस्ताक्षर र अफलाइन प्रमाणीकरणको Node-आधारित कार्यान्वयन गर्छन्, कुनै पनि MCP सर्भरलाई छेउफिरे प्रमाणित अडिट ट्रेलमा र्याप गर्ने उद्देश्यले।pip install nobulex) ले Python मा Ed25519 + JCS साइनिङ ढाँचा LangChain र CrewAI एकीकरणसहित उपलब्ध गराउँछ, प्रकाशित क्रस भ्यालिडेसन टेस्ट भेक्टर र OWASP PR #2210 मार्फत योगदान गरिएको अनुपालन नक्शासहित।आफ्नै JWT पुस्तकालय लेख्ने र जाँचिएको प्रयोग गर्ने बीच निर्णय जस्तै, आफ्नै रसिद पुस्तकालय बनाउने वा प्रयोग गर्ने निर्णय पनि यस्तै हो: दुवै उपयुक्त; पुस्तकालयले समय बचत गर्छ र अडिट सतह घटाउँछ; तर खरोंचबाटले प्रत्येक प्रिमिटिभ बुझ्न बाध्य पार्छ। यो पाठले खरोंचबाट सिकाउने छ ताकि तपाईं दुबै बाटोका लागि आधार राख्न सक्नुहोस्।
व्यावहारिक अभ्यासमा जानुअघि आफूलाई परिक्षण गर्नुहोस्।
१. रसिद एजेन्टको निजी Ed25519 कुञ्जीले साइन गरिएको छ। अडिटरलाई केवल सार्वजनिक कुञ्जी छ। के अडिटर रसिद अफलाइन प्रमाणीकरण गर्न सक्छ?
२. एउटा हमलावरले रसिदको policy_id फिल्डलाई परिवर्तन गरेर बढी सहमतीय नीति दाबी गर्छ। हस्ताक्षर मूल प्यालोडमाथि छ। प्रमाणीकरण गर्दा के हुन्छ?
३. रसिदमा tool_args_hash र result_hash राखिन्छ किन कच्चा तर्क र परिणाम होइन?
४. previous_receipt_hash फिल्डले प्रत्येक रसिदलाई उसको अघिल्लो रसिदसँग जोड्छ। यदि हमलावरले चेनको बीचबाट एउटा रसिद निस्कन चुपचाप हटाउँछ भने के अमान्य हुन्छ?
५. रसिद सफा प्रमाणीकरण हुन्छ भने के त्यो एजेन्टको क्रिया सही, ध्वनि, वा नीतिमार्फत अनुपालक थियो प्रमाणित गर्छ?
code_samples/18-signed-receipts.ipynb खोली सबै चार खण्डहरू पूरा गर्नुहोस्:
Stretch challenge 2: तपाईंका दुई रसीदहरूलाई SHA-256 ह्यास गरेर सँगै जोड्नुहोस् (उनीहरूको क्यानोनिकल बाइटहरू निश्चित क्रममा जोड्नुहोस्) र परिणामस्वरूप प्राप्त डाइजेस्टलाई तेस्रो रसीदमा नयाँ फिल्डको रूपमा साइन गर्ने अघि एम्बेड गर्नुहोस्। सबै तीन रसीदहरू अझै पनि राउन्ड-ट्रिप हुने पुष्टि गर्नुहोस्। तपाईंले भर्खर एक-चरण समावेशन प्रमाण बनाएका हुनुहुन्छ: तेस्रो रसीदधारीले प्रमाणित गर्न सक्छ कि पहिलो दुईहरू साइन भएको समयमा अस्तित्वमा थिए, तिनीहरूको सामग्रीहरू देखाउन आवश्यक नपरी। यो नै पैटर्न हो जुन चयनात्मक-प्रकटीकरण रसीदहरूले ठूला स्तरमा प्रयोग गर्छन् (Merkle commitments, 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 प्रयोग गरेर अनुवाद गरिएको हो। हामी सही हुन प्रयास गर्छौं, तर कृपया जानकार हुनुस् कि स्वचालित अनुवादमा त्रुटिहरू वा अशुद्धताहरू हुन सक्छन्। मूल दस्तावेज़ यसको मूल भाषामा आधिकारिक स्रोत मानिनुपर्छ। महत्वपूर्ण जानकारीका लागि व्यावसायिक मानव अनुवाद सिफारिस गरिन्छ। यस अनुवादको प्रयोगबाट उत्पन्न कुनै पनि गलत बुझाइ वा त्रुटिको लागि हामी जिम्मेवार छैनौं।