سبق ویڈیو دیکھیں: کریپٹوگرافک رسیدوں کے ساتھ AI ایجنٹس کو محفوظ بنانا
(سبق ویڈیو اور تھمب نیل کو Microsoft مواد کی ٹیم مرجر کے بعد شامل کرے گی، سبق 14 / 15 کے نمونے کے مطابق)
اس سبق میں شامل ہوں گے:
اس سبق کے مکمل ہونے پر، آپ جانیں گے کہ کیسے:
فرض کریں کہ آپ نے Contoso Travel کے لیے ایک AI ایجنٹ تعینات کیا ہے۔ ایجنٹ کسٹمر کی درخواستیں پڑھتا ہے، فلائٹس API کو کال کرکے اختیارات تلاش کرتا ہے، اور کسٹمر کی طرف سے نشستیں بک کرتا ہے۔ پچھلے کوارٹر میں، ایجنٹ نے 50,000 بکنگز کیں۔
آج ایک آڈیٹر آتا ہے۔ وہ ایک سادہ سوال پوچھتا ہے: “مجھے دکھائیں کہ آپ کا ایجنٹ کیا کیا۔”
آپ اپنے لاگ فائلز دے دیتے ہیں۔ آڈیٹر انہیں دیکھتا ہے اور مشکل سوال پوچھتا ہے: “مجھے کیسے پتہ چلے کہ ان لاگز میں کوئی ترمیم نہیں ہوئی؟”
یہی آڈٹ ٹریل کا مسئلہ ہے۔ آج کل کے زیادہ تر ایجنٹ تعیناتیاں درج ذیل پر انحصار کرتی ہیں:
یہ میں سے کوئی بھی آڈیٹر کے سوال کا جواب ایسے نہیں دے سکتا کہ اسے کسی پر اعتماد کرنا نہ پڑے (آپ پر، آپ کے کلاوڈ پرووائیڈر پر، یا ڈیٹابیس وینڈر پر)۔ اندرونی استعمال کے لیے یہ اعتماد قابل قبول ہوتا ہے، لیکن منظم کاموں (فنانس، ہیلتھ کیئر، یا EU AI Act کے تابع) کے لیے نہیں۔
کریپٹوگرافک رسیدیں یہ مسئلہ حل کرتی ہیں کیونکہ ہر ایجنٹ کے عمل کی آزادانہ تصدیق ممکن ہوتی ہے۔ آڈیٹر کو آپ پر اعتماد کرنے کی ضرورت نہیں، صرف آپ کی پبلک کی اور خود رسید کی ضرورت ہے۔
رسید ایک 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 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 # آر ایف سی 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) پیکیجز رسید دستخط اور آف لائن تصدیق کے لیے نوڈ بیسڈ نفاذ فراہم کرتے ہیں، جو کسی بھی 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: اپنی پسند کا ایک اضافی فیلڈ شامل کرکے رسید اسکیمہ کو بڑھائیں (مثلاً، ٹریسنگ کے لیے درخواست ID)، canonical دستخطی منطق کو اپ ڈیٹ کریں تاکہ اس میں شامل ہو، اور تصدیق کریں کہ رسید اب بھی صحیح طور پر چیک ہوتی ہے۔ پھر دستخط کے بعد فیلڈ کو تبدیل کریں اور تصدیق ناکام ہو جائے۔ یہ آپ کو سکھاتا ہے کہ کینونیکل انکوڈنگ کے ہر بائٹ کا دستخط میں کیا کردار ہے۔ اسٹریچ چیلنج 2: اپنے دو رسیدوں کو SHA-256 سے ہیش کریں (ان کے کینونیکل بائٹس کو ایک متعین ترتیب میں جوڑیں) اور حاصل کردہ ڈائجسٹ کو کسی تیسرے رسید کے نئے فیلڈ کے طور پر ایمبیڈ کریں اس سے پہلے کہ اسے دستخط کیا جائے۔ تصدیق کریں کہ تمام تین رسیدیں اب بھی راؤنڈ ٹرپ کر سکتی ہیں۔ آپ نے ابھی ایک قدمی انکلوژن پروف بنایا ہے: جو کوئی تیسرے رسید کو رکھتا ہے وہ ثابت کر سکتا ہے کہ پہلے دو رسید دستخط کے وقت موجود تھے، بغیر ان کی محتویات ظاہر کیے۔ یہی وہ پیٹرن ہے جو سیلیکٹو-ڈسکلوژن رسیدیں بڑی سطح پر استعمال کرتی ہیں (مرکل کمیٹمنٹس، RFC 6962)۔
کریپٹوگرافک رسیدیں AI ایجنٹس کو ایک آڈٹ ٹریل دیتی ہیں جو کہ:
یہ ان پٹ ویلیڈیشن، پالیسی نفاذ، یا شناختی انفراسٹرکچر کا نعم البدل نہیں ہیں۔ یہ ان تہوں کی بنیاد ہیں۔ جب آپ ایجنٹس کو منظم کردہ کاموں، کثیر تنظیمی ورک فلو، یا کسی بھی ایسی جگہ تعینات کر رہے ہوں جہاں مستقبل کا آڈیٹر آپ پر بھروسہ کرنے کا مفروضہ نہیں رکھتا، تو رسیدیں وہ ذریعہ ہیں جس سے آپ آڈٹ ٹریل کو ایماندار بناتے ہیں۔
سب سے اہم بات یہ ہے: رسیدیں ثابت کرتی ہیں کہ کس نے کیا کہا، اور کب۔ یہ ثابت نہیں کرتیں کہ جو کہا گیا وہ درست یا صحیح تھا۔ اس فرق کو سختی سے یاد رکھیں۔ یہ ایک ایماندار ماخذ نظام اور گمراہ کن نظام میں فرق ہے۔
جب آپ اس سبق سے فارغ ہو کر رسید دستخط شدہ ایجنٹس کو حقیقی ماحول میں تعینات کرنے کے لیے تیار ہوں:
https://your-org.example.com/.well-known/agent-keys.json۔Microsoft Foundry Discord میں شامل ہوں تاکہ دوسرے سیکھنے والوں سے ملیں، آفس آورز میں شرکت کریں، اور اپنے AI ایجنٹس کے سوالات کا جواب حاصل کریں۔
یہ سبق سنگل رسید دستخط اور ہیش چینڈ سلسلے کا احاطہ کرتا ہے۔ یہ ہی پرمیٹیوز کئی زیادہ جدید پیٹرنز میں مل کر بنتے ہیں جو آپ کے گورننس سلوک کے بہتر ہونے پر آپ کو مل سکتے ہیں:
result_hash میں دیے گئے بائٹس کو سیل کرتی ہے۔ حقیقی دنیا کے مواد اکثر ایک ٹول کال کے نتیجے سے زیادہ جامع ہوتے ہیں: پیشگی فیصلہ سازی (ماڈل کی پیشن گوئی، زیر غور اختیارات، ثبوت اور اس کی مکملت، خطرات کی صورتحال، جوابدہی چین، دروازے کا نتیجہ) سب مواد میں شامل ہو سکتے ہیں، جسے ایک واحد رسید سیل کرتی ہے۔ یہ رسید کے فارمیٹ کو کم از کم رکھتا ہے جبکہ مواد کے اسکیما کو شعبہ بہ شعبہ ترقی دینے دیتا ہے۔signature.alg فیلڈ ML-DSA-65 (NIST بعدی-کوانٹم دستخط کا معیار) رکھ سکتی ہے جب آپ کو مائیگریٹ کرنا ہو۔ ایک عبوری دور کے لیے منصوبہ بندی کریں جہاں رسیدیں دوہری دستخط شدہ ہوں۔کمپیوٹر یوز ایجنٹس بنانا (CUA)
(نصاب کے منتظمین کے ذریعے طے کیا جائے گا)
ڈس کلیمر: یہ دستاویز AI ترجمہ سروس Co-op Translator کے ذریعے ترجمہ کی گئی ہے۔ جبکہ ہم درستگی کے لیے کوشاں ہیں، براہ کرم اس بات سے آگاہ رہیں کہ خودکار ترجمے میں غلطیاں یا عدم درستیاں ہو سکتی ہیں۔ اصل دستاویز اپنے مادری زبان میں مستند ماخذ سمجھی جائے گی۔ حساس معلومات کے لیے پیشہ ور انسانی ترجمہ کی سفارش کی جاتی ہے۔ اس ترجمے کے استعمال سے پیدا ہونے والی کسی بھی غلط فہمی یا غلط تشریح کی ذمہ داری ہم قبول نہیں کرتے۔