पाठ वीडियो देखें: क्रिप्टोग्राफिक रसीदों के साथ 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 कैनोनिकलाइज़ेशन स्कीम (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 -. previous_receipt_hash .-> R0
R2 -. previous_receipt_hash .-> R1
R3 -. previous_receipt_hash .-> R2
प्रत्येक रसीद उससे पहले वाली रसीद के हैश को रिकॉर्ड करती है। अगर कोई हमलावर चुपचाप रसीद 2 को हटाना चाहता है, तो उसे या तो:
previous_receipt_hash फ़ील्ड को संशोधित करना होगा (जिससे रसीद 3 का हस्ताक्षर टूट जाएगा), यायदि निजी कुंजी हार्डवेयर की वॉल्ट में है और आप हर रसीद के साथ सार्वजनिक कुंजी प्रकाशित करते हैं, तो बिना पता चले कोई भी हमला संभव नहीं।
नोटबुक में दर्शाया गया है:
previous_receipt_hash पिछली रसीद के असली हैश से मेल खाते हैं।यही वह तरीका है जिससे आप एक ऑडिट ट्रेल बनाते हैं जिसे बाहरी ऑडिटर बिना आप पर भरोसा किए सत्यापित कर सकता है।
यह इस पाठ का सबसे महत्वपूर्ण भाग है। रसीदें शक्तिशाली हैं लेकिन उनकी शक्ति सीमित है।
रसीदें तीन बातें साबित करती हैं:
रसीदें यह साबित नहीं करतीं:
policy_id में संदर्भित नीति का वास्तव में मूल्यांकन किया गया, या यदि जाँचा गया तो यह क्रिया की अनुमति देती। रसीद यह रिकॉर्ड करती है कि क्या दावा किया गया, न कि क्या लागू किया गया।इस सीमा के दो कारण हैं:
एक आम गलती है यह मान लेना कि “हमारे पास रसीदें हैं” मतलब “हम नियंत्रित हैं।” ऐसा नहीं है। रसीदें एक आधार हैं। शासन वह प्रणाली है जो आप इसके ऊपर बनाते हैं।
इस पाठ में Python कोड जानबूझकर न्यूनतम है ताकि आप हर पंक्ति पढ़ सकें और यह समझ सकें कि क्या हो रहा है। उत्पादन में आपके पास दो विकल्प हैं:
क्रिप्टोग्राफिक प्रिमिटिव्स पर सीधे आधारित निर्माण करें। ऊपर दिखाए गए 50 पंक्तियाँ कई उपयोग मामलों के लिए पर्याप्त हैं। PyNaCl (Ed25519) और jcs पैकेज (कैनोनिकल JSON) अच्छी तरह से मेंटेन और ऑडिट की गई लाइब्रेरी हैं।
उत्पादन रसीद लाइब्रेरी का उपयोग करें। कई ओपन-सोर्स प्रोजेक्ट समान पैटर्न को अतिरिक्त विशेषताओं (की रोटेशन, बैच सत्यापन, JWK सेट वितरण, नीति इंजन एकीकरण) के साथ लागू करते हैं:
draft-farley-acta-signed-receipts) है जो वर्तमान में मानक प्रक्रिया में है।protect-mcp (npm) और @veritasacta/verify (npm) पैकेजेस एक नोड-आधारित रसीद साइनिंग और ऑफ़लाइन सत्यापन कार्यान्वयन प्रदान करते हैं, जो किसी भी MCP सर्वर को छेड़छाड़-प्रतिरोधी ऑडिट ट्रेल के साथ लपेटने के लिए हैं।अपनी खुद की 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 एजेंटों को ऑडिट ट्रेल देती हैं जो कि:
वे इनपुट मान्यता, नीति प्रवर्तन, या पहचान अवसंरचना के लिए विकल्प नहीं हैं। वे उन स्तरों के लिए एक नींव हैं। जब आप एजेंटों को विनियमित वर्कलोड, मल्टी-ऑर्गनाइज़ेशन वर्कफ़्लोज़, या किसी भी ऐसी सेटिंग में तैनात कर रहे हों जहाँ भविष्य के ऑडिटर की आप पर भरोसा होना अनिवार्य नहीं है, तो रसीदें वह तरीका हैं जिससे आप ऑडिट ट्रेल को ईमानदार बनाते हैं।
सबसे महत्वपूर्ण निष्कर्ष: रसीदें साबित करती हैं कि किसने क्या कहा, कब। वे यह साबित नहीं करती हैं कि जो कहा गया वह सत्य या सही था। इस अंतर को कड़ाई से पकड़ें। यह ईमानदार स्रोत प्रणाली और भ्रमित करने वाली प्रणाली के बीच का फर्क है।
जब आप इस पाठ से आगे बढ़कर रसीद-हस्ताक्षरित एजेंटों को वास्तविक वातावरण में तैनात करने के लिए तैयार हों:
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 का उपयोग करके किया गया है। जबकि हम सटीकता के लिए प्रयास करते हैं, कृपया ध्यान दें कि स्वचालित अनुवादों में त्रुटियाँ या अशुद्धियाँ हो सकती हैं। मूल दस्तावेज़ अपनी मूल भाषा में ही प्रामाणिक स्रोत माना जाना चाहिए। महत्वपूर्ण जानकारी के लिए, पेशेवर मानव अनुवाद की सिफारिश की जाती है। इस अनुवाद के उपयोग से उत्पन्न किसी भी गलतफहमी या गलत व्याख्या के लिए हम उत्तरदायी नहीं हैं।