تماشای ویدیو درس: ایمنسازی عوامل هوش مصنوعی با رسیدهای رمزنگاریشده
(ویدیو درس و تصویر کوچک توسط تیم محتوای مایکروسافت پس از ادغام اضافه خواهند شد، مطابق الگوی درس ۱۴ / ۱۵.)
این درس پوشش میدهد:
پس از کامل کردن این درس خواهید دانست چگونه:
فرض کنید شما یک عامل هوش مصنوعی برای شرکت Contoso Travel مستقر کردهاید. این عامل درخواستهای مشتری را میخواند، از API پروازها برای جستجو استفاده میکند و به نمایندگی از مشتری صندلی رزرو میکند. در سه ماهه گذشته، عامل ۵۰،۰۰۰ رزرو انجام داده است.
امروز یک حسابرس میآید و سوال سادهای میپرسد: «به من نشان بده عامل شما چه کاری انجام داد.»
شما فایلهای لاگ را میدهید. حسابرس آنها را بررسی میکند و سوال سختتری میپرسد: «چطور مطمئن شوم این لاگها ویرایش نشدهاند؟»
این مشکل ردپای حسابرسی است. اکثر استقرارهای عامل امروز به اینها متکی هستند:
هیچ کدام نمیتوانند بدون اینکه حسابرس به شخص یا نهادی (شما، ارائهدهنده ابر، فروشنده پایگاه داده) اعتماد کند، سوال حسابرس را پاسخ دهند. برای استفاده داخلی معمولاً این اعتماد قابل قبول است اما برای بارهای تحت مقررات (مالی، بهداشت و درمان، هر چیزی تحت قانون هوش مصنوعی اتحادیه اروپا) قابل قبول نیست.
رسیدهای رمزنگاریشده این مشکل را با امکان تأیید مستقل برای هر عمل عامل حل میکنند. حسابرس نیازی به اعتماد به شما ندارد. فقط کلید عمومی شما و خود رسید مورد نیاز است.
رسید یک شیء 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 # JSON رسمی RFC 8785
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 واقعاً ارزیابی شده یا اینکه اگر بررسی میشد این اقدام را اجازه میداد. رسید آنچه ادعا شده را ثبت میکند نه آنچه اعمال شده.این مرز برای دو دلیل اهمیت دارد:
اشتباه رایج این است که فرض کنیم «رسید داریم» یعنی «حکمرانی داریم.» اینطور نیست. رسید پایه است. حکمرانی سیستمی است که روی آن میسازید.
کد پایتون این درس به عمد حداقلی است تا بتوانید هر خط را بخوانید و دقیقاً بفهمید چه اتفاقی میافتد. در تولید دو انتخاب دارید:
مستقیماً روی اجزای رمزنگاری بسازید. ۵۰ خطی که دیدید برای بسیاری از موارد کافی است. 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 خودتان یا استفاده از کتابخانه تستشده است: هر دو معقولاند؛ کتابخانه زمان میخرد و سطح حسابرسی را کاهش میدهد؛ روش از صفر تا صد شما را مجبور به فهم تمام اجزا میکند. این درس روش از صفر تا صد را آموزش میدهد تا مبنای هر دو انتخاب را داشته باشید.
قبل از رفتن به تمرین، دانش خود را آزمایش کنید.
۱. رسید با کلید خصوصی Ed25519 عامل امضا شده است. حسابرس فقط کلید عمومی را دارد. آیا حسابرس میتواند رسید را به صورت آفلاین تأیید کند؟
۲. مهاجم فیلد policy_id یک رسید را تغییر میدهد تا ادعا کند زیر سیاستی با مجوز بیشتر بوده است. امضا روی بارگذاری اصلی است. در تأیید چه اتفاقی میافتد؟
۳. چرا رسید به جای آرگومانها و نتیجه خام، tool_args_hash و result_hash را شامل میشود؟
۴. فیلد previous_receipt_hash هر رسید را به پیشینی آن پیوند میدهد. اگر مهاجم یک رسید وسط زنجیره را بیصدا حذف کند، چه چیزی نامعتبر میشود؟
۵. رسید بهدرستی تأیید میشود. آیا این اثبات میکند که عمل عامل درست، منطقی یا منطبق بر سیاست بوده است؟
دفترچه یادداشت code_samples/18-signed-receipts.ipynb را باز کنید و چهار بخش را کامل کنید:
چالش کششی ۲: دو تا از رسیدهای خود را با هم هَش SHA-256 کنید (بایتهای کاننیکالشدهشان را به ترتیب مشخص به هم بچسبانید) و حاصل را به عنوان یک فیلد جدید بر روی رسید سوم قرار دهید قبل از آن که آن را امضا کنید. تأیید کنید که همه سه رسید به درستی عبور میکنند. شما همین حالا یک اثبات شمول یک مرحلهای ساختهاید: هرکس رسید سوم را داشته باشد میتواند اثبات کند رسید اول و دوم در زمان امضای آن وجود داشتند، بدون نیاز به افشای محتوایشان. این الگوی رسیدهای افشای انتخابی است که در مقیاس استفاده میشود (تعهدهای مرکل، RFC 6962).
رسیدهای رمزنگاریشده به عاملهای هوش مصنوعی یک مسیر حسابرسی میدهند که:
آنها جایگزین اعتبارسنجی ورودی، اعمال سیاستها یا زیرساخت هویت نیستند. آنها پایهای برای آن لایهها هستند. زمانی که عاملها را در محیطهای تنظیمشده، گردش کارهای چندسازمانی یا هر موقعیتی که نمیتوان انتظار داشت حسابرس آینده به شما اعتماد کند به کار میبرید، رسیدها نحوه درست کردن مسیر حسابرسی صادقانه هستند.
مهمترین نکته: رسیدها ثابت میکنند چه کسی چه چیزی گفته و کی گفته است. آنها اثبات نمیکنند آنچه گفته شده، درست یا صحیح بوده است. این تمایز را محکم نگه دارید. این تفاوت بین یک سیستم اصیل منشأ و یک سیستم گمراهکننده است.
زمانی که آماده هستید از این درس فراتر بروید و عاملهای دارای امضای رسید را در محیط واقعی مستقر کنید:
https://your-org.example.com/.well-known/agent-keys.json.به مایکروسافت فاندری دیسکورد بپیوندید تا با دیگر یادگیرندگان ملاقات کنید، در ساعتهای کاری شرکت کنید و سوالات هوش مصنوعی خود را بپرسید.
این درس شامل امضای با یک رسید و دنبالههای هش زنجیرهای است. همان اجزا در چند الگوی پیشرفته دیگر ترکیب میشوند که ممکن است با رشد پستور حاکمیتی شما با آنها روبرو شوید:
authorization_*) و پساجرا (result_*) با امضاهای مستقل تقسیم میکنند، که زمانی که تصمیم مجوز و نتیجه مشاهده شده توسط افراد یا در زمانهای مختلف تولید میشوند مفید است. این افزایشی بر روی فرمت رسیدی است که در این درس آموزش داده شده است.result_hash قرار دهید مهر و موم میکند. بارهای دنیای واقعی اغلب از نتیجه یک فراخوان ابزار ساده غنیترند: دلیلسازی پیشتصمیم (پیشبینی مدل، گزینههای در نظر گرفته شده، شواهد و جامعیت آن، وضعیت ریسک، زنجیره حسابرسی، نتیجه دروازه) همه میتوانند داخل بار باشند، مهر و موم شده با یک رسید واحد. این فرمت رسید را حداقلی نگه میدارد در حالی که اجازه میدهد طرحهای بار حوزه به حوزه توسعه یابند.signature.alg میتواند ML-DSA-65 (استاندارد امضای پساکوانتومی NIST) را در مواقع مهاجرت در خود نگه دارد. برای دوره انتقالی که رسیدها دوگانه امضا میشوند برنامهریزی کنید.ساخت عاملهای استفاده کامپیوتر (CUA)
(توسط نگهدارندگان برنامه درسی تعیین میشود)
سلب مسئولیت: این سند با استفاده از سرویس ترجمه هوش مصنوعی Co-op Translator ترجمه شده است. در حالی که ما در تلاش برای دقت هستیم، لطفاً توجه داشته باشید که ترجمههای خودکار ممکن است شامل خطاها یا نادرستیهایی باشند. سند اصلی به زبان مادری خود باید به عنوان منبع معتبر در نظر گرفته شود. برای اطلاعات حیاتی، ترجمه حرفهای انسانی توصیه میشود. ما در قبال هرگونه سوء تفاهم یا برداشت نادرست ناشی از استفاده از این ترجمه مسئولیتی نداریم.