पाठ वीडियो देखें: क्रिप्टोग्राफ़िक रसीदों के साथ 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 -- yes --> I[छेड़छाड़-प्रमाणित प्रमाण]
H -- no --> 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 में संदर्भित नीति का वास्तविक मूल्यांकन या जांच कि क्या वह इस क्रिया की अनुमति देती। रसीद में रिकॉर्ड किया गया है जो दावा किया गया, वह लागू किया गया नहीं।यह सीमा दो कारणों से महत्वपूर्ण है:
एक सामान्य गलती यह मान लेना है कि “हमारे पास रसीदें हैं” का अर्थ है “हम नियंत्रित हैं।” ऐसा नहीं है। रसीदें आधार हैं। शासन वह सिस्टम है जो आप इसके ऊपर बनाते हैं।
ऊपर आइटम 3 के लिए एक अलग खंड जरूरी है: एक क्रिया रसीद कहती है “इस कुंजी ने इस सामग्री पर सिग्नेचर किया,” कभी नहीं “एक मानव ने यह अधिकृत किया।” उच्च जोखिम वाली क्रियाओं (रिफंड, deletions, वायर ट्रांसफर) के लिए, शासन फ्रेमवर्क इस गुम हुआ कथन की आवश्यकता बढ़ते जा रहे हैं, और यह उसी प्रिमिटिव्स से बनाया जा सकता है जो आपने इस पाठ में बनाया है।
अगला नोटबुक code_samples/human-authorization-receipts.ipynb दूसरे प्रकार की रसीद जोड़ता है, human.approval.v1, उसी रूप में जैसे इस पाठ की रसीदें हैं (एक टाइप्ड पे-लोड जो Ed25519 से साइन होता है इसके कैनोनिकल SHA-256 के ऊपर, signature ऑब्जेक्ट साइन की गई बाइट्स के बाहर)। एक नामित अनुमोदक पूर्ण कैनोनिकल क्रिया और उसका डाइजेस्ट साइन करता है निष्पादन से पहले; एजेंट की क्रिया रसीद उसी क्रिया डाइजेस्ट और एक parent_approval_ref रखती है, जो अनुमोदन की receipt_hash है, उसी कन्वेंशन में जैसे आपने ऊपर चेन में previous_receipt_hash बनाया। एक verify_chain दोनों अभिलेखों को अलग-अलग पिन की रजिस्ट्रीज़ के तहत सत्यापित करता है (अनुमोदक कीज़ बनाम एजेंट कीज़), इसलिए कोड पथ साझा है पर अधिकार कभी नहीं।
इसका गुण, सावधानीपूर्वक कहा गया: मानव ने इस सटीक क्रिया को अनुमोदित किया, और एजेंट ने बिल्कुल उस अनुमोदित क्रिया को निष्पादित किया। नोटबुक के अस्वीकृति फिक्स्चर इसे सिद्ध करते हैं, न कि केवल दावा:
प्रत्येक असफलता अलग कारण से अस्वीकार होती है, ताकि एक ऑडीटर पढ़कर बता सके कि अधिकार पुराना हुआ या निष्पादित क्रिया बदली। नोटबुक का नियम है: एक साइन की हुई अनुमोदन स्वयं में अधिकार नहीं है। अधिकार तभी मौजूद होता है जब दोनों रसीदें निष्पादन समय पर एक ही कैनोनिकल क्रिया से जुड़ी हों। इसी पैटर्न का Internet-Draft (draft-farley-acta-signed-receipts) में सह-हस्ताक्षर मार्ग स्टैण्डर्ड ट्रैक आकार है।
इस पाठ का Python कोड स्वेच्छा से न्यूनतम है ताकि आप हर लाइन पढ़कर पूरी तरह समझ सकें कि क्या हो रहा है। उत्पादन में, आपके पास दो विकल्प हैं:
क्रिप्टोग्राफ़िक प्रिमिटिव्स पर सीधे निर्माण करें। ऊपर देखे गए 50 लाइन कई उपयोग मामलों के लिए पर्याप्त हैं। PyNaCl (Ed25519) और jcs पैकेज (कैनोनिकल JSON) अच्छे से अनुरक्षित और ऑडिटेड पुस्तकालय हैं।
एक उत्पादन रसीद पुस्तकालय का उपयोग करें। कई खुले स्रोत परियोजनाएं समान पैटर्न को अतिरिक्त सुविधाओं (की रोटेशन, बैच सत्यापन, JWK सेट वितरण, नीति इंजन एकीकरण) के साथ लागू करती हैं:
draft-farley-acta-signed-receipts, संशोधन 02) जो वर्तमान में मानकों की प्रक्रिया में है, एक साझा परिपालन सूट के साथ (agent-governance-testvectors) जिसके विरुद्ध स्वतंत्र कार्यान्वयन बाइट-तुल्य कैनोनिकल आउटपुट के लिए पार-परीक्षण करते हैं।protect-mcp (npm) और @veritasacta/verify (npm) पैकेज एक Node-आधारित रसीद साइनिंग और ऑफ़लाइन सत्यापन कार्यान्वयन प्रदान करते हैं, जो किसी भी MCP सर्वर को छेड़छाड़-प्रतिरोधी ऑडिट ट्रेल के साथ लपेटने के लिए है, जिसमें एक होल्ड-फॉर-को-साइन फ्लो शामिल है जिसमें एक रुकी हुई क्रिया कार्रवाई डाइजेस्ट से बंधा अनुमोदन रसीद जारी करती है (डेस्कटॉप फ्लो में WebAuthn समर्थित), मानव-अधिकृति नोटबुक के समान अनुमोदन-रसीद पैटर्न।pip install nobulex) उसी Ed25519 + JCS साइनिंग पैटर्न को Python में 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 खोलें और सभी चार अनुभाग पूर्ण करें:
विस्तार चुनौती 1: अपनी पसंद के एक अतिरिक्त फ़ील्ड के साथ रसीद स्कीमा का विस्तार करें (उदाहरण के लिए, ट्रेसिंग के लिए एक अनुरोध आईडी), साइनिंग लॉजिक में इसे शामिल करने के लिए सामान्यीकृत हस्ताक्षर लॉजिक अपडेट करें, और पुष्टि करें कि रसीद अभी भी सत्यापन के माध्यम से वापस आती है। फिर साइनिंग के बाद फ़ील्ड में परिवर्तन करें और पुष्टि करें कि सत्यापन विफल हो जाता है। इससे आपको यह समझना होगा कि सामान्यीकृत एन्कोडिंग का हर बाइट हस्ताक्षर में कैसे योगदान देता है।
विस्तार चुनौती 2: अपनी दो रसीदों के SHA-256 हैश को एक साथ करें (उनके सामान्यीकृत बाइट्स को निर्धारित क्रम में जोड़ें) और परिणामस्वरूप डाइजेस्ट को तीसरी रसीद पर एक नए फ़ील्ड के रूप में एम्बेड करें, फिर उसे हस्ताक्षरित करें। सुनिश्चित करें कि तीनों रसीदें अभी भी सत्यापित होती हैं। आपने अभी एक-चरण समावेशन प्रमाण बनाया है: तीसरी रसीद रखने वाला कोई भी व्यक्ति प्रमाणित कर सकता है कि पहली दो रसीदें उस समय मौजूद थीं जब इसे साइन किया गया था, बिना उनकी सामग्री का खुलासा किए। यही पैटर्न चयनात्मक-प्रकटीकरण रसीदें बड़े पैमाने पर उपयोग करती हैं (Merkle commitments, 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 पोस्ट-क्वांटम हस्ताक्षर मानक) ले सकता है जब माइग्रेशन आवश्यक हो। एक संक्रमण अवधि की योजना बनाएं जहाँ रसीदें दोहरी-साइन हों।अस्वीकरण: इस दस्तावेज़ का अनुवाद AI अनुवाद सेवा Co-op Translator का उपयोग करके किया गया है। जबकि हम सटीकता के लिए प्रयास करते हैं, कृपया ध्यान दें कि स्वचालित अनुवादों में त्रुटियाँ या अशुद्धियाँ हो सकती हैं। मूल दस्तावेज़ अपनी मूल भाषा में ही प्रामाणिक स्रोत माना जाना चाहिए। महत्वपूर्ण जानकारी के लिए, पेशेवर मानव अनुवाद की सिफारिश की जाती है। इस अनुवाद के उपयोग से उत्पन्न किसी भी गलतफहमी या गलत व्याख्या के लिए हम उत्तरदायी नहीं हैं।