शिक्षण व्हिडिओ पहा: क्रिप्टोग्राफिक रिसिप्ट्ससह AI एजंट्स सुरक्षित करणे
(शिक्षण व्हिडिओ आणि थंबनेल मर्ज नंतर Microsoft कंटेंट टीमद्वारे जोडले जातील, धडा 14 / 15 च्या नमुन्यानुसार.)
हा धडा यात समाविष्ट आहे:
हा धडा पूर्ण केल्यानंतर, आपल्याला माहित असेल कसे:
कल्पना करा की आपण Contoso Travel साठी AI एजंट तैनात केला आहे. एजंट ग्राहक विनंत्या वाचतो, फ्लाइट्स API कॉल करतो पर्याय शोधण्यासाठी आणि ग्राहकाच्या वतीने आसन बुक करतो. गेल्या तिमाहीत, एजंटने 50,000 बुकिंग प्रक्रिया केली आहेत.
आज एक ऑडिटर येतो. तो एक साधा प्रश्न विचारतो: “तुमचा एजंट काय केला ते दाखवा.”
आपण आपले लॉग फाईल्स देता. ऑडिटर त्यांना पाहतो आणि कठीण प्रश्न विचारतो: “हे लॉग्स संपादित केलेले नाहीत याची मला खात्री कशी?”
ही ऑडिट-ट्रेलची समस्या आहे. आजच्या बहुतेक एजंट तैनातीवर अवलंबून आहेत:
कोणतेही हे प्रश्न उत्तरू शकत नाहीत जर ऑडिटरला कोणावर (तुमच्यावर, तुमच्या क्लाउड प्रदात्यावर, तुमच्या डाटाबेस विक्रेत्यावर) विश्वास ठेवावा लागेल. अंतर्गत वापरासाठी, हा विश्वास मान्य आहे. नियंत्रित वर्कलोडसाठी (वित्त, आरोग्यसेवा, 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[छेडछाड-प्रतEvidence पुरावा]
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 Canonicalization Scheme (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[पावती 0<br/>सुरुवात] --> R1[पावती 1]
R1 --> R2[पावती 2]
R2 --> R3[पावती 3]
R1 -. मागील_पावती_हॅश .-> R0
R2 -. मागील_पावती_हॅश .-> R1
R3 -. मागील_पावती_हॅश .-> R2
प्रत्येक रिसिप्टमध्ये आधीच्या रिसिप्टचा हॅश आहे. रिसिप्ट 2 शांतपणे काढण्यासाठी हल्लेखोरने खालीपैकी एक करावे लागेल:
previous_receipt_hash फील्ड बदलणे (रिसिप्ट 3 ची स्वाक्षरी तुटेल), किंवाजर खासगी की हार्डवेअर की वॉल्टमध्ये असेल आणि आपण प्रत्येक रिसिप्टसह सार्वजनिक की प्रकाशित करत असाल, तर कोणताही हल्ला मानवियपणे शोधण्याशिवाय शक्य नाही.
नोटबुक पुढे सांगतो:
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 उघडा आणि चार विभाग पूर्ण करा:
स्ट्रेच आव्हान 1: रिसिप्ट स्कीमामध्ये तुमच्या आवडीनुसार अतिरिक्त फील्ड जोडा (उदा. ट्रेसिंगसाठी रिक्वेस्ट ID), कॅनॉनिकल साईनिंग लॉजिक अपडेट करा व पुष्टी करा की रिसिप्ट पडताळणीसाठी योग्य प्रकारे फिरते. नंतर साईनिंगनंतर फील्ड बदलून पडताळणी अयशस्वी होत असल्याचे तपासा. यामुळे तुम्हाला कॅनॉनिकल एनकोडिंगमधील प्रत्येक बाइटची स्वाक्षरीत कशी भूमिका आहे हे समजेल. स्ट्रेच चॅलेंज 2: आपल्या दोन पावत्या SHA-256-हॅश करून त्यांना एकत्र करा (त्यांचे कॅनॉनिकल बाइट्स नियत क्रमाने concatenating करा) आणि प्राप्त झालेला डाइजेस्ट तिसर्या पावतीवर नवीन फील्ड म्हणून एम्बेड करा आणि नंतर त्यावर स्वाक्षरी करा. सर्व तीन पावत्या अद्याप round-trip होतात का ते तपासा. आपण नुकत्याच एक-चरणाचा समावेश पुरावा तयार केला आहे: तिसरी पावत धरणारा कोणीही प्रथम दोन पावत्या त्यावर स्वाक्षरी केल्याच्या वेळी अस्तित्वात होत्या हे पुरावा देऊ शकतो, त्यांची सामग्री उघड न करता. हा तो नमुना आहे जो selective-disclosure पावत्या मोठ्या प्रमाणावर वापरतात (Merkle commitments, RFC 6962).
क्रिप्टोग्राफिक पावत्या AI एजंट्सना एक ऑडिट ट्रेल देतात जो:
हे इनपुट वैधता, धोरण अंमलबजावणी, किंवा ओळख यंत्रणेसाठी पर्याय नाहीत. ते त्या स्तरांसाठी पाया आहेत. जेव्हा आपण रेग्युलेटेड वर्कलोड्समध्ये, मल्टी-ऑर्गनायझेशन वर्कफ्लोजमध्ये किंवा अशा कोणत्याही पर्यावरणात एजंट्स तैनात करत आहात जिथे भविष्यातील ऑडिटर आपल्यावर विश्वास ठेवेलच असे नाही, तेव्हा पावत्या आपला ऑडिट ट्रेल प्रामाणिक करण्याचा मार्ग असतात.
सर्वात महत्त्वाचा मुद्दा: पावत्या सिद्ध करतात कोण काय म्हणाला, कधी. त्या सिद्ध करत नाहीत की जे म्हटले ते खरे किंवा बरोबर होते. त्या फरकाला घट्ट पकडा. हे प्रामाणिक मूळ प्रणाली आणि दिशाभूल करणारी प्रणाली यामधील फरक आहे.
जेव्हा आपण हा धडा पूर्ण करून वास्तविक वातावरणात receipt-signed एजंट्स तैनात करण्यासाठी तयार असाल:
https://your-org.example.com/.well-known/agent-keys.json.Microsoft Foundry Discord मध्ये सामील व्हा, इतर शिकणाऱ्यांशी भेटा, ऑफिस आवर्सला उपस्थित राहा आणि आपल्या AI एजंट्ससंबंधी प्रश्नांचे निराकरण करा.
हा धडा एकल पावतीवर स्वाक्षरी आणि हॅश-शृंखलाबद्ध अनुक्रमांचे वर्णन करतो. तेच primitives अनेक प्रगत नमुन्यांमध्ये वापरले जातात जे आपले शासन धोरण पूरक होण्यास मदत करतात:
authorization_*) आणि अंमलबजावणीनंतर (result_*) अर्ध्या भागांत विभाजित केला जातो, स्वतंत्र स्वाक्षऱ्यांसह; जेव्हा अधिकृत निर्णय आणि निरीक्षित परिणाम वेगळ्या कार्यकर्त्यांनी किंवा वेगवेगळ्या वेळी निर्मिती केले जातात तेव्हा उपयुक्त. हा पद्धत या धड्यात शिकवलेल्या पावती फॉरमॅटवर अतिरिक्तपणे बनतो.result_hash मध्ये टाकता ते पावती तळाशी सील करते. वास्तविक वापरातील पेलोड सामान्यतः एका साध्या टूल कॉल निष्कर्षापेक्षा जास्त समृद्ध असतात: निर्णय आधीचे विचार (मॉडेल पूर्वकल्पना, विचारलेले पर्याय, पुरावे आणि त्यांची संपूर्णता, जोखीम स्थिती, उत्तरदायित्व साखळी, गेट परिणाम) सर्व पेलोडमध्ये असू शकतात, जे एका पावतीने सील केलेले असते. हे पावती फॉरमॅटला कमीतकमी ठेवते आणि पेलोड स्कीमा क्षेत्रानुसार विकसित होऊ देते.signature.alg फील्डमध्ये ML-DSA-65 (NIST पोस्ट-क्वांटम स्वाक्षरी मानक) धारण करू शकते, जेव्हा स्थलांतरण आवश्यक असते. दोनही पद्धतीने साईन केलेल्या पावत्या असलेल्या संक्रमण काळासाठी योजना करा.कंप्यूटर वापर एजंट्स तयार करणे (CUA)
(शिक्षण विभागाद्वारे ठरविले जाणार आहे)
अस्वीकरण: हा दस्तऐवज AI भाषांतर सेवा Co-op Translator चा वापर करून अनुवादित केला आहे. जरी आम्ही अचूकतेसाठी प्रयत्न करतो, तरी कृपया लक्षात घ्या की स्वयंचलित भाषांतरांमध्ये त्रुटी किंवा अचूकतेची कमतरता असू शकते. मूळ दस्तऐवज त्याच्या मूळ भाषेत अधिकृत स्रोत मानला पाहिजे. महत्त्वाची माहिती असल्यास, व्यावसायिक मानवी भाषांतराची शिफारस केली जाते. या भाषांतराच्या वापरामुळे उद्भवणाऱ्या कोणत्याही गैरसमज किंवा चुकीच्या अर्थलावणीसाठी आम्ही जबाबदार नाही.