تصور کنید یک عامل تولید (Production Agent) رکوردی را می‌خواند، فایلی را صادر می‌کند یا مبلغی را جابه‌جا می‌کند؛ در این حالت، دفترچه ثبت وقایع (Audit Log) با دقت عمل را ثبت می‌کند، اما نویسندهٔ این عمل را «عامل» می‌شناسد، نه انسانی که دستور را صادر کرده است. این شکاف رایج در دیده‌شدگی باعث می‌شود اکثر عامل‌ها استانداردهای ماده ۱۲ قانون هوش مصنوعی اتحادیه اروپا (EU AI Act) را نادیده بگیرند. این ماده صراحتاً الزام می‌کند که سیستم‌های هوش مصنوعی با ریسک بالا باید لاگ‌هایی را نگهداری کنند که «اشخاص حقیقی» (Natural Persons) درگیر در هر رویداد را شناسایی کند.
بر اساس مستندات این قانون، این الزام خاص از ۲ اوت ۲۰۲۶ اجرایی می‌شود. با این حال، در حال حاضر اکثر سامانه‌ها تحت حساب‌های خدمات مشترک (Shared Service Accounts) یا کلیدهای API عمل می‌کنند که هویت واقعی انسان را می‌پوشاند و محو می‌کند. این وضعیت یک خلاء قانونی و عملیاتی جدی ایجاد می‌کند؛ اگر یک عامل کاری را انجام دهد که نباید انجام می‌داد، پاسخ «حساب سیستمی این کار را کرد» پاسخی نیست که کسی بتواند بر اساس آن اقدامی کند. شما نمی‌توانید یک حساب خدمات را تادیب کنید و نمی‌توانید به رگولاتور بگویید که یک ربات مسئول بوده است و پرونده تحقیقات را در همان‌جا ببندید. اهمیت این موضوع را می‌توان در تحلیل ما درباره نقش حیاتی لاگ‌های رویداد در دستیابی به پایداری مشاهده کرد، جایی که ثبت دقیق وضعیت تنها راه نجات از آشفتگی‌های عملیاتی است.
همان‌طور که پیش‌تر در تحلیل‌های خود درباره تکنولوژی‌های رمزنگاری مانند رمزنگاری همومورفیک (FHE) و محافظت از حریم خصوصی داده‌ها بررسی کردیم، چالش «انتساب» (Attribution) یک موجود کاملاً متفاوت است. موضوع در اینجا پنهان کردن داده‌ها نیست، بلکه اثبات دقیق این است که چه کسی در یک زنجیره نرم‌افزاری پیچیده، اجازهٔ یک اقدام خاص را داده است. یک لاگ که بر پایه اعتبارنامه‌های مشترک ساخته شده باشد، هرگز نمی‌تواند به پرسش «چه کسی؟» پاسخ دهد، زیرا آن هویت اصلاً در هیچ مرحله‌ای ثبت نشده است.
شکست شناسایی مبتنی بر مدل
غریزه‌ی بدیهی برای توسعه‌دهندگان این است که از مدل بخواهند گزارش دهد برای چه کسی عمل می‌کند. این کار معمولاً با قرار دادن هویت کاربر در پرامپت سیستمی (System Prompt) یا اجبار عامل به گنجاندن هویت در فراخوانی ابزار (Tool Call) انجام می‌شود. اما این رویکرد به دو دلیل حیاتی شکست می‌خورد:
- شکاف‌های پروتکل: در سطح انتقال داده (Wire Level)، یک فراخوانی ابزار چیزی شبیه به
{"name": "export_record", "arguments": {...}}است. در این ساختار، هیچ فیلد بومی برای هویت انسانی وجود ندارد. سیستم فراخوانی توابع OpenAI هیچ جایگاه بومی برای هویت ندارد و اگرچه پروتکل زمینهٔ مدل (MCP) اجازه انتقال آن را می‌دهد، اما تقریباً هیچ‌کس آن را پیاده‌سازی نمی‌کند. در واقع، «چه کسی» در سطح پروتکل هیچ جایی برای زندگی ندارد. - تزریق پرامپت: خروجی مدل تنها سطحی است که هرگز نمی‌توان آن را برای احراز هویت به عنوان منبع مورد اعتماد پذیرفت. هر چیزی که مدل تولید می‌کند، می‌تواند هدف تزریق پرامپت (Prompt Injection) قرار گیرد. اگر هویت از طریق مدل منتقل شود، داده‌هایی که عامل از یک ابزار می‌خواند می‌تواند آن هویت را بازنویسی کند. آزمایش‌ها نشان می‌دهند که توصیفات ابزارها (Tool Descriptions) حتی از خروجی‌های ابزار در ربودن کنترل مدل و تغییر هویت مؤثرتر هستند.
معرفی Crumb: زمان‌سنجِ انتساب
برای حل این بحران، الکس لاگواردیا (Alex Laguardia) ابزاری به نام Crumb را توسعه داد. Crumb یک محیط اجرا (Runtime) است که هویت را خارج از فرآیند استدلال مدل ثبت می‌کند. در این معماری، هر فراخوانی ابزار باید از یک درگاه (Gateway) واحد عبور کند. این درگاه هویت انسان را از یک نشست تأییدشده (Verified Session) که در لحظه ورود ثبت شده است استخراج می‌کند و هرگز این اطلاعات را از خود مدل دریافت نمی‌کند.
مکانیسم عملکرد
Crumb از یک فرآیند رمزنگاری سخت‌گیرانه برای تضمین پاسخگویی استفاده می‌کند که مراحل آن به شرح زیر است:
- تبادل توکن: این سیستم از یک تبادل توکن واقعی بر اساس استاندارد RFC 8693 در برابر یک ارائه‌دهنده هویت (مانند Okta، Keycloak یا Zitadel) استفاده می‌کند. نشست کاربر به عنوان
subject_tokenارسال شده و یک ترکیب (Composite) امضا شده توسط ارائه‌دهنده با الگوریتم RS256 بازگردانده می‌شود. - توکن‌های تفویض: Crumb یک توکن تفویض کوتاه‌مدت صادر می‌کند. این توکن، انسان را به عنوان
sub(موضوع) مطابق RFC 8693 و عامل را به عنوانact(بازیگر) شناسایی می‌کند و دامنه آن دقیقاً به همان منبعی محدود می‌شود که فراخوانی شده است. - تأیید: منبع موردنظر، توکن را در برابر JWKS (مجموعه کلیدهای عمومی) منتشر شده توسط ارائه‌دهنده تأیید می‌کند. چون این فرآیند از استاندارد پیروی می‌کند و نه یک نسخه سفارشی، هیچ نیازی به اشتراک رازهای محرمانه (Shared Secrets) نیست.
- دفتر کل (The Ledger): هر اقدام عامل، یک «خرده‌راهنما» (crumb) در یک دفتر کل با زنجیره هش (Hash-chained Ledger) که فقط قابلیت افزودن دارد، می‌اندازد. هر ورودی با امضای Ed25519 تأیید می‌شود. ابزارها هر فراخوانی را که توکن معتبر یدک نکشد رد می‌کنند و بدین ترتیب هیچ مسیری برای دسترسی به داده‌ها که این فرآیند را دور بزند، وجود نخواهد داشت. این رویکرد برای ایجاد سوابق غیرقابل‌ویرایش مشابه است با مدل معماری دوگانه Nylas که برای ثبت تاریخچه تغییرات در عامل‌های ایمیلی به کار می‌رود.
حل معمای پرش‌های متعدد (Multi-Hop)
سیستم‌های دنیای واقعی به ندرت ساده هستند. معمولاً یک انسان به یک ارکستراتور دستور می‌دهد، ارکستراتور دستور را به یک زیر-عامل (Sub-agent) تفویض می‌کند و در نهایت آن زیر-عامل ابزار را فراخوانی می‌کند. وقتی انسان دو مرحله از اقدام فاصله دارد، اکثر روایت‌های انتساب متوقف می‌شوند زیرا نهادهای استانداردسازی هنوز راهکار کاملی برای این مورد ارائه نداده‌اند.
Crumb این مشکل را با بهره‌برداری از مکانیسمی که در بخش ۴.۱ استاندارد RFC 8693 پنهان شده است حل می‌کند: ادعای act می‌تواند به صورت تو در تو (Nested) باشد. هر بازیگر جدید در زنجیره، بازیگر قبلی را در بر می‌گیرد (Wrap می‌کند)، اما انسان در تمام طول مسیر تا پایین‌ترین سطح، به عنوان sub در ریشه باقی می‌ماند. با باز کردن این لایه‌های تو در تو، یک حسابرس می‌تواند زنجیره کامل «چه کسی برای چه کسی عمل کرد» را ردیابی کند.
در یک سناریوی عملی، «آلیس» در هنگام ورود، اجازه اقدام read_record را می‌دهد. یک عامل برنامه‌ریز درخواست او را می‌گیرد و آن را به یک زیر-عامل پژوهشگر تفویض می‌کند و سپس پژوهشگر رکورد را می‌خواند. Crumb این مسیر را از هر دو عامل بازگشته و به آلیس می‌رساند. اگر یکی از این گره‌ها دچار خطا یا تخریب شود و اقدام به export_record کند — کاری که آلیس هرگز اجازه نداده است — این اقدام ممکن است از نظر فنی اجرا شود، اما Crumb ثبت می‌کند که هیچ دستور انسانی پشت آن نیست. سیستم این عمل را به عنوان «غیرمجاز» علامت می‌زند و زنجیره عامل‌های مسئول را نام می‌برد، و بدین ترتیب آلیس را به صورت اثباتی تبرئه می‌کند.
جلوگیری از دست‌کاری داده‌ها (Tamper-Evidence)
یک لاگ امضاشده و با زنجیره هش، تا زمانی که کلید امضا امن باشد، ضد دست‌کاری به نظر می‌رسد. اما اگر اپراتوری کلید امضا را در اختیار داشته باشد، می‌تواند تاریخ را بازنویسی کرده و کل زنجیره را دوباره امضا کند. از آنجایی که هر ورودی به طور معتبر امضا شده است، تأیید هر ورودی به تنهایی منجر به پذیرش جعل می‌شود.
برای جلوگیری از این حمله «بازگشت اپراتور» (Operator-rollback)، Crumb ریشه مرکل (Merkle Root) خود را در نقاط زمانی مشخص (Checkpoint) کرده و آن را در Rekor (دفتر شفافیت عمومی Sigstore) منتشر می‌کند. اگر اپراتوری یک خرده‌راهنما را بازنویسی کرده و زنجیره را مجدداً امضا کند، ریشه بازنویسی شده دیگر با ریشه زمان‌دار شده‌ای که به صورت عمومی در Rekor قرار دارد، مطابقت نخواهد داشت. در این حالت، جعل توسط یک سیستم خارجی که اپراتور کنترلی روی آن ندارد، شناسایی می‌شود.
موازنه‌ها و نقاط ضعف عملی
Crumb به عنوان یک «جعبه‌سیاه» یا ثبت‌کننده پرواز (Flight Recorder) طراحی شده است، نه یک صفحه کنترل (Control Plane). این سیستم اقدامات را ثبت و اثبات می‌کند اما جلوی آن‌ها را نمی‌گیرد؛ این نقش به ابزارهای تخصصی مدیریت دسترسی مانند Cerbos، Capsule یا Astrix واگذار شده است. علاوه بر این، قدرت انتساب تنها به اندازه قدرت درگاه (Gateway) است؛ اگر مهاجمی بتواند درگاه را دور بزند، هیچ ردی (crumb) ایجاد نخواهد شد.
نکات فنی دیگری نیز در پیاده‌سازی وجود دارد:
- حریم خصوصی داده‌ها: دفتر کل به جای ذخیره آرگومان‌های خام، هش (Hash) آرگومان‌ها را ذخیره می‌کند. این کار باعث می‌شود داده‌های حساس وارد لاگ نشوند، هرچند به این معناست که سیستم اثبات می‌کند «یک اقدام رخ داده و چه کسی دستور داده است»، نه اینکه دقیقاً چه بایت‌هایی لمس شده‌اند.
- تفویض بین-صادره (Cross-Issuer Delegation): از آنجایی که هیچ RFC فعلی تفویض بین صادرکنندگان مختلف را تعریف نمی‌کند، Crumb از قراردادی استفاده می‌کند که در آن توکن هر صادرکننده، توکن قبلی را به خود بچسباند (Staple). تأیید اعتبار با بازگشت در زنجیره تا رسیدن به انسان انجام می‌شود و هر بخش در برابر کلید صادرکننده مربوط به خود، بر اساس یک مجموعه اعتماد فدرال (Federation Trust Set) صریح، بررسی می‌شود.
- سازگاری با MCP: در حالی که انتساب در MCP توسط مشخصات فنی (Spec) مجاز شمرده شده، اما به ندرت در لایه‌های بالادستی پیاده‌سازی شده است. در نتیجه، Crumb می‌تواند رکورد را مهر و ثبت کند، اما نمی‌تواند سروری را که با این استاندارد سازگار نیست مجبور کند تا هویت انسانی را به رسمیت بشناسد.
این چرخش معماری، شناسایی و انتساب را از یک «تلاش حداکثری» در قالب پرامپت، به یک قطعیت رمزنگاری تبدیل می‌کند تا ضرب‌الاجل ۲ اوت ۲۰۲۶ برای رعایت ماده ۱۲ قانون هوش مصنوعی اتحادیه اروپا محقق شود. دمو زنده این سیستم در crumb.alexlaguardia.dev در دسترس است و به کاربران اجازه می‌دهد خرده‌راهنماها را ایجاد کرده و مشاهده کنند که چگونه لنگرهای خارجی، تلاش‌های جعل را شناسایی می‌کنند.
گام بعدی شما
- اگر از عامل‌های هوش مصنوعی در محیط تولید (Production) استفاده می‌کنید، ساختار لاگ‌های خود را بررسی کنید تا مطمئن شوید هویت کاربر نهایی ثبت می‌شود و نه فقط نام مدل.
- دمو زنده این ابزار را در
crumb.alexlaguardia.devبررسی کنید تا نحوه ثبت و شناسایی جعل‌ها را ببینید. - برای لایه‌های کنترلی، ترکیب Crumb با ابزارهایی نظیر Cerbos را برای مدیریت دسترسی‌های داینامیک بررسی کنید.
اما این سیستم‌ها تنها بخشی از پازل هستند؛ برای درک اینکه چگونه می‌توان دسترسی‌های مدل‌ها را در سطح سخت‌افزاری محدود کرد، تحلیل ما درباره تراشه‌های Blackwell را بخوانید.
گفتگو