धडा व्हिडिओ पहा: क्रिप्टोग्राफिक रिसीट्ससह AI एजंट्स सुरक्षित करणे
(धडा व्हिडिओ आणि थंबनेल Microsoft सामग्री टीमद्वारे मर्जीनंतर जोडले जातील, ज्याचा नमुना धडा 14 / 15 सारखा असेल.)
हा धडा पुढील गोष्टींवर प्रकाश टाकेल:
हा धडा पूर्ण केल्यानंतर, तुम्हाला माहित असेल कसे:
समजा तुम्ही Contoso Travel साठी AI एजंट तैनात केला आहे. एजंट ग्राहकांच्या विनंत्या वाचतो, फ्लाइट्स API कॉल करतो आणि ग्राहकाच्या वतीने सीट बुक करतो. मागील तिमाहीत, एजंटने 50,000 बुकिंग्स प्रक्रिया केली.
आज एक ऑडिटर येतो. तो एक सोपा प्रश्न विचारतो: “तुमचा एजंट काय केलाय ते दाखवा.”
तुम्ही तुमची लॉग फाइल्स दे करता. ऑडिटर त्या तपासतो आणि कठीण प्रश्न विचारतो: “मला कशी खात्री होईल की हे लॉग संपादित केलेले नाहीत?”
ही ऑडिट-ट्रेलची समस्या आहे. आजच्या बहुतेक एजंट तैनातींमध्ये अवलंबले जाते:
यापैकी कोणतेही प्रश्नाच्या उत्तरासाठी एखाद्या व्यक्तीवर (तुम्ही, तुमचा क्लाउड प्रदाता, तुमचा डेटाबेस विक्रेता) विश्वास ठेवण्याशिवाय ऑडिटरला मदत करू शकत नाही. अंतर्गत वापरासाठी ते सहसा स्वीकार्य आहे, पण नियामक कामासाठी (अर्थव्यवस्था, आरोग्यसेवा, EU AI कायद्याच्या अधीन असलेल्या कामासाठी) ते योग्य नाही.
क्रिप्टोग्राफिक पावत्या या समस्येला मर्यादित करतात ज्यामुळे स्वाक्षरी केलेले विधान स्वतंत्रपणे पडताळू शकते. लेखापरीक्षकाला तरीही स्वाक्षरी करणाऱ्या कीवर आणि विधान तयार करणाऱ्या घटकावर विश्वास ठेवण्याकरिता बाह्य कारणाची गरज असते. एम्बेड केलेली की आत्म-सुसंगतता सिद्ध करते, प्रकाशकाची ओळख किंवा अंमलबजावणीचे स्थान नाही.
रिसीट हा एक JSON ऑब्जेक्ट आहे जो एजंटने काय केले हे नोंदवतो, डिजिटल स्वाक्षरीने स्वाक्षरीत केलेला.
flowchart LR
A[Agent invokes a tool] --> B[Build receipt payload]
B --> C[Canonicalize JSON RFC 8785]
C --> E[Ed25519 sign canonical bytes]
E --> F[Receipt with signature]
F --> G[Auditor verifies offline]
G --> H{Signature valid?}
H -- yes --> I[Signed statement is intact]
H -- no --> J[Receipt rejected]
एक किमान रिसीट अशी दिसते:
{
"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 मधील व्यवहारिक सराव पूर्ण कार्यप्रवाहातून मार्गदर्शन करतात. स्रोत-नियंत्रित code_samples/18-signed-receipts.execution-receipt.json अचूक नोटबुक हॅश, Python पर्यावरण, सेल संख्या आणि नवीनतम स्वच्छ अंमलबजावणीमधील तपासण्या नोंदवते, आणि धड्याच्या जतन केलेल्या आउटपुटना बदल न करता. सारांश आवृत्ती:
import json
import hashlib
import base64
from nacl import signing
from jcs import canonicalize # RFC 8785 canonical 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()}"
# Generate or load a signing key (in production, store in a key vault)
signing_key = signing.SigningKey.generate()
verify_key = signing_key.verify_key
TRUSTED_PUBLIC_KEYS = {b64url_nopad(bytes(verify_key))} # pinned out of band by the verifier
# Build the receipt payload (no signature yet)
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,
}
# Canonicalize and sign the JCS bytes directly. PureEdDSA hashes internally.
canonical_bytes = canonicalize(payload)
signature_bytes = signing_key.sign(canonical_bytes).signature
# Attach a structured signature object.
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 CryptoError
from jcs import canonicalize
def b64url_decode(s: str) -> bytes:
padding = "=" * ((4 - len(s) % 4) % 4)
return base64.b64decode(s + padding, altchars=b"-_", validate=True)
def verify_receipt(receipt: dict, trusted_public_keys: set[str]) -> bool:
# The signature is a structured object: {"alg", "sig", "public_key"}.
if not isinstance(receipt, dict):
return False
sig_obj = receipt.get("signature")
if not isinstance(sig_obj, dict) or sig_obj.get("alg") != "EdDSA":
return False
try:
# An inline key proves only self-consistency. Trust is configured out of band.
public_key = sig_obj.get("public_key")
signature = sig_obj.get("sig")
if not isinstance(public_key, str) or not isinstance(signature, str):
return False
if public_key not in trusted_public_keys:
return False
payload = {k: v for k, v in receipt.items() if k != "signature"}
canonical_bytes = canonicalize(payload)
verify_key = signing.VerifyKey(b64url_decode(public_key))
verify_key.verify(canonical_bytes, b64url_decode(signature))
return True
except (CryptoError, TypeError, ValueError, KeyError, OverflowError):
return False
हे फंक्शन एक पावती आणि भरोसा करणाऱ्या पक्षाच्या पिन केलेल्या की संचाला घेते आणि परत करते
True फक्त तेव्हाच जर सही एखाद्या स्वीकारलेल्या कीखाली वैध असेल.
तपासणीसाठी कोणतीही नेटवर्क कॉल आवश्यक नाही, परंतु कीवरील विश्वास अद्याप बाह्य कॉन्फिगरेशन निर्णय आहे.
छेडछाड शोधण्याचे प्रात्यक्षिक पाहण्यासाठी, नोटबुक:
tool_args_hash फील्डमधील एक बाइट बदलतो.हे प्रात्यक्षिक दाखवते की रिसीट छेडछाड-प्रतिबंधक आहेत: कोणतीही थोडक्यात असलेलीही फेरफार स्वाक्षरी तोडते.
एकच स्वाक्षरी दिलेला रिसीट एका क्रियेला सुरक्षित करतो. रिसीट्सची साखळी एक अनुक्रम सुरक्षित करते.
flowchart LR
R0[Receipt 0<br/>genesis] --> R1[Receipt 1]
R1 --> R2[Receipt 2]
R2 --> R3[Receipt 3]
R1 -. previous_receipt_hash .-> R0
R2 -. previous_receipt_hash .-> R1
R3 -. previous_receipt_hash .-> R2
प्रत्येक रिसीट आधीच्या रिसीटचा हॅश रेकॉर्ड करतो. रिसीट 2 गुपचूप काढायचा असल्यास हल्लेखोरला:
previous_receipt_hash फील्डमध्ये बदल करावा लागेल (स्वाक्षरी तुटेल), किंवाजर खाजगी की संरक्षित असेल आणि तपासणारा स्वतंत्रपणे साक्षीदारांनी साक्षी दिलेल्या साखळीच्या शीर्षाला पिन करतो तर हे हल्ले शोधता येऊ शकतात. प्रत्येक पावतीच्या आत की प्रकाशित करणे पुरेसे नाही पर्याप्त: एक सही करणारा किंवा हल्लेखोर वेगळी की सादर करू शकतो, साखळीचा शेवटचा भाग पुन्हा लिहू शकतो, किंवा साखळी कापून टाकू शकतो जोपर्यंत अवलंबून असणाऱ्या पक्षाकडे बाह्य विश्वास आणि पूर्णतेचा अँकर नसेल.
नोटबुकमध्ये दाखवले आहे:
previous_receipt_hash प्रत्यक्ष हॅशशी जुळतो का ते तपासणे.हेच मार्ग आहे ज्याद्वारे तुम्ही एक ऑडिट ट्रेल तयार करता ज्याची बाह्य लेखापरीक्षक त्याच्या स्वतःच्या पिन केलेल्या जारीकर्त्याच्या की आणि चेन चेकपॉइंट्सखाली पडताळणी करू शकतो, तुमच्या बदलणाऱ्या लॉग स्टोअरवर विश्वास न ठेवता.
हा भाग या धड्याचा सर्वात महत्त्वाचा आहे. रिसीट्स शक्तिशाली आहेत पण त्यांची मर्यादा आहे.
रसीद तीन गोष्टी सिद्ध करतात:
रसीद सिद्ध करत नाहीत:
policy_id मध्ये नमूद धोरण मूल्यमापन केले का किंवा ते क्रिया अनुमती दिली असती का याची खात्री नाही. रसीद फक्त दावा केलेले नोंदवते, पालन केलेले नाही.ही मर्यादा दोन कारणाने महत्त्वाची:
एक सामान्य चूक अशी आहे की “आमच्याकडे रिसीट्स आहेत” याचा अर्थ “आम्ही नियमनाधीन आहोत” असा आहे. नाही. रिसीट्स हा पाया आहे. नियमन म्हणजे तुम्ही त्यावर तयार केलेली प्रणाली.
वरिल आयटम 3 स्वतःच्या विभागासारखा आहे: एक क्रिया पावती म्हणते “या कीने या सामग्रीवर सही केली आहे,” कधीच “एखाद्या व्यक्तीने हे मंजूर केले.” उच्च-जोखमीच्या क्रियांसाठी (परतफेडी, हटवणे, वायर ट्रान्सफर्स), वेगळ्या मंजूरकर्त्याच्या सहीने अचूक क्रियेला बंधनकारक केले जाऊ शकते. त्या कीला एखाद्या व्यक्तीशी जोडणे आणि व्यक्तीची उपस्थिती तपासणे ही वेगळी जबाबदारी राहते.
पुढील नोटबुक code_samples/human-authorization-receipts.ipynb धड्याच्या रिसीट्ससारख्या त्याच एनव्हलप आकारात दुसरा रिसीट प्रकार, human.approval.v1, जोडते (एक टाइप केलेला पेलोड ज्यावर Ed25519 ने त्याच्या canonical JCS बाइट्सवर स्वाक्षरी केली आहे, आणि signature ऑब्जेक्ट स्वाक्षरी केलेल्या बाइट्सच्या बाहेर आहे). एक अनुमोदक की पूर्ण कॅनॉनिकल क्रिया आणि तिचा डाइजेस्ट वर स्वाक्षरी करते; एक एजंट की एका दाव्यावर स्वाक्षरी करते जी समान क्रियेचा डाइजेस्ट आणि एक parent_approval_ref धारण करते, मंजुरीचे receipt_hash, आणि हीच परंपरा आहे जी previous_receipt_hash मध्ये तुम्ही वर तयार केलेल्या साखळीमध्ये आहे. एक verify_chain दोन्ही आर्टिफॅक्ट्सना वेगळ्या पिन केलेल्या की नोंदण्या (अनुमोदक की विरुद्ध एजंट की) अंतर्गत हाताळते, त्यामुळे कोड मार्ग सामायिक असला तरी अधिकार कधीच सामायिक नसतात.
हा गुणधर्म जो यातून मिळतो, काळजीपूर्वक सांगायचा तर: पिन केलेल्या मंजूरकर्ता कीने ही अचूक क्रिया स्वाक्षरी केली, आणि एजंट कीने नंतर त्याच क्रियेच्या डाइजेस्टसह एक विधान स्वाक्षरी केले. हे उपयुक्त पुरावा आहे, परंतु ते स्वतःच त्या क्रियेची अंमलबजावणी झाली याचे पुरावा नाही. करण्यासाठी अंमलबजावणी नियंत्रित करण्यासाठी, अचूक मंजुरी देखील राखून ठेवली आणि प्रत्यक्ष एक्झिक्युटर सीमारेषेवर एकदाच वापरण्यात यावी प्रत्यक्ष एक्झिक्युटर सीमा-बिंदूवर; अज्ञात प्रदात्यांच्या निकालांना अज्ञातच ठेवले पाहिजेत, अंधाधुंद पुन्हा प्रयत्न करण्याऐवजी अंधाधुंद पुन्हा प्रयत्न करणे नाही. नोटबुकचे नाकारण्याचे फिक्सचर प्राप्ती-चेन स्तराची चाचणी करतात:
प्रत्येक अपयश वेगळ्या कारणामुळे नाकारले जाते, त्यामुळे नकार वाचणारा लेखापरीक्षक ओळखू शकतो की अधिकार कालबाह्य झाले आहे की दावा केलेली क्रिया बदलली आहे. पुष्टीकरण फक्त-वाचनासाठी आणि पुनरावृत्तीयोग्य आहे: ते मंजुरीचा वापर करत नाही किंवा प्रदात्याला कॉल करत नाही. एका स्वतंत्र कार्यान्वेचकाला टिकाऊ, अण्विक पुनरावृत्ती संरक्षण आणि स्पष्ट यश, अपयश आणि अनिर्णीत परिणामांची आवश्यकता असते. मानवी-मंजुरीची पावती ही या धड्यात व्याख्यित केलेली शैक्षणिक रचना आहे, draft-farley-acta-signed-receipts द्वारे व्याख्यित केलेल्या पावतीच्या प्रकारापेक्षा वेगळी आहे.
या धड्यातील Python कोड इरादेनुसार कमी ठेवलेला आहे जेणेकरून तुम्ही प्रत्येक ओळ वाचून नेमके काय होते ते समजू शकता. उत्पादनात, तुमच्याकडे दोन पर्याय आहेत:
क्रिप्टोग्राफिक प्रिमिटिव्ह्सवर थेट बांधा. वर पाहिलेल्या 50 ओळी अनेक उपयोगांसाठी पर्याप्त आहेत. PyNaCl (Ed25519) आणि jcs पॅकेज (कॅनॉनिकल JSON) चांगल्या प्रकारे देखभाल आणि तपासलेली लायब्ररी आहेत.
उत्पादनासाठी रिसीट लायब्ररी वापरा. काही मुक्त स्रोत प्रकल्प त्याच नमुन्याने अतिरिक्त वैशिष्ट्यांसह (की रोटेशन, बॅच पडताळणी, JWK सेट वितरण, धोरण इंजिनसह समाकलन) अंमलबजावणी करतात:
draft-farley-acta-signed-receipts, आवृत्ती 02). या धड्यातील शिक्षणार्थी रिसीट ड्राफ्टच्या {payload, signature} आवरणापासून वेगळा आणि सुसंगत अंमलबजावणी म्हणून मांडलेला नाही. ड्राफ्ट सामान्य अमलासाठी सामायिक पडताळणी संच प्रसिद्ध करतो (agent-governance-testvectors).protect-mcp (npm) आणि @veritasacta/verify (npm) पॅकेजेस रिसीट स्वाक्षरी व ऑफलाइन पडताळणीचे नोड-आधारित अंमलबजावणी पुरवतात, टॅम्पर-एव्हिडेंट ऑडिट ट्रेलसह कोणतीही MCP सर्व्हर व्रॅप करण्यासाठी, त्यात थांबलेली क्रिया मंजुरी रसीत सोबत आहे (वेब ऑथन समर्थित डेस्कटॉप प्रवाह), मानवी-परवानगी नोटबुकमधील समान परवानगी-रसीत नमुना.pip install nobulex) Python मध्ये LangChain आणि CrewAI समाकलनांसह Ed25519 + JCS स्वाक्षरी नमुना पुरवतो, जसे क्रॉस-चाचणी सहाय्य हटलेले आणि OWASP PR #2210 कडून योगदान दिलेला अनुपालन नकाशा.
- EMILIA Protocol एक पूरक अचूक-कृती अंमलबजावणी थर प्रदान करते: ऑफलाइन-तपासण्यायोग्य मंजुरी पावत्या, पिन केलेले WebAuthn किंवा क्वोरम प्राधिकरण, एग्झिक्युटर सीमारेषेवर एकदाच उपभोग, आणि एक स्पष्ट अनिर्णीत-परिणाम मार्ग. त्याचे फ्रेमवर्क अॅडॉप्टर्स पावतीला बाह्य परिणाम घडल्याचा पुरावा म्हणून नव्हे तर आवश्यक पुरावा म्हणून वागवतात.स्वतःचा कोड लिहायचा की लायब्ररी वापरायची हे निर्णय तुमच्या JWT लायब्ररीच्या निवडीप्रमाणे आहेत: दोन्ही अयोग्य नाहीत; लायब्ररी वेळ वाचवते आणि ऑडिट क्षेत्र कमी करते; तयार-करण्याचा मार्ग प्रत्येक प्रिमिटिव्ह समजण्यास भाग पाडतो. हा धडा तुम्हाला तयार-करण्याचा मार्ग शिकवतो जेणेकरून तुम्हाला दोन्ही पर्यायांची कळकळीची समज मिळेल.
व्यायाम करण्यापूर्वी आपले आकलन तपासा.
1. रसीत एजंटच्या खासगी Ed25519 कीने स्वाक्षरीत आहे. ऑडिटरकडे फक्त सार्वजनिक की आहे. ऑडिटर रसीत ऑफलाइन पडताळू शकतो का?
2. हल्लेखोर रिसीटच्या policy_id फील्डमध्ये बदल करून ती अधिक परवानगी देणाऱ्या धोरणाखाली गेल्याचा दावा करतो. स्वाक्षरी मूळ पेलोडवर आहे. पडताळणीदरम्यान काय होते?
3. पावतीत कच्च्या арг्युमेंट्स आणि निकालाऐवजी tool_args_hash आणि result_hash का समाविष्ट आहेत?
4. previous_receipt_hash फील्ड प्रत्येक पावतीला त्याच्या मागील पावतीशी जोडते. जर हल्लेखोर साखळीत मधल्या एका पावतीला शांतपणे हटवित असेल, तर काय अवैध होते?
5. एखादी पावती स्वच्छपणे पडताळली गेली. याचा अर्थ एजंटच्या क्रियेचा योग्य, मजबूत किंवा धोरणाशी अनुरूप असल्याचा पुरावा मिळतो का?
code_samples/18-signed-receipts.ipynb उघडा आणि सर्व चार विभाग पूर्ण करा:
वाढीव आव्हान 1: आपल्या पसंतीचा अतिरिक्त फील्ड घेऊन पावती स्कीमा वाढवा (उदा. ट्रेसिंगसाठी विनंती आयडी), कॅनॉनिकल स्वाक्षरी लॉजिक अपडेट करा आणि खात्री करा की पावती पडताळण्यांतून फेर फिरते. नंतर सही केल्यावर फील्डमध्ये बदल करा आणि पडताळणी अयशस्वी होते हे तपासा. यामुळे कॅनॉनिकल कोडिंगमधील प्रत्येक बाइट कशी सहीमध्ये योगदान देते हे समजायला जबरदस्त मदत होते.
वाढीव आव्हान 2: दोन पावत्या SHA-256 हॅश एकत्र करा (त्यांचे कॅनॉनिकल बाइट्स अंदाजे क्रमाने जोडून) आणि या हॅशला तिसऱ्या पावतीतील नवीन फील्ड म्हणून समाविष्ट करा, नंतर सही करा. खात्री करा की त्या तीनही पावत्या फेर फिरतात. तुम्ही फक्त एक-पायरी समावेश पुरावा तयार केला आहे: तिसरी पावती जवळ ठेवणारा कोणताही पुरावा देऊ शकतो की पहिली दोन पावत्या त्या वेळी अस्तित्वात होत्या, त्यांच्या सामग्री उघड न करता. हेच नमुना मोठ्या प्रमाणावर निवडक-प्रकटीकरण पावत्यांसाठी वापरला जातो (मर्कल कमिटमेंट्स, RFC 6962).
क्रिप्टोग्राफिक पावत्या AI एजंट्सना अशा ऑडिट ट्रेलची हमी देतात की:
हे इनपुट वैधता, धोरण अंमलबजावणी, कार्यान्वाहक प्रवेश यांचे पर्याय नाहीत, परिणाम पुरावे, पूर्णतेचे नियंत्रण किंवा ओळख संरचना यांचेही नाहीत. ते त्या स्तरांसाठी एक पाया आहेत त्या स्तरांसाठी. नियमनाधीन किंवा बहु-संस्थात्मक कार्यप्रवाहांमध्ये, पावत्या विशिष्ट जारीकर्त्यांच्या विधानांना लेखापरीक्षकाच्या स्वतःच्या विश्वास संरचनेखाली स्वतंत्रपणे तपासता येण्यासारखे करतात.
सर्वात महत्त्वाची गोष्ट: पावत्या हे सिद्ध करतात की विशिष्ट कीने विशिष्ट सामग्री. सोबत वाहून नेलेला टाइमस्टँप हा साइनरचा दावा आहे जोपर्यंत तो स्वतंत्रपणे वेळेने प्रमाणित केलेला नसतो. एक पावती हे सिद्ध करत नाही की तिची सामग्री खरी होती, की एखादी क्रिया अमलात आली होती, किंवा की रेकॉर्ड संच पूर्ण आहे. त्या फरकांना घट्टपणे सांभाळा.
जेव्हा तुम्ही या धड्यापासून पदवीगतरित होऊन खऱ्या वातावरणात पावती-स्वाक्षरीकृत एजंट्स तैनात करण्यास तयार असाल:
Microsoft Foundry Discord मध्ये सामील व्हा, इतर शिकणाऱ्यांशी भेटा, कार्यालयीन तासांत सहभागी व्हा, आणि तुमचे AI एजंट्स प्रश्नांची उत्तरे मिळवा.
हा धडा एकेरी-पावती स्वाक्षरी आणि हॅश-चेन केलेल्या साखळ्यांचा आढावा घेतो. तेच प्राथमिक घटक अनेक अधिक प्रगत नमुन्यांमध्ये एकत्र येतात जे तुम्ही भेटू शकता जसे तुमचे शासकीय धोरण विकसित होते:
authorization_*) आणि नंतर (result_*) अर्ध्या भागांमध्ये विभागतात, स्वतंत्र स्वाक्षरींसह, जेव्हा अधिकृत निर्णय आणि निरीक्षित निकाल वेगवेगळ्या पक्षांनी किंवा वेगवेगळ्या वेळी तयार केले जातात तेव्हा उपयुक्त. हे या धड्यात शिकविलेल्या पावती स्वरूपावर योगायोगाने येते.result_hash मध्ये जे काही बाइट्स टाकले जातात त्यावर सही होते. प्रत्यक्ष पेलोड्स अनेकदा एका टूल कॉलच्या निकालापेक्षा अधिक समृद्ध असतात: पूर्वनिर्णय विचार (मॉडेल अंदाज, पर्याय विचारले, पुरावे आणि त्याची पूर्णता, धोका स्थिती, जबाबदारी साखळी, गेट परिणाम) सर्व एका पेलोडमध्ये राहत असू शकतात, एकाच पावतीने सही केलेले. हे पावती फॉर्मॅट कमी ठेवते परंतु डोमेननुसार पेलोड स्कीमा विकसित होऊ देते.alg लेबल स्वतःमध्ये स्थलांतर नाही: एका प्रोफाइलने ML-DSA की एन्कोडिंग, कॅनॉनिकल साइन केलेले बाइट्स, पडताळणी, रिलायिंग-पार्टी धोरण, डाउनग्रेड-प्रतिरोध आणि संक्रमणाचे अर्थ परिभाषित करणे आवश्यक आहे. सुसंगततेचे दावे करण्यापूर्वी सामायिक व्हेक्टरविरुद्ध दुहेरी-स्वाक्षरी संक्रमणाचे नियोजन आणि चाचणी करा.अस्वीकरण: हा दस्तऐवज AI भाषांतर सेवा Co-op Translator चा वापर करून अनुवादित केला आहे. जरी आम्ही अचूकतेसाठी प्रयत्न करतो, तरी कृपया लक्षात घ्या की स्वयंचलित भाषांतरांमध्ये त्रुटी किंवा अचूकतेची कमतरता असू शकते. मूळ दस्तऐवज त्याच्या मूळ भाषेत अधिकृत स्रोत मानला पाहिजे. महत्त्वाची माहिती असल्यास, व्यावसायिक मानवी भाषांतराची शिफारस केली जाते. या भाषांतराच्या वापरामुळे उद्भवणाऱ्या कोणत्याही गैरसमज किंवा चुकीच्या अर्थलावणीसाठी आम्ही जबाबदार नाही.