धडा व्हिडिओ पहा: क्रिप्टोग्राफिक रिसिप्टसह AI एजंट्स सुरक्षित करणे
(धडा व्हिडिओ आणि थंबनेल मायक्रोसॉफ्ट सामग्री टीमद्वारे मर्ज नंतर जोडिले जातील, धडा १४ / १५ च्या नमुन्याशी जुळवून.)
हा धडा खालील गोष्टींना आच्छादित करेल:
हा धडा पूर्ण केल्यानंतर, तुम्हाला हे कळेल कसे:
कल्पना करा, तुम्ही Contoso Travel साठी AI एजंट लागू केला आहे. हा एजंट ग्राहकांच्या विनंत्या वाचतो, फ्लाइट API कॉल करतो पर्याय शोधण्यासाठी, आणि ग्राहकांच्या वतीने आसने बुक करतो. मागील तिमाहीत एजंटने ५०,००० बुकिंग्स प्रक्रिया केल्या.
आज एक ऑडिटर येतो. तो एक सोपा प्रश्न विचारतो: “तुमचा एजंट काय करत होता ते दाखवा.”
तुम्ही तुमची लॉग फाईल्स देता. ऑडिटर पाहतो आणि कठीण प्रश्न विचारतो: “मला कसे कळेल की हे लॉग्स संपादित केलेले नाहीत?”
ही ऑडिट-ट्रेल समस्या आहे. आजच्या बहुतेक एजंट तैनातीवर अवलंबून असतात:
यापैकी कोणतेही ऑडिटरचा प्रश्न उत्तर देऊ शकत नाहीत जोपर्यंत ऑडिटर कोणावरही (तुम्ही, तुमचा क्लाउड पुरवठादार, तुमचा डेटाबेस विक्रेता) विश्वास ठेवत नसतो. अंतर्गत वापरासाठी तो विश्वास सहसा स्वीकार्य असतो. परंतु नियमनाधीन कार्यभारांसाठी (वित्त, आरोग्यसेवा, 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 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 क्षेत्रात बदल करावा लागेल (रिसिप्ट ३ ची स्वाक्षरी मोडते), किंवाजर खाजगी की हार्डवेअर की व्हॉल्टमध्ये असेल आणि तुम्ही प्रत्येक रिसिप्टसह सार्वजनिक की प्रकाशित केली, तर दोन्ही हल्ले शोधाशोध केल्याशिवाय शक्य नाहीत.
नोटबुक मध्ये दर्शवले आहे:
previous_receipt_hash खरोखरच्या मागील रिसिप्टच्या हॅशशी जुळतो की नाही ते पडताळणे.ह्यामुळे तुम्ही असा ऑडिट ट्रेल तयार करता ज्याची बाह्य ऑडिटर द्वारे स्वतः पडताळणी केली जाऊ शकते, तुमच्यावर विश्वास न ठेवता.
हा धड्याचा सर्वात महत्त्वाचा विभाग आहे. रिसिप्ट्स शक्तिशाली आहेत पण त्यांची क्षमता मर्यादित आहे.
रिसिप्ट्स तीन गोष्टी पुरपुर करतात:
रिसिप्ट्स खालील गोष्टी पुरपुर करत नाहीत:
policy_id मध्ये नमूद केलेल्या धोरणाची खरी अंमलबजावणी झाली की नाही, किंवा तपासल्यास ही क्रिया परवानगी दिली असती की नाही. रिसिप्ट काय दावा केले ते नोंदवते, काय अंमलात आणले नाही.ही सीमा दोन कारणांसाठी महत्त्वाची आहे:
एका सामान्य चुकीचा समज आहे की “आमच्याकडे रिसिप्ट्स आहेत” म्हणजे “आपण शासन करत आहोत.” तसे नाही. रिसिप्ट्स ही पाया आहेत. शासन म्हणजे वरील स्तरावर तुम्ही तयार करणारा प्रणाली.
वरचा मुद्दा ३ स्वतंत्र विभागासारखा आहे: क्रिया रिसिप्ट म्हणते “ही की या सामग्रीवर स्वाक्षरी केली,” कधीही नाही “मानवाने ही अधिकृत केली.” उच्च धोका क्रियांसाठी (परतावा, विलोपन, वायर्ड ट्रान्सफर) शासन फ्रेमवर्क्स हळूहळू तो गहाळ विधान आवश्यक ठरवतात, आणि तेच मूळतत्त्वे तुम्ही या धड्यात तयार केलेल्या पद्धतींशिवाय तयार करता येऊ शकतात.
पुढील नोटबुक 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) द्वारे सह-स्वाक्षरी मार्गमानक-प्रक्रियेत आहे.
या धड्यातील पायथन कोड जाणून घेण्यास सोपा ठेवले आहे, त्यामुळे तुम्ही प्रत्येक ओळ वाचून समजू शकता काय होत आहे. उत्पादनात, तुमच्याकडे दोन पर्याय आहेत:
थेट क्रिप्टोग्राफिक मूळतत्त्वांवर बांधा. वरील ५० ओळी अनेक वापरप्रकरणांसाठी पुरेश्या आहेत. PyNaCl (Ed25519) आणि jcs पॅकेज (कॅनॉनिकल JSON) ही चांगली देखभाल आणि तपासलेली लायब्ररी आहेत.
उत्पादन रिसिप्ट लायब्ररी वापरा. अनेक मुक्त स्रोत प्रकल्प समान नमुना अधिक वैशिष्ट्यांसह (की फिरवणे, बॅच सत्यापन, JWK सेट वितरण, धोरण इंजिनसह एकत्रीकरण) राबवतात:
draft-farley-acta-signed-receipts, सुधारणा ०२) सध्या मानक प्रक्रियेत आहे, सामायिक अनुरूपता सूईटसह (agent-governance-testvectors) ज्यावर स्वतंत्र अंमलबजावणी बाइट-ओळखीच्या कॅनॉनिकल आउटपुटसाठी क्रॉस-सत्यापन करतात.protect-mcp (npm) आणि @veritasacta/verify (npm) पॅकेजेस रिसिप्ट साइनिंग आणि ऑफलाइन सत्यापनाचा Node-आधारित अमलबजावणी करतात, कोणत्याही MCP सर्व्हरला छळ प्रतिबंधक ऑडिट ट्रेलसह वेढण्यासाठी, ज्यात होल्ड-फॉर-को-साइन फ्लो आहे जिथे एका थांबलेल्या क्रियेतून एका मान्यता रिसिप्ट सोडला जातो जो क्रिया पचनाशी बांधलेला आहे (डेस्कटॉप फ्लोमधील WebAuthn-बॅक्ड), वरच्या मानवी-प्राधिकरण नोटबुकसारखा नमुना.pip install nobulex) Ed25519 + JCS साइनिंग नमुना पायथनमध्ये LangChain आणि CrewAI एकत्रीकरणांसह पुरवते, प्रसिद्ध केलेले क्रॉस-व्हॅलिडेशन चाचणी सूईट आणि OWASP PR #2210 द्वारे दिलेले अनुपालन नकाशा समाविष्ट.स्वतःचा कोड तयार करणे आणि लायब्ररी वापरण्याचा निर्णय त्याचप्रमाणे आहे ज्याप्रमाणे स्वतःचा JWT लायब्ररी लेखन आणि तपासलेली वापरणे यातील फरक आहे: दोन्ही बरोबर आहेत; लायब्ररी वेळ वाचवते आणि ऑडिट क्षेत्र कमी करते; सुरुवातपासून पद्धत तुम्हाला प्रत्येक मूळतत्त्व समजण्यास भाग पाडते. हा धडा सुरुवातीपासून शिकवतो जेणेकरून तुम्हाला कोणताही पर्याय आधार मिळेल.
सरावसंबंधी व्यायाम करण्याआधी तुमचे ज्ञान तपासा.
१. रिसिप्ट एजंटच्या खाजगी Ed25519 कीने साइन केलेली आहे. ऑडिटरकडे फक्त सार्वजनिक की आहे. ऑडिटर रिसिप्ट ऑफलाइन पडताळू शकतो का?
२. हल्लेखोराने रिसिप्टचा policy_id क्षेत्र बदलून दावा केला की ती अधिक मोकळ्या धोरणाखाली होती. स्वाक्षरी मूळ पेलोडवर होती. पडताळणी दरम्यान काय होते?
3. पावतीमध्ये कच्च्या आर्ग्युमेंट्स आणि निकालाऐवजी tool_args_hash आणि result_hash का समाविष्ट केले आहेत?
4. previous_receipt_hash फील्ड प्रत्येक पावतीला तिच्या पूर्वीच्या पावतीशी जोडते. जर हल्लेखोराने साखळीत मधल्या कोणत्यातरी पावतीला गुपचूप हटवले, तर काय अवैध होते?
5. पावती स्वच्छपणे पडताळली गेली. हे एजंटच्या कृती योग्य, ठोस किंवा धोरणास अनुरूप असल्याचा पुरावा का आहे?
code_samples/18-signed-receipts.ipynb उघडा आणि चार विभाग पूर्ण करा:
स्ट्रेच आव्हान 1: पावती स्कीमामध्ये तुमच्या इच्छेनुसार एक अतिरिक्त फील्ड जोडा (उदाहरणार्थ, ट्रेसिंगसाठी विनंती आयडी), कॅनॉनिकल सहीकरण लॉजिकमध्ये त्याचा समावेश करा, आणि पडताळणी करताना पावती पूर्ण परत येते याची पुष्टी करा. नंतर सही केल्यानंतर फील्डमध्ये बदल करा आणि पडताळणी अयशस्वी होईल याची पुष्टी करा. यामुळे तुम्हाला समजेल की कॅनॉनिकल एनकोडिंगच्या प्रत्येक बाइटचा सहीवर काय परिणाम होतो.
स्ट्रेच आव्हान 2: तुमच्या दोन पावतींच्या कॅनॉनिकल बाइट्सना ठराविक क्रमाने एकत्र करा आणि SHA-256 हॅश तयार करा आणि परिणामी डायजेस्ट तिसऱ्या पावतीच्या नवीन फील्डमध्ये समाविष्ट करा आणि सही करा. सर्व तीन पावत्या अजूनही पूर्ण परत येतात याची पडताळणी करा. तुम्ही नुकतेच एक-चरण समावेशन पुरावा तयार केला आहे: जो कोणी तिसरी पावती ठेवतो, तो पहिल्या दोन पावती असल्याचे सिद्ध करू शकतो, त्यांची सामग्री उघड न करता. हाच नमुना निवडक-प्रकटीकरणाच्या पावती मोठ्या प्रमाणात वापरतात (Merkle कमिटमेंट्स, 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 चा वापर करून अनुवादित केला आहे. जरी आम्ही अचूकतेसाठी प्रयत्न करतो, तरी कृपया लक्षात घ्या की स्वयंचलित भाषांतरांमध्ये त्रुटी किंवा अचूकतेची कमतरता असू शकते. मूळ दस्तऐवज त्याच्या मूळ भाषेत अधिकृत स्रोत मानला पाहिजे. महत्त्वाची माहिती असल्यास, व्यावसायिक मानवी भाषांतराची शिफारस केली जाते. या भाषांतराच्या वापरामुळे उद्भवणाऱ्या कोणत्याही गैरसमज किंवा चुकीच्या अर्थलावणीसाठी आम्ही जबाबदार नाही.