पाठ वीडियो देखें: क्रिप्टोग्राफिक रसीदों के साथ AI एजेंट्स की सुरक्षा
(पाठ वीडियो और थंबनेल Microsoft कंटेंट टीम द्वारा मर्ज के बाद जोड़े जाएंगे, जो पाठ 14 / 15 के पैटर्न से मेल खाते हैं।)
यह पाठ कवर करेगा:
इस पाठ को पूरा करने के बाद, आप जानेंगे कैसे:
कल्पना करें कि आपने Contoso Travel के लिए एक AI एजेंट तैनात किया है। एजेंट ग्राहक अनुरोध पढ़ता है, एक flights 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 फ़ील्ड प्रत्येक रसीद को उससे पहले वाली रसीद से जोड़ता है। एक रसीद को हटाने या पुनः क्रमित करने से उसके बाद की हर रसीद टूट जाती है। भले ही व्यक्तिगत हस्ताक्षर बायपास हों, छेड़छाड़ चेन स्तर पर दिखाई देती है।
ये गुण मिलकर तीन गारंटियां प्रदान करते हैं:
रसीद बनाने के लिए आपको किसी विशेष लाइब्रेरी की आवश्यकता नहीं है। क्रिप्टोग्राफिक प्रिमिटिव्स व्यापक रूप से उपलब्ध हैं और लॉजिक कुछ दर्जन पंक्तियों के पाइथन कोड का है।
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 में उल्लिखित नीति का वास्तव में मूल्यांकन हुआ, या कि यदि जांचा गया तो यह क्रिया अनुमति देगा। रसीद रिकॉर्ड करती है क्या दावा किया गया, न कि क्या लागू किया गया।यह सीमा महत्वपूर्ण है क्योंकि:
एक आम गलती यह मानना है कि “हमारे पास रसीदें हैं” का अर्थ है “हम नियंत्रित हैं।” ऐसा नहीं है। रसीदें एक आधार हैं। शासन वह प्रणाली है जिसे आप उपर बनाते हैं।
इस पाठ का पायथन कोड जानबूझकर न्यूनतम है ताकि आप हर पंक्ति पढ़कर ठीक से समझ सकें कि क्या हो रहा है। उत्पादन में आपके पास दो विकल्प हैं:
क्रिप्टोग्राफिक प्रिमिटिव्स पर सीधे बनाएं। ऊपर दिखाए गए 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 (लिंक) के माध्यम से अनुपालन मैपिंग शामिल है।अपना JWT लाइब्रेरी लिखने और एक परीक्षण की हुई लाइब्रेरी उपयोग करने के बीच निर्णय की तरह, अपनी खुद की लिखने और लाइब्रेरी के बीच निर्णय दो विकल्पों को दर्शाता है: दोनों उचित हैं; लाइब्रेरी समय बचाती है और ऑडिट सतह कम करती है; शुरुआत से लिखने पर हर प्रिमिटिव समझना जरूरी होता है। यह पाठ शुरुआत से पथ सिखाता है ताकि आपके पास दोनों विकल्पों के लिए आधार हो।
अभ्यास करने से पहले अपनी समझ का परीक्षण करें।
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 एजेंट्स के प्रश्नों के उत्तर पा सकें।
यह पाठ एकल रिसिप्ट साइनिंग और हैश-चेन अनुक्रमों को कवर करता है। वही प्राइमिटिव कई अधिक उन्नत पैटर्न में संयोजित होते हैं जो आपके शासन स्थिति के परिपक्व होने के साथ आप देख सकते हैं:
authorization_*) और पश्च-कार्य (result_*) आधों में बांटते हैं जो स्वतंत्र हस्ताक्षरों के साथ होते हैं, उपयोगी जब अनुमति निर्णय और परिणाम अलग-अलग अभिनेताओं या समय पर उत्पन्न होते हैं। यह इस पाठ में सिखाए गए रिसिप्ट फॉर्मेट पर संलग्न होता है।result_hash में सील करता है। वास्तविक दुनिया के पेलोड अक्सर एकल टूल कॉल से अधिक समृद्ध होते हैं: पूर्व-निर्णय तर्क (मॉडल पूर्वानुमान, विचार किए विकल्प, साक्ष्य और उसकी पूर्णता, जोखिम स्थिति, जवाबदेही श्रृंखला, गेट परिणाम) सभी पेलोड के अंदर रह सकते हैं, जिन्हें एक रिसिप्ट द्वारा सील किया जाता है। यह रिसिप्ट फॉर्मेट को न्यूनतम रखता है जबकि पेलोड स्कीमाओं को डोमेन-वार विकसित करने देता है।signature.alg फ़ील्ड में ML-DSA-65 (NIST पोस्ट-क्वांटम सिग्नेचर मानक) जब आप माइग्रेट करने की आवश्यकता हो तब कैरी किया जा सकता है। समयांतराल के लिए योजना बनाएं जहां रिसिप्ट ड्यूल-साइन किए जाते हैं।कंप्यूटर उपयोग एजेंट बनाना (CUA)
(पाठ्यक्रम के रखरखावकर्ताओं द्वारा निर्धारित किया जाएगा)
अस्वीकरण: इस दस्तावेज़ का अनुवाद AI अनुवाद सेवा Co-op Translator का उपयोग करके किया गया है। जबकि हम सटीकता के लिए प्रयास करते हैं, कृपया ध्यान दें कि स्वचालित अनुवादों में त्रुटियाँ या अशुद्धियाँ हो सकती हैं। मूल दस्तावेज़ अपनी मूल भाषा में ही प्रामाणिक स्रोत माना जाना चाहिए। महत्वपूर्ण जानकारी के लिए, पेशेवर मानव अनुवाद की सिफारिश की जाती है। इस अनुवाद के उपयोग से उत्पन्न किसी भी गलतफहमी या गलत व्याख्या के लिए हम उत्तरदायी नहीं हैं।