امنیت ایجنت هوش مصنوعی؛ رسید امضاشده برای اقدامات قابل راستی‌آزمایی

فایل لاگ معمولی نشان می‌دهد برنامه چه چیزی ثبت کرده، اما به‌تنهایی تضمین نمی‌کند که بعداً تغییر نکرده باشد. وقتی ایجنت پیام می‌فرستد، پرداخت را پیش می‌برد یا داده‌ای را تغییر می‌دهد، این تفاوت اهمیت پیدا می‌کند. یکی از لایه‌های امنیت ایجنت هوش مصنوعی، ثبت اقدام‌ها به شکلی است که هر کسی بتواند بدون اعتماد به شما آن را بررسی کند.

در این قسمت پایانی از مجموعه‌ی آموزش هوش مصنوعی تخته سبز، رسیدهای امضاشده را می‌شناسیم. یاد می‌گیریم چطور رسید بسازیم، بررسی کنیم و به هم زنجیر کنیم. و مهم‌تر از همه، دقیقاً می‌بینیم رسید چه چیزی را اثبات می‌کند و چه چیزی را نه.

مسئله‌ی ردپای حسابرسی در امنیت ایجنت هوش مصنوعی

تصور کنید یک ایجنت آموزشی مستقر کرده‌اید که درخواست دانشجوها را می‌خواند، ابزار صدا می‌زند و پیام می‌فرستد. روزی حسابرسی می‌آید و می‌پرسد: «نشانم بده ایجنت چه کار کرده است.» فایل‌های لاگ را تحویل می‌دهید.

حسابرس سؤال سخت‌تری می‌پرسد: «از کجا بدانم این لاگ‌ها بعد از وقوع ویرایش نشده‌اند؟» و اینجا بیشتر سیستم‌ها پاسخی ندارند.

چرا لاگ‌های رایج کافی نیستند

بیشتر ایجنت‌ها امروز به سه نوع ثبت تکیه دارند. لاگ برنامه، که خود ایجنت می‌نویسد و هر کسی با دسترسی به سیستم فایل می‌تواند ویرایشش کند. سرویس‌های لاگ ابری، که در سطح پلتفرم تغییر را نشان می‌دهند؛ اما فقط اگر حسابرس به ارائه‌دهنده‌ی ابر اعتماد کند.

سومی لاگ تراکنش پایگاه داده است که برای تغییر داده مناسب است، اما برای فراخوانی دلخواه ابزار نه. هیچ‌کدام بدون اعتماد حسابرس به یک طرف سوم کار نمی‌کند. رسیدهای امضاشده این مشکل را با قابل بررسی کردن مستقل هر اقدام حل می‌کنند.

رسید امضاشده چیست؟

رسید یک شیء JSON است که کاری را که ایجنت انجام داده ثبت می‌کند و با امضای دیجیتال امضا شده است. یک رسید حداقلی این‌طور است:

{
  "type": "agent.tool_call.v1",
  "agent_id": "course-assistant",
  "tool_name": "send_message",
  "tool_args_hash": "sha256:a3f9c1...",
  "result_hash": "sha256:7b2e1d...",
  "policy_id": "messaging-policy-v3",
  "timestamp": "2026-10-19T14:30:00Z",
  "sequence": 47,
  "previous_receipt_hash": "sha256:9d4e6a...",
  "signature": {"alg": "EdDSA", "sig": "c5af83...", "public_key": "8f3b2c..."}
}

به جای خود ورودی و خروجی، هش آن‌ها ثبت می‌شود. به این ترتیب رسید اطلاعات شخصی را افشا نمی‌کند، اما هر کسی که ورودی اصلی را داشته باشد، می‌تواند تطبیقش را بررسی کند.

سه ویژگی اصلی

اول، امضا. رسید با کلید خصوصی Ed25519 امضا می‌شود و هر کسی که کلید عمومی را دارد، می‌تواند آن را بررسی کند. دوم، کدگذاری کانونی. پیش از امضا، JSON با استاندارد RFC 8785 مرتب و یکسان می‌شود تا ترتیب کلیدها یا فاصله‌ها امضا را عوض نکند.

سوم، زنجیره‌ی هش. فیلد previous_receipt_hash هر رسید را به رسید قبلی وصل می‌کند. حذف یا جابه‌جایی یک رسید، همه‌ی رسیدهای بعدی را نامعتبر می‌کند.

ساخت و بررسی رسید در پایتون

برای ساخت رسید به کتابخانه‌ی خاصی نیاز ندارید. ابزارهای رمزنگاری در دسترس‌اند و منطق کار چند ده خط است. نمودار زیر مسیر ساخت و بررسی را نشان می‌دهد.

امضا کردن

کد زیر رسید را کانونی می‌کند، هش می‌گیرد و امضا می‌کند:

import hashlib
from nacl import signing
from jcs import canonicalize  # RFC 8785

signing_key = signing.SigningKey.generate()  # در محیط واقعی: گاوصندوق کلید

def sign_receipt(payload: dict) -> dict:
    digest = hashlib.sha256(canonicalize(payload)).digest()
    sig = signing_key.sign(digest).signature
    return {**payload, "signature": {"alg": "EdDSA", "sig": sig.hex(),
                                     "public_key": bytes(signing_key.verify_key).hex()}}

کلید خصوصی مهم‌ترین دارایی این سیستم است. در محیط واقعی باید در گاوصندوق کلید یا ماژول سخت‌افزاری نگه داشته شود، نه در کد یا فایل تنظیمات.

بررسی و تشخیص دستکاری

بررسی، عکس همین کار است. امضا را جدا می‌کنید، بقیه را دوباره کانونی و هش می‌کنید و امضا را با کلید عمومی می‌سنجید:

from nacl.exceptions import BadSignatureError

def verify_receipt(receipt: dict) -> bool:
    sig = receipt.get("signature") or {}
    if sig.get("alg") != "EdDSA":
        return False
    payload = {k: v for k, v in receipt.items() if k != "signature"}
    digest = hashlib.sha256(canonicalize(payload)).digest()
    try:
        signing.VerifyKey(bytes.fromhex(sig["public_key"])).verify(digest, bytes.fromhex(sig["sig"]))
        return True
    except BadSignatureError:
        return False

بدون تماس شبکه و بدون اعتماد به کسی. برای دیدن تشخیص دستکاری، یک رسید معتبر بسازید، یک بایت از tool_args_hash را تغییر دهید و دوباره بررسی کنید؛ نتیجه False است.

زنجیره کردن رسیدها

یک رسید فقط یک اقدام را محافظت می‌کند؛ زنجیره‌ای از رسیدها، یک توالی را. برای حذف بی‌صدای رسید شماره‌ی ۲، مهاجم باید previous_receipt_hash رسید ۳ را تغییر دهد، که امضایش را می‌شکند. یا باید رسید ۳ را دوباره امضا کند، که کلید خصوصی ایجنت را می‌خواهد.

اگر کلید خصوصی در گاوصندوق سخت‌افزاری باشد و کلید عمومی منتشر شده باشد، هیچ‌کدام از این حمله‌ها بدون کشف ممکن نیست. نتیجه، ردپایی است که حسابرس بیرونی بدون اعتماد به شما بررسی می‌کند.

رسید چه چیزی را اثبات می‌کند و چه چیزی را نه

این مهم‌ترین بخش این آموزش است. رسیدها قدرتمندند اما قدرتشان محدود است. جدول زیر این مرز را روشن می‌کند.

اشتباه رایج

اشتباه رایج این است که فکر کنیم «رسید داریم» یعنی «قانون‌مندیم». این‌طور نیست. یک رسید می‌تواند یک پاسخ نادرست را به همان وضوح پاسخ درست ثبت کند. اگر ایجنت درخواست دستکاری‌شده‌ای بگیرد و بر اساسش عمل کند، رسید آن اقدام را دقیق ثبت می‌کند؛ اما درستی ورودی را تضمین نمی‌کند.

رسیدها پایه‌اند، نه کل ساختمان. هنوز به اعتبارسنجی ورودی، اجرای سیاست پیش از اقدام و تأیید انسانی برای کارهای پرخطر نیاز دارید.

رسید تأیید انسانی

برای اثبات اینکه یک انسان دقیقاً همین اقدام را تأیید کرده، نوع دومی از رسید لازم است؛ رسید تأیید انسانی که با کلید تأییدکننده امضا می‌شود و به هش کانونی همان اقدام اشاره دارد. آن‌وقت می‌توان ثابت کرد انسان دقیقاً این اقدام را تأیید کرده و ایجنت دقیقاً همان را اجرا کرده است.

این طرح باید جلوی حمله‌های ظریف‌تر را هم بگیرد. مثلاً امضای معتبری که به دلیل تغییر نسخه‌ی سیاست یا حذف کلید تأییدکننده دیگر پذیرفتنی نیست. یا رسید اقدامی که به تأیید واقعی اما مربوط به اقدام دیگری اشاره می‌کند. هر کدام باید با دلیل جداگانه رد شود.

سناریوی عملی؛ پیامی که مدرس تأیید کرد

مدرس پیامی را برای دانشجوها تأیید کرده و تیم باید بعداً نشان دهد همان پیام، بدون تغییر، ارسال شده است. ورودی آزمون شناسه‌ی اقدام، خلاصه‌ی داده، نسخه‌ی پیام و تصمیم تأییدکننده است. یک نمونه‌ی سالم و یک نمونه با یک فیلد تغییرکرده آماده کنید.

معیار پذیرش و نمونه‌ی شکست

اقدام مورد بررسی، ساخت رکورد امضاشده و بررسی آن با ابزاری مستقل است. معیار پذیرش دو بخش دارد: تغییر داده تشخیص داده شود و تأیید دقیقاً با همان اقدام تطبیق کند؛ نه با نسخه‌ی دیگری از پیام.

شکستی که باید عمداً دنبالش بگردید، استفاده از امضا به‌عنوان اثبات درستی علمی پاسخ یا مجاز بودن اقدام است. اگر گزارش شما بگوید «رسید معتبر است، پس پیام درست بوده»، مرز اثبات را زیر پا گذاشته‌اید. رسید فقط می‌گوید همین پیام، بدون تغییر، با این کلید ثبت شده است.

تمرین عملی؛ رسید قابل بررسی

خروجی این تمرین یک نمونه رسید قابل بررسی، همراه با توضیح دقیق حدود اثبات آن است:

1. برای سه اقدام پشت‌سرهم ایجنت، رسید امضاشده و زنجیرشده بسازید.
2. یک بایت از رسید وسط را تغییر دهید و نشان دهید زنجیره دقیقاً کجا می‌شکند.
3. در یک پاراگراف بنویسید رسیدهای شما چه چیزی را اثبات می‌کنند و چه لایه‌هایی هنوز لازم است.

مشخص کنید کدام بخش را واقعاً اجرا کرده‌اید و کدام هنوز فرض است.

سخن پایانی

امنیت ایجنت هوش مصنوعی فقط جلوگیری از اقدام اشتباه نیست؛ اثبات اقدام‌های انجام‌شده هم هست. رسید امضاشده با امضای Ed25519، کدگذاری کانونی و زنجیره‌ی هش، ردپایی می‌سازد که هر حسابرسی بدون اعتماد به شما بررسی می‌کند و کوچک‌ترین دستکاری را آشکار می‌کند. اما مرز آن روشن است: رسید نسبت‌دهی، یکپارچگی و ترتیب را اثبات می‌کند، نه درستی تصمیم یا رعایت سیاست را.

این قسمت، پایان مسیر پنجاه‌قسمتی آموزش هوش مصنوعی تخته سبز است. از انتخاب مدل و پرامپت‌نویسی تا ایجنت، RAG، حافظه، استقرار و امنیت را قدم‌به‌قدم پیمودیم. حالا وقت ساختن است؛ از یک نمونه‌ی کوچک شروع کنید و هر لایه را با آزمون خودش اضافه کنید.

این آموزش بر پایه‌ی درس Securing AI Agents with Signed Receipts از مجموعه‌ی آزاد AI Agents for Beginners مایکروسافت (مجوز MIT) به فارسی بازنویسی و تکمیل شده است.