ai-agents-for-beginners

سبق کا ویڈیو دیکھیں: کرپٹوگرافک رسیدات کے ساتھ AI ایجنٹس کی حفاظت

(سبق کا ویڈیو اور تھمب نیل مائیکروسافٹ مواد ٹیم کے ذریعہ مرج کے بعد شامل کیا جائے گا ، سبق 14 / 15 کے نمونہ سے میل کھاتے ہوئے.)

کرپٹوگرافک رسیدات کے ساتھ AI ایجنٹس کی حفاظت

تعارف

یہ سبق درج ذیل موضوعات کا احاطہ کرے گا:

سیکھنے کے مقاصد

اس سبق کو مکمل کرنے کے بعد، آپ جان لیں گے کہ کیسے:

مسئلہ: آپ کے ایجنٹ کا آڈٹ ٹریل

تصور کریں کہ آپ نے 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..."
  }
}

تین خصوصیات کام کر رہی ہیں:

  1. دستخط۔ رسید ایجنٹ کے گیٹ وے کے ذریعہ Ed25519 پرائیویٹ کی سے دستخط کی جاتی ہے۔ جو کوئی بھی متعلقہ پبلک کی رکھتا ہے، وہ دستخط کو آف لائن تصدیق کر سکتا ہے۔ کسی بھی فیلڈ میں چھیڑ چھاڑ دستخط کو غلط بنا دیتی ہے۔

  2. کینونیکل انکوڈنگ۔ دستخط کرنے سے پہلے، رسید JSON کینونیکلائزیشن اسکیم (JCS, RFC 8785) سے سیریلائز کی جاتی ہے۔ یہ اس بات کو یقینی بناتا ہے کہ دو مختلف عمل درآمدات جو ایک ہی منطقی رسید تیار کرتے ہیں بائٹ کی سطح پر بالکل ایک جیسے آؤٹ پٹ دیتے ہیں۔ بغیر کینونیکلائزیشن کے مختلف JSON سیریلائزرز مختلف دستخط بنائیں گے۔

  3. ہیش چیننگ۔ previous_receipt_hash فیلڈ ہر رسید کو اس سے پہلے والی رسید سے مربوط کرتا ہے۔ ایک رسید کو ہٹانے یا دوبارہ ترتیب دینے سے اس کے بعد کی ہر رسید ٹوٹ جاتی ہے۔ چھیڑ چھاڑ چین کی سطح پر نظر آ جاتی ہے چاہے انفرادی دستخطوں کو نظر انداز کیا جائے۔

یہ خصوصیات مل کر تین ضمانتیں فراہم کرتی ہیں:

Python میں رسید تیار کرنا

رسید بنانے کے لیے آپ کو کوئی خاص لائبریری درکار نہیں۔ کرپٹوگرافک بنیادیات وسیع پیمانے پر دستیاب ہیں اور منطق چند دہائیاں Python کی لائنیں ہیں۔

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۔ کوئی نیٹ ورک کال نہیں، کوئی سروس انحصار نہیں، کسی تیسرے فریق پر اعتماد کی ضرورت نہیں۔

چھیڑ چھاڑ کی شناخت کی مشق دیکھنے کے لیے، نوٹ بک ان کاموں کی وضاحت کرتی ہے:

  1. ایک درست رسید تیار کرنا اور اس کی تصدیق کی تصدیق کرنا۔
  2. tool_args_hash فیلڈ کے ایک بائٹ میں ترمیم کرنا۔
  3. دوبارہ تصدیق چلانا اور ناکامی دیکھنا۔

یہ عملی مظاہرہ ہے کہ رسیدات چھیڑ چھاڑ کا پتہ دیتی ہیں: کوئی بھی چھوٹا سا ترمیم دستخط کو توڑ دیتی ہے۔

متعدد مراحل والے ایجنٹس کے لیے رسیدات کی چیننگ

ایک واحد دستخط شدہ رسید ایک عمل کی حفاظت کرتی ہے۔ رسیدات کی ایک چین ایک سلسلہ کی حفاظت کرتی ہے۔

flowchart LR
    R0[رسید ۰<br/>ابتدائی] --> R1[رسید ۱]
    R1 --> R2[رسید ۲]
    R2 --> R3[رسید ۳]
    R1 -. previous_receipt_hash .-> R0
    R2 -. previous_receipt_hash .-> R1
    R3 -. previous_receipt_hash .-> R2

ہر رسید اس سے پہلے کی رسید کا ہیش ریکارڈ کرتی ہے۔ رسید 2 کو خاموشی سے ہٹانے کے لیے، حملہ آور کو یا تو:

اگر پرائیویٹ کی ہارڈویئر کی والٹ میں محفوظ ہو اور آپ ہر رسید کے ساتھ پبلک کی شائع کریں، تو دونوں حملے بغیر پتہ لگائے ممکن نہیں۔

نوٹ بک درج ذیل مراحل دکھاتی ہے:

  1. تین رسیدات کی چین بنانا۔
  2. تصدیق کرنا کہ ہر رسید کا previous_receipt_hash پچھلی رسید کے حقیقی ہیش سے میل کھاتا ہے۔
  3. درمیان میں ایک رسید کے ساتھ چھیڑ چھاڑ کرنا اور دیکھنا کہ چین اسی مقام پر ٹوٹ جاتی ہے۔

یہ ہے وہ آڈٹ ٹریل جو ایک بیرونی آڈیٹر بغیر آپ پر اعتماد کیے تصدیق کر سکتا ہے۔

رسیدات کیا ثابت کرتی ہیں (اور کیا نہیں)

یہ سبق کا سب سے اہم حصہ ہے۔ رسیدات طاقتور ہیں لیکن ان کی طاقت محدود ہے۔

رسیدات تین چیزیں ثابت کرتی ہیں:

  1. منسوبیت: ایک مخصوص کی نے ایک مخصوص پے لوڈ پر دستخط کیے۔
  2. سالِمیت: پے لوڈ دستخط کے بعد سے تبدیل نہیں ہوا۔
  3. ترتیب: یہ رسید ہیش چین میں اس رسید کے بعد آیا۔

رسیدات یہ ثابت نہیں کرتیں:

  1. درستی: کہ ایجنٹ کا عمل درست عمل تھا۔ رسید غلط جواب کے لیے آسانی سے دستخط کی جا سکتی ہے جیساکہ درست جواب کے لیے یہ کی گئی ہو۔
  2. پالیسی کی پابندی: کہ policy_id میں حوالہ دی گئی پالیسی کی واقعی جانچ ہوئی، یا اگر جانچی گئی تو اس نے اس عمل کی اجازت دی ہوتی۔ رسید صرف دعویٰ کو ریکارڈ کرتی ہے، نفاذ کو نہیں۔
  3. کی سے آگے شناخت: رسید کہتی ہے “یہ کی نے اس مواد پر دستخط کیا۔” یہ نہیں کہتی “یہ انسان نے اجازت دی۔” کی کو انسان یا ادارے سے منسلک کرنے کے لیے علیحدہ شناختی ڈھانچے کی ضرورت ہوتی ہے (جیسے ڈائریکٹری، پبلک کی رجسٹری وغیرہ)۔
  4. ان پٹ کی صداقت: اگر ایجنٹ کو ترمیم شدہ پرامپٹ موصول ہوتا ہے اور اس پر عمل کرتا ہے، رسید عمل کو صحیح طریقے سے ریکارڈ کرتی ہے۔ رسیدات ان پٹ کی تصدیق کی جگہ نہیں بلکہ اس کے بعد کا مرحلہ ہیں۔

یہ حد بندی دو وجوہات کی وجہ سے اہم ہے:

ایک عام غلطی یہ سمجھنا ہے کہ “ہمارے پاس رسیدات ہیں” مطلب “ہم حکومت یافتہ ہیں”۔ ایسا نہیں ہے۔ رسیدات بنیاد ہیں۔ حکومت وہ نظام ہے جو آپ اس بنیاد پر بناتے ہیں۔

یہ ثابت کرنا کہ انسان نے بالکل وہی عمل منظور کیا

اوپر کا آئٹم 3 اپنی جگہ کے قابل ہے: ایک عمل کی رسید کہتی ہے “یہ کی نے اس مواد پر دستخط کیا”، کبھی نہیں کہتی “ایک انسان نے اس کی اجازت دی۔” اعلیٰ خطرے والے عمل (رقم کی واپسی، حذف، وائر ٹرانسفر) کے لیے، حکومت کے فریم ورک خاص طور پر وہی گمشدہ بیان چاہتے ہیں، اور اسے آپ نے اس سبق کے وہی بنیادیات استعمال کر کے تیار کیا جا سکتا ہے۔

اس سے متعلقہ نوٹ بک code_samples/human-authorization-receipts.ipynb ایک دوسرا رسیدی قسم، human.approval.v1 شامل کرتی ہے، جو سبق کی رسیدوں کی طرح چھپے ہوئے شکل میں ہے (ایک ٹائپڈ پے لوڈ جو Ed25519 سے اس کے canonical SHA-256 پر دستخط شدہ ہے، اور دستخط کا آبجیکٹ دستخط شدہ بائٹس کے باہر ہے)۔ ایک نامزد منظوری دہندہ دستخط کرتا ہے پورے کینونیکل عمل اور اس کے ہیش پر عمل درآمد سے پہلے؛ ایجنٹ کی عمل کی رسید میں وہی عمل کا ہیش اور parent_approval_ref، منظوری کی receipt_hash ہوتی ہے، جس کا کنونشن چین میں previous_receipt_hash جیسا ہے۔ ایک verify_chain دونوں دستاویزات کو الگ الگ key رجسٹریز (منظور کرنے والے کیز بمقابلہ ایجنٹ کیز) کے تحت چلاتا ہے، تو کوڈ راستہ مشترک ہے لیکن اختیاریں کبھی نہیں۔

یہ پراپرٹی، غور سے بیان کی گئی: انسان نے بالکل یہ عمل منظور کیا، اور ایجنٹ نے وہی منظور شدہ عمل انجام دیا۔ نوٹ بک کی انکار کی مثالیں اس پراپرٹی کو حقیقت بناتی ہیں نہ کہ صرف دعویٰ:

ہر ناکامی ایک مخصوص وجہ کے ساتھ انکار کرتی ہے، تو ایک آڈیٹر انکار پڑھ کر بتا سکتا ہے کہ آیا اختیار پرانی ہو گئی یا انجام دیا گیا عمل بدل گیا۔ نوٹ بک کا اصول یہ سکھاتا ہے: ایک دستخط شدہ منظوری خود اختیار نہیں ہے۔ اختیار تب ہوتی ہے جب دونوں رسیدات اسی کینونیکل عمل سے عمل درآمد کے وقت بندھی ہوں۔ اسی سبق کے Internet-Draft (draft-farley-acta-signed-receipts) میں کو-دستخطی راستہ اس طرز کا معیار ہے۔

پیداواری حوالہ جات

اس سبق کے Python کوڈ کو جان بوجھ کر کم سے کم رکھا گیا ہے تاکہ آپ ہر لائن پڑھیں اور بالکل سمجھیں کہ کیا ہو رہا ہے۔ پیداواری استعمال میں، آپ کے پاس دو اختیارات ہیں:

  1. براہ راست کرپٹوگرافک بنیادیات پر تعمیر کریں۔ اوپر دیکھی گئی 50 لائنیں بہت سے استعمال کے لیے کافی ہیں۔ PyNaCl (Ed25519) اور jcs پیکیج (کینونیکل JSON) اچھی طرح سے دیکھ بھال شدہ اور آڈٹ کی گئی لائبریریاں ہیں۔

  2. پیداواری رسید لائبریری استعمال کریں۔ کئی اوپن سورس پروجیکٹس اسی طرز کو اضافی خصوصیات کے ساتھ نافذ کرتے ہیں (کی گھماؤ، بیچ تصدیق، JWK سیٹ کی تقسیم، پالیسی انجنز کے ساتھ انضمام):

    • اس سبق میں استعمال ہونے والا رسید فارمیٹ ایک IETF انٹرنیٹ-ڈرافٹ (draft-farley-acta-signed-receipts, ریویژن 02) ہے جو فی الحال معیاراتی عمل میں ہے، ایک مشترکہ تعمیل مجموعہ (agent-governance-testvectors) کے ساتھ جس کے خلاف آزاد عمل درآمدات بائٹ کی سطح پر یکساں کینونیکل آؤٹ پٹ کی تصدیق کرتی ہیں۔
    • مائیکروسافٹ ایجنٹ گورننس ٹول کٹ رسیدات کو Cedar-بنیاد پالیسی فیصلوں کے ساتھ کمپوز کرتی ہے؛ اس ذخیرے میں ٹیوٹوریل 33 میں ایک مکمل مثال دیکھیے۔
    • protect-mcp (npm) اور @veritasacta/verify (npm) پیکیجز Node پر مبنی رسید دستخط اور آف لائن تصدیق کی عمل درآمد فراہم کرتے ہیں، جس کا مقصد کسی بھی MCP سرور کو چھیڑ چھاڑ سے بچانے والا آڈٹ ٹریل دینا ہے، جس میں ایک روک کر دستخط والا طریقہ شامل ہے جس میں ایک معطل عمل ایک منظوری رسید جاری کرتا ہے جو عمل کے ہیش سے بندھی ہوتی ہے (ڈیسک ٹاپ فلو میں WebAuthn کی حمایت کے ساتھ)، وہی منظوری-رسید کا نمونہ جو انسانی اجازت دہندگی نوٹ بک میں ہے۔
    • nobulex Python SDK (pip install nobulex) Python میں Ed25519 + JCS دستخط کے نمونے کو LangChain اور CrewAI انضمامات کے ساتھ فراہم کرتا ہے، جس میں شائع شدہ کراس-ویلڈیٹیشن ٹیسٹ ویکٹرز اور AWASP PR #2210 کے ذریعے فراہم کردہ تعمیل میپنگ شامل ہے۔

اپنا لائبریری بنانے اور استعمال کرنے کے درمیان فیصلہ JWT لائبریری لکھنے اور ٹیسٹ شدہ لائبریری استعمال کرنے کے فیصلے سے مماثل ہے: دونوں مناسب ہیں؛ لائبریری وقت بچاتی ہے اور آڈٹ سرفیس کم کرتی ہے؛ شروع سے بنانا آپ کو ہر بنیادی چیز سمجھنے پر مجبور کرتا ہے۔ یہ سبق آپ کو شروع سے سکھاتا ہے تاکہ آپ دونوں انتخاب کے لیے بنیاد رکھ سکیں۔

علم کی جانچ

عملی مشق پر جانے سے پہلے اپنی سمجھ کا امتحان لیں۔

1. رسید ایجنٹ کی پرائیویٹ Ed25519 کلید سے دستخط کی جاتی ہے۔ آڈیٹر کے پاس صرف پبلک کلید ہے۔ کیا آڈیٹر رسید کو آف لائن تصدیق کر سکتا ہے؟

جواب جی ہاں۔ Ed25519 کی تصدیق کے لیے صرف پبلک کی اور دستخط شدہ بائٹس کی ضرورت ہوتی ہے۔ کوئی نیٹ ورک کال نہیں، کوئی سروس انحصار نہیں۔ یہ وہ خصوصیت ہے جو رسیدات کو ایئر گیپڈ، کثیر تنظیمی، یا کم اعتماد والے آڈٹ میں مفید بناتی ہے۔

2. ایک حملہ آور نے رسید کے policy_id فیلڈ میں ترمیم کی تاکہ دعویٰ کرے کہ اسے زیادہ نرم پالیسی کے تحت حکمرانی حاصل تھی۔ دستخط اصل پے لوڈ پر تھا۔ تصدیق کے دوران کیا ہوتا ہے؟

جواب تصدیق ناکام ہو گئی۔ دستخط اصل پیلوڈ کے کینونیکل بائٹس پر مبنی تھا۔ کسی بھی فیلڈ میں ترمیم کرنے سے کینونیکل بائٹس تبدیل ہو جاتی ہیں، جو SHA-256 ہیش کو تبدیل کرتی ہے، اور دستخط غلط ہو جاتا ہے۔ حملہ آور کو ایک نیا درست دستخط بنانے کے لیے پرائیویٹ کلید کی ضرورت ہوگی، جو ان کے پاس نہیں ہے۔

3. رسید میں خام دلائل اور نتائج کی جگہ tool_args_hash اور result_hash کیوں شامل ہیں؟

جواب دو وجوہات ہیں۔ پہلی، رسید کو ایسے ماحول میں محفوظ یا منتقل کیا جا سکتا ہے جہاں خام مواد (PII، کاروباری ڈیٹا) کا افشاء مسئلہ ہو۔ ہیشنگ رسید کو چھوٹا اور مواد کو نجی رکھتی ہے؛ آڈیٹر اس بات کی تصدیق کرتا ہے کہ ہیش اصل مواد کی علیحدہ محفوظ شدہ کاپی سے میل کھاتی ہے۔ دوسری، ہیشز کی ایک مقررہ جسامت ہوتی ہے؛ ہیشز والی رسید کی جسامت ان پٹ اور آؤٹ پٹ کے سائز سے قطع نظر محدود ہوتی ہے۔

4. previous_receipt_hash فیلڈ ہر رسید کو اس کے پیش رو سے جوڑتا ہے۔ اگر حملہ آور چین کے وسط سے ایک رسید کو خاموشی سے حذف کرے تو کیا غلط ہو جاتا ہے؟

جواب ہر رسید جو حذف کی گئی رسید کے بعد آئی۔ ان کے `previous_receipt_hash` فیلڈز اصل چین سے میل نہیں کھاتے (کیونکہ جس رسید کا وہ حوالہ دے رہے تھے وہ اب موجود نہیں ہے، یا چین اب کسی مختلف پیش رو کی طرف اشارہ کرتا ہے)۔ حذف کو چھپانے کے لیے، حملہ آور کو ہر بعد کی رسید کو دوبارہ دستخط کرنا ہوگا، جس کے لیے پرائیویٹ کی کی ضرورت ہوتی ہے۔

5. ایک رسید صاف ستھری تصدیق کرتی ہے۔ کیا اس سے یہ ثابت ہوتا ہے کہ ایجنٹ کی کارروائی درست، معقول، یا پالیسی کے مطابق تھی؟

جواب نہیں۔ ایک درست رسید تین باتیں ثابت کرتی ہے: نسبت (یہ کلید اس مواد پر دستخط کرتی ہے)، سالمیت (مواد تبدیل نہیں ہوا)، اور ترتیب (یہ رسید اس رسید کے بعد آئی ہے)۔ یہ ثابت نہیں کرتی کہ کارروائی درست تھی، کہ `policy_id` میں نامزد پالیسی کا درحقیقت جائزہ لیا گیا، یا ایجنٹ نے ہر قاعدہ کی پیروی کی۔ رسیدیں ایجنٹ کے رویے کی آڈٹ کرنے کے قابل بناتی ہیں، درست ہونے کی ضمانت نہیں۔ یہ سبق کی سب سے اہم حد بندی ہے۔

مشق کی مشق

code_samples/18-signed-receipts.ipynb کھولیں اور چاروں سیکشن مکمل کریں:

  1. سیکشن 1: اپنی پہلی رسید پر دستخط کریں اور اس کی تصدیق کریں۔
  2. سیکشن 2: رسید میں چھیڑ چھاڑ کریں اور تصدیق ناکام ہونے کا مشاہدہ کریں۔
  3. سیکشن 3: تین رسیدوں کی چین بنائیں اور چین کی سالمیت کی تصدیق کریں۔
  4. سیکشن 4: مائیکروسافٹ ایجنٹ فریم ورک کے ساتھ بنے ایجنٹ پر یہ پیٹرن نافذ کریں: ٹول کال کو رسید دستخطی میں لپیٹیں، پھر رسید کو آزادانہ طور پر تصدیق کریں۔

اسٹریچ چیلنج 1: رسید اسکیمہ میں اپنی پسند کا ایک اضافی فیلڈ شامل کریں (مثلاً، ٹریسنگ کے لیے درخواست ID)، کینونیکل دستخطی منطق کو اسے شامل کرنے کے لیے اپ ڈیٹ کریں، اور تصدیق کریں کہ رسید اب بھی مکمل طور پر کام کرتی ہے۔ پھر دستخط کے بعد فیلڈ کو تبدیل کریں اور تصدیق ناکام ہونے کی تصدیق کریں۔ یہ آپ کو یہ سمجھنے پر مجبور کرتا ہے کہ کینونیکل اینکوڈنگ کے ہر بائٹ کا دستخط پر کیا اثر ہوتا ہے۔

اسٹریچ چیلنج 2: اپنی دو رسیدوں کو SHA-256 ہیش کے ذریعہ اکٹھا کریں (ان کے کینونیکل بائٹس کو ایک تعین شدہ ترتیب میں جوڑیں) اور حاصل ہونے والا ہیش تیسری رسید کے نئے فیلڈ کے طور پر ڈالیں، پھر اس پر دستخط کریں۔ تصدیق کریں کہ تینوں رسیدیں اب بھی مکمل طور پر کام کر رہی ہیں۔ آپ نے ایک مرحلہ انضمام کا ثبوت بنایا ہے: جو کوئی بھی تیسری رسید رکھتا ہے وہ ثابت کر سکتا ہے کہ پہلی دو رسیدیں اس وقت موجود تھیں جب اس پر دستخط ہوئے تھے، بغیر ان کے مواد ظاہر کیے۔ یہ وہ پیٹرن ہے جو بڑے پیمانے پر منتخب انکشاف رسیدیں استعمال کرتی ہیں (مرکل تعہدات، RFC 6962)۔

اختتام

کرپٹوگرافک رسیدیں AI ایجنٹس کو ایک آڈٹ ٹریل دیتی ہیں جو کہ:

یہ انپٹ کی تصدیق، پالیسی نفاذ، یا شناخت کے ڈھانچے کا متبادل نہیں ہیں بلکہ ان تہوں کی بنیاد ہیں۔ جب آپ ایجنٹس کو ریگولیٹڈ ورک لوڈز، کثیر تنظیمی ورک فلو، یا کسی بھی ایسی جگہ پر تعینات کر رہے ہوں جہاں مستقبل کا آڈیٹر آپ پر قابل اعتماد ہونے کا مفروضہ نہیں کر سکتا، رسیدیں وہ طریقہ ہیں جن سے آپ آڈٹ ٹریل کو ایماندار بناتے ہیں۔

سب سے اہم بات: رسیدیں ثابت کرتی ہیں کہ کس نے کیا کہا اور کب۔ یہ ثابت نہیں کرتیں کہ جو کہا گیا وہ سچ یا درست تھا۔ اس امتیاز کو مضبوطی سے تھامے رکھیں۔ یہ ایماندار Herkunft نظام اور گمراہ کن نظام کے درمیان فرق ہے۔

پیداوار چیک لسٹ

جب آپ اس سبق سے فارغ ہو کر حقیقی ماحول میں رسید دستخط شدہ ایجنٹس کو تعینات کرنے کے لیے تیار ہوں:

AI ایجنٹس کی حفاظت کے بارے میں مزید سوالات ہیں؟

Microsoft Foundry Discord میں شامل ہوں تاکہ دوسرے سیکھنے والوں سے ملاقات کریں، دفتر کے اوقات میں شرکت کریں اور اپنے AI ایجنٹس کے سوالات پوچھیں۔

اس سبق سے آگے

یہ سبق سنگل رسید دستخط اور ہیش چینڈ سلسلے کو کور کرتا ہے۔ وہی اصول کئی مزید پیچیدہ پیٹرنز میں شامل ہوتے ہیں جن سے آپ کا گورننس کا طریقہ کار جب نکھرتا ہے تو آپ کو ملیں گے:

اضافی وسائل

پچھلا سبق

مقامی AI ایجنٹس کی تخلیق

ڈس کلیمر: یہ دستاویز AI ترجمہ سروس Co-op Translator کے ذریعے ترجمہ کی گئی ہے۔ جبکہ ہم درستگی کے لیے کوشاں ہیں، براہ کرم اس بات سے آگاہ رہیں کہ خودکار ترجمے میں غلطیاں یا عدم درستیاں ہو سکتی ہیں۔ اصل دستاویز اپنے مادری زبان میں مستند ماخذ سمجھی جائے گی۔ حساس معلومات کے لیے پیشہ ور انسانی ترجمہ کی سفارش کی جاتی ہے۔ اس ترجمے کے استعمال سے پیدا ہونے والی کسی بھی غلط فہمی یا غلط تشریح کی ذمہ داری ہم قبول نہیں کرتے۔

This site is open source. Improve this page.