धडा व्हिडिओ पहा: क्रिप्टोग्राफिक रसीदांसह 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[तोडफोड-प्रमाणित पुरावा]
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 फील्ड प्रत्येक रसीद मागील रसीदमध्ये लिंक करते. एक रसीद काढल्यास किंवा पुनर्रचनेमुळे त्या नंतरच्या प्रत्येक रसीदीची साखळी फुगते. व्यक्तिगत स्वाक्षऱ्यांवरही छेडछाड लपवली तरी साखळी स्तरावर दिसून येते.
एकत्र या गुणधर्म तीन हमी देतात:
रसीद तयार करण्यासाठी तुम्हाला कोणतीही विशेष लायब्ररी आवश्यक नाही. क्रिप्टोग्राफिक प्राथमिक घटक प्रचंड उपलब्ध आहेत आणि लॉजिक काही दहा-पंक्तींचे पाइथनमध्ये आहे.
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 फील्ड बदलणे (रसीद 3 ची स्वाक्षरी फोडते), किंवाजर खाजगी की हार्डवेअर की वॉल्टमध्ये असेल आणि तुम्ही प्रत्येक रसीदसह सार्वजनिक की प्रकाशित करत असाल, तर कोणताही हल्ला लपवता येत नाही.
नोटबुकमध्ये खालील गोष्टी दाखविल्या आहेत:
previous_receipt_hash ची खरी मागील रसीदीच्या हॅशशी जुळणी पडताळणे.अशा प्रकारे तुम्ही असा ऑडिट ट्रेल तयार करता जो बाह्य ऑडिटर स्वायत्तपणे पडताळू शकतो.
हा धडा यातील सर्वात महत्त्वाचा भाग आहे. रसीद शक्तिशाली आहेत पण त्यांची शक्ती मर्यादित आहे.
रसीद तीन गोष्टी सिद्ध करतात:
रसीद काय सिद्ध करत नाहीत:
policy_id मधील धोरण खरोखरच मूल्यांकन झाले किंवा तपासले असते तरच परवानगी दिली गेली काय? रसीद नेमकं काय दावा केला ते नोंदवते, काय लागू केले गेले नाही.ही सीमा दोन कारणांसाठी महत्वाची आहे:
एक सामान्य समजुतीची चूक: “आपल्याकडे रसीद आहेत म्हणजे आपल्यावर शासन आहे.” खरे नाही. रसीद ही फक्त पाया आहे. शासन हा वर बांधलेला सिस्टीम आहे.
या धड्यातील पाइथन कोड जाणून घेण्यासाठी कमी आणि सुलभ ठेवले आहेत. उत्पादनात तुमच्याकडे दोन पर्याय आहेत:
क्रिप्टोग्राफिक घटक वर थेट काम करा. वरील 50 ओळी अनेक उपयोगांसाठी पुरेश्या आहेत. PyNaCl (Ed25519) आणि jcs पॅकेज (कॅनॉनिकल JSON) हे चांगल्या प्रकारे राखणी व ऑडिटेड लायब्रऱ्या आहेत.
उत्पादनासाठी रसीद लायब्ररी वापरा. अनेक मुक्त स्रोत प्रकल्प तेच नमुना अतिरिक्त वैशिष्ट्यांसह अंमलात आणतात (की रोटेशन, बॅच पडताळणी, JWK सेट वितरण, धोरण इंजिनसह एकत्रीकरण):
draft-farley-acta-signed-receipts) आहे जी सध्या मानक प्रक्रियेत आहे.protect-mcp (npm) आणि @veritasacta/verify (npm) पॅकेजेस रसीद साइनिंग व ऑफलाइन पडताळणीसाठी Node-आधारित अंमलबजावणी देतात, कोणत्याही MCP सर्व्हरवर छेडछाड-प्रतिबंधक ऑडिट ट्रेल देण्यासाठी.pip install nobulex) पाइथनमध्ये Ed25519 + JCS साइनिंग नमुना देतो, LangChain व CrewAI समाकलनांसह, प्रसिद्ध क्रॉस-व्हॅलिडेशन टेस्ट व्हेक्टर व @OWASP PR #2210 द्वारे योगदान केलेला अनुपालन मॅपिंग.स्वतः तयार करणे किंवा लायब्ररी वापरण्याचा निर्णय याला प्रत्येकी फायदा व तोटे आहेत: वेळ वाचवणारी लायब्ररी, तुमचा वेळ व क्षेत्र कमी करणारी, पण तुम्हाला प्रत्येक घटक समजावून घेण्यासाठी स्वतः कोड लिहिणे आवश्यक. हा धडा स्वतःपासून मार्ग शिकवतो जेणेकरून तुम्हाला कोणताही पर्याय सहज वापरता येईल.
सराव करण्यापूर्वी तुमचे समज तपासा.
1. एक रसीद एजंटच्या खाजगी Ed25519 कीने स्वाक्षरी केली जाते. ऑडिटरकडे फक्त सार्वजनिक की आहे. ऑडिटर रसीद ऑफलाइन पडताळू शकतो का?
2. एखाद्या हल्लेखोराने रसीदमधील policy_id फील्ड बदलून ती अधिक आरामशीर धोरणाखाली असल्याचा दावा केला. स्वाक्षरी मूळ पेलोडवर होती. पडताळणी दरम्यान काय होते?
3. tool_args_hash आणि result_hash याऐवजी थेट आर्ग्युमेंट्स आणि परिणाम न लावण्याची कारणं काय?
4. previous_receipt_hash फील्ड प्रत्येक रसीदला तिच्या मागील रसीदशी लिंक करते. जर एखाद्या हल्लेखोराने साखळीतील मधल्या रसीद एका रसीदेला गुप्तपणे काढले, तर काय अमान्य होईल?
5. एखादी रसीद स्वच्छपणे पडताळली गेली. याचा अर्थ एजंटची कृती बरोबर, योग्य वा धोरणानुसार होते असा अर्थ आहे का?
code_samples/18-signed-receipts.ipynb उघडा आणि सर्व चार विभाग पूर्ण करा:
स्टेच चॅलेंज 2: तुमच्या दोन रिसीट्सचे SHA-256 हॅश (त्यांचे कैनॉनिकल बाइट्स ठराविक क्रमाने एकत्र करून) काढा आणि साइनिंगपूर्वी तिसऱ्या रिसीटमध्ये नवीन फील्ड म्हणून त्या हॅशला समाविष्ट करा. नंतर खात्री करा की सर्व तीन रिसीट्स अजूनही व्यवस्थित राउंड-ट्रिप होतात. तुम्ही नुकतेच एकस्टेप इन्क्लूजन प्रूफ तयार केला आहे: तिसरा रिसीट ठेवणारे कोणताही व्यक्ती आपल्या प्रत्येकात समाविष्ट पहिल्या दोन रिसीट्स अस्तित्वात होत्या हे त्यांच्या सामग्री उघड न करता सिद्ध करू शकतो. हेच पॅटर्न निवडक प्रकटीकरण रिसीट्स मोठ्या प्रमाणावर वापरतात (मर्कल कमिटमेंट्स, RFC 6962).
क्रिप्टोग्राफिक रिसीट्स AI एजंट्ससाठी अशा ऑडिट ट्रेलची हमी देतात:
हे इनपुट व्हॅलिडेशन, धोरण अंमलबजावणी किंवा ओळख ढाच्याची जागा घेत नाहीत. ते या स्तरांसाठी एक पाया आहेत. जेव्हा तुम्ही एजंट्सचे नियमनशास्त्रीय कामावर, बहु-संस्था वर्कफ्लोजवर किंवा अशा सेटिंगमध्ये तैनात करता जिथे भविष्यातील ऑडिटर तुम्हावर विश्वास ठेवणे अपेक्षित नसेल, तेव्हा रिसीट्स ऑडिट ट्रेल प्रामाणिक बनवण्याचा मार्ग आहेत.
सर्वात महत्त्वाचा मुद्दा: रिसीट्स सिद्ध करतात कोण म्हणाले काय, कधी. ते सिद्ध करत नाहीत की जे म्हटले ते खरं किंवा योग्य आहे. हा फरक नीट समजा. हा प्रामाणिक प्रामाणिकता प्रणाली आणि दिशाभूल करणाऱ्या प्रणालीतील फरक आहे.
जेव्हा तुम्ही या धडा पासून पुढे जाऊन रिअल वातावरणात रिसीट-साइन केलेले एजंट्स तैनात करण्यास तयार असाल:
https://your-org.example.com/.well-known/agent-keys.json.Microsoft Foundry Discord मध्ये सामील व्हा, इतर शिकणाऱ्यांशी भेटा, ऑफिस तासांना उपस्थित राहा, आणि आपल्या AI एजंट्सच्या प्रश्नांची उत्तरे मिळवा.
हा धडा सिंगल-रिसीट साइनिंग आणि हॅश-जोडलेल्या अनुक्रमांकाचा आच्छादित करतो. हेच प्र primitव हे अनेक अधिक प्रगत पॅटर्नमध्ये आपण वापरू शकता जो तुमच्या शासनाच्या स्तराबरोबर प्रगत होतो:
authorization_*) आणि पोस्ट-एक्झिक्युशन (result_*) भागांमध्ये वेगळ्या सिग्नेचरसह विभागतात, जेव्हा अधिकृतता निर्णय आणि निरीक्षित निकाल वेगळ्या व्यक्ति/वेळेस तयार होतात तेव्हा उपयुक्त. हे या धड्याने शिकवलेल्या रिसीट फॉरमॅटवर उपसर्ग म्हणून तयार करता येते.result_hash मध्ये जे काही बाइट्स देतात त्यांची सील करते. प्रत्यक्षातील पेलोड बहुधा एका टूल कॉलच्या निकालापेक्षा अधिक समृद्ध असतात: पूर्वनिर्णय विचार (मॉडेल भाकीत, पर्याय विचारले, पुरावे आणि त्याची पूर्णता, धोका स्थिती, जबाबदारी साखळी, गेट निकाल) हे सर्व एका रिसीटद्वारे सीलबंद करता येतात. ह्यामुळे रिसीट फॉरमॅट साधा राहतो आणि डोमेननुसार पेलोड स्कीमा विकसित होऊ शकतो.signature.alg फील्ड ML-DSA-65 (NIST पोस्ट-क्वांटम सिग्नेचर मानक) या साठी नेऊ शकतो जेव्हा स्थलांतर आवश्यक असेल. रिसीट्स द्वि-साइन केलेले असतील अशी संक्रमण कालावधी नियोजन करा.कंप्युटर वापर एजंट तयार करणे (CUA)
(कॅरिक्युलम व्यवस्थापकांनी ठरवले जाणार)
अस्वीकरण: हा दस्तऐवज AI भाषांतर सेवा Co-op Translator चा वापर करून अनुवादित केला आहे. जरी आम्ही अचूकतेसाठी प्रयत्न करतो, तरी कृपया लक्षात घ्या की स्वयंचलित भाषांतरांमध्ये त्रुटी किंवा अचूकतेची कमतरता असू शकते. मूळ दस्तऐवज त्याच्या मूळ भाषेत अधिकृत स्रोत मानला पाहिजे. महत्त्वाची माहिती असल्यास, व्यावसायिक मानवी भाषांतराची शिफारस केली जाते. या भाषांतराच्या वापरामुळे उद्भवणाऱ्या कोणत्याही गैरसमज किंवा चुकीच्या अर्थलावणीसाठी आम्ही जबाबदार नाही.