Trust Gateway با تفکیک هویت و مجوز، مشکل اولین تماس عامل‌های هوش مصنوعی را حل

تصور کنید یک عامل خرید شخصی بخواهد در ۳۰ ثانیه از ۲۰ فروشگاه مختلف استعلام قیمت بگیرد؛ در حالت فعلی، این عامل با یک دیوار بحرانی روبروست: او یا به عنوان یک ربات استخراج‌کننده (Scraper) مسدود می‌شود یا کاربر را مجبور می‌کند ۲۰ بار فرم‌های مجزای رضایت و تأیید صلاحیت را پر کند. Trust Gateway با پیاده‌سازی یک سیستم هویت دوگانه، این بن‌بست را می‌شکند و بین «عامل کیست» (هویت) و «چه اجازه‌ای دارد» (تفویض اختیار) تفکیک قائل می‌شود.

این تغییر معماری در حالی رخ می‌دهد که صنعت با چالش «اولین تماس» (First Contact) دست‌وپنجه نرم می‌کند. چارچوب‌های فعلی مانند OAuth 2.x بر پایه روابط پیش‌ساخته و کلاینت‌های ثبت‌شده هستند و وقتی یک عامل خودمختار برای نخستین بار با سرویسی مواجه می‌شود، شکست می‌خورند. به نقل از گزارشی در dev.to که در ۱۷ اکتبر ۲۰۲۶ منتشر شد، تکیه فعلی بر کلیدهای API یا اسرار مشترک (Shared Secrets)، ریسک جعل هویت را افزایش می‌دهد، زیرا هیچ پیوند رمزنگاری‌شده‌ای بین کلید و آن عامل خاص وجود ندارد.

زمینه و بستر اولین تماس

در سناریوی فعلی، اگر از عامل بخواهید «یک جعبه ذخیره‌سازی ضدآب پیدا کن و بهترین گزینه زیر ۵۰ یورو را بخر»، او باید در عرض ۳۰ ثانیه به ۲۰ فروشگاه ناشناس متصل شود. هر فروشگاه با یک دوراهی روبروست: یا عامل را به عنوان یک اسکرپر شناسایی و مسدود کند، یا کاربر را مجبور کند از ۲۰ جریان ثبت‌نام و رضایت مجزا عبور کند، یا کلید API را بپذیرد که دسترسی «همه یا هیچ» دارد و هیچ ردپای حسابرسی (Audit Trail) از این نمی‌گذارد که کدام عامل دقیقاً چه اقدامی انجام داده است.

برای حل این مشکل، یک فروشگاه نیاز دارد به چهار پرسش مشخص پاسخ دهد:

• این عامل کیست؟ (اشاره به نمونه نرم‌افزاری خاصی که همین حالا درخواست می‌فرستد).
• چه کسی آن را فرستاده است؟ (شخص یا سازمانی که پشت این عامل ایستاده است).
• چه کارهایی مجاز است انجام دهد؟ (مجوزهای خاص مانند مرور کالا، رزرو یا پرداخت تا سقف ۵۰ یورو).
• چرا باید این ادعاها را باور کرد؟ (امکان تأیید بدون تماس با شخص ثالث و قابلیت ابطال مجوز).

مقایسه رویکردهای فعلی

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

• کلیدهای API / اسرار مشترک: هیچ پاسخ قابل اعتمادی نمی‌دهند. عامل صرفاً هویت کاربر را جعل می‌کند و هیچ ردپای حسابرسی برای هر عامل باقی نمی‌ماند.
• OAuth 2.x / OIDC (با DPoP و تبادل توکن): تا حدی پاسخ می‌دهند که چه کسی فرستاده و چه اجازاتی دارد. اما این‌ها بر پایه سرورهای مجوز (Authorization Servers) متصل به هر سرویس ساخته شده‌اند و نیاز به نشست‌های کاربر یا ثبت‌نام کلاینت دارند.
• هویت‌های کاری (SPIFFE, WIMSE): در شناسایی عامل در داخل یک سازمان واحد بسیار قوی هستند، اما در تفویض اختیار مصرف‌کننده بین شرکت‌های مختلف (Cross-company) دچار مشکل می‌شوند.
• درخواست‌های HTTP امضا شده (Web Bot Auth): اپراتوری که ربات را اجرا می‌کند شناسایی می‌کنند، اما مشخص نمی‌کنند کدام کاربر خاص اختیار را تفویض کرده است.
• گواهی‌های قابل تأیید (W3C VC/VP, SD-JWT, UCAN): به پرسش‌های «چه کسی فرستاده» و «چه اجازاتی دارد» پاسخ می‌دهند و تا حدی هویت و تأیید را پوشش می‌دهند. اگرچه صادرکننده را از تأییدکننده جدا می‌کنند، اما موضوعاتی چون اعتماد به صادرکننده، ابطال و نگهداری کلیدها همچنان باز است.

تلاش‌های اخیر IETF، از جمله پیش‌نویس سپتامبر ۲۰۲۶ با عنوان «سامانه مدیریت هویت AI»، عامل‌ها را به عنوان «Workload» در نظر می‌گیرند و به جای اختراع پروتکل‌های جدید، WIMSE و OAuth را ترکیب می‌کنند. این مورد هنوز یک پیش‌نویس اولیه است.

چرا OAuth در اولین تماس دچار فشار می‌شود؟

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

اگرچه ثبت‌نام پویا (Dynamic Client Registration - RFC 7591) کاغذبازی‌ها را کاهش می‌دهد، اما به سرویس نمی‌گوید که آیا باید به یک کلاینت ناشناس اعتماد کند یا خیر. به همین ترتیب، تبادل توکن (Token Exchange - RFC 8693) از زنجیره‌های تفویض در یک فدراسیون پشتیبانی می‌کند، اما هیچ سرور مجوز مشترکی بین فروشندگان وب آزاد وجود ندارد. نکته حیاتی این است که توکن OAuth توسط سرورِ خودِ سرویس صادر می‌شود، نه اینکه توسط کاربر امضا شده و به عنوان یک گواهی توسط عامل حمل شود.

یک پیش‌نویس جولای ۲۰۲۶ در IETF بر این شکاف‌ها تأکید می‌کند: فقدان یک «بنیان هویت برای عامل» (Agent Identity Primitive)، الزام به ثبت‌نام پیش‌برد کلاینت‌ها و نبود روشی استاندارد برای راه‌اندازی هویت عامل از نقطه صفر.

مدل پاسپورت و وکالت‌نامه

توسعه‌دهندگان Trust Gateway برای حل این موضوع، مدلی بر پایه دو لایه متمایز پیشنهاد می‌دهند:

• پاسپورت (هویت عامل): یک جفت‌کلید که توسط محیط اجرای عامل (با استفاده از DIDهایی مانند did:key) نگه داشته می‌شود. این لایه پاسخ می‌دهد «چه کسی در حال صحبت است».
• وکالت‌نامه (تفویض اختیار کاربر): یک گواهی امضا شده از سوی کاربر که نام عامل خاص را ذکر کرده و محدودیت‌های او را تعریف می‌کند (مثلاً حداکثر هزینه ۵۰ یورو). این لایه پاسخ می‌دهد «عامل مجاز است چه کاری از طرف کاربر انجام دهد».

این رویکرد به فروشنده اجازه می‌دهد اعتبار عامل را به‌صورت محلی تأیید کند، بدون اینکه نیاز باشد کاربر آنلاین باشد یا عامل از قبل حسابی داشته باشد. این سیستم از ارائه‌های قابل تأیید W3C (VP) و شناسه‌های غیرمتمرکز (DIDs) استفاده می‌کند تا اطمینان حاصل شود گواهی دقیقاً به همان عاملی متصل است که آن را ارائه می‌دهد.

این الگو سوابقی دارد. پروتکل AP2 گوگل (Agent Payments Protocol) از دستورات امضا شده به عنوان گواهی‌های قابل تأیید استفاده می‌کند و تفویض اختیار را از طریق OpenID4VP با گواهی‌های SD-JWT توصیف می‌کند، هرچند دامنه آن محدود به پرداخت‌هاست. UCAN در زنجیره‌های تفویض قابلیت‌ها پیشگام بوده و کارهای IETF WIMSE در حال حاضر در حال بحث درباره تفویض گواهی مشابه برای عامل‌ها است.

پیاده‌سازی فنی در Rust

تأییدکننده (Verifier) در Trust Gateway که با زبان Rust نوشته شده (در مسیر shared_libs/trust_auth/src/did.rs و موتور سیاست‌ها در crates/trust-policy)، درخواست‌های ورودی را از طریق یک خط لوله هفت‌مرحله‌ای پردازش می‌کند تا از کلاهبرداری و سوءاستفاده سیستمی جلوگیری کند:

1. تشخیص VP: شناسایی می‌کند که آیا درخواست حاوی یک ادعای ارائه‌ی قابل تأیید (claim "vp") هست یا خیر.
2. بررسی‌های زمانی و Replay: برچسب‌های زمانی انقضا (exp) و «قبل از این زمان نباشد» (nbf) را اعتبارسنجی می‌کند. همچنین مخاطب (aud) را اعمال کرده و با استفاده از jti در یک کش KV JetStream، تکرار توکن را بررسی می‌کند تا از استفاده مجدد جلوگیری شود. TTLهای حذف از کش با پنجره exp مطابقت دارند تا از پر شدن حافظه کش جلوگیری شود.
3. اعتبارسنجی DID: از متدهای خودگواهی مانند did:key ،did:jwk و did:twin پشتیبانی می‌کند و الگوریتم‌های Ed25519 (EdDSA) و P-256 (ES256) را می‌پذیرد.
4. اثبات مالکیت (Proof of Possession): از طریق یک امضای JWS بیرونی تأیید می‌کند که فراخواننده واقعاً کنترل کلید خصوصی عامل را در اختیار دارد.
5. تأیید صادرکننده: دامنه کاربر را با لیست TRUSTED_ISSUER_DOMAINS چک کرده و اسناد did:web را تحلیل می‌کند. این مرحله شامل حفاظ‌های سخت‌گیرانه SSRF است که localhost، محدوده‌های IP خصوصی و تغییر مسیرهای HTTP را رد می‌کند و IPهای تحلیل شده را پین می‌کند تا از DNS Rebinding جلوگیری شود.
6. اتصال موضوع (Subject Binding): اطمینان حاصل می‌کند که credentialSubject.id با DID عاملی که درخواست را ارائه می‌دهد مطابقت دارد؛ این کار مانع از آن می‌شود که عامل Beta از گواهی صادر شده برای عامل Alpha استفاده کند.
7. ایزوله‌سازی: مجوزها و ابزارهای تفویض شده را به IdentityContext منتقل کرده و یک کلید ایزولاسیون مستأجر را از هش SHA-256 شناسه صادرکننده مشتق می‌کند.

درس‌های پیاده‌سازی

سه یافته کلیدی از این نمونه اولیه به دست آمد:

نخست، کلیدهای عامل (از طریق did:key یا did:jwk) نیازی به تماس‌های شبکه‌ای ندارند زیرا کلید عمومی در خودِ DID تعبیه شده است. پشتیبانی از هر دو الگوریتم Ed25519 و P-256 به عامل‌ها اجازه می‌دهد از کلیدهای سخت‌افزاری مانند TPM، Secure Enclave یا WebAuthn استفاده کنند که با مشخصات AP2 همسو است.

دوم، تحلیل did:web نیازمند کشینگ تهاجمی است. چون did:web به یک فایل JSON میزبانی شده (مثلاً https://alice.id/.well-known/did.json) ارجاع می‌دهد، اگر یک عامل همزمان به ۲۰ فروشگاه متصل شود، سرور کاربر می‌تواند به گلوگاه تبدیل شود. تأییدکنندگان باید از TTLهای Cache-Control HTTP استفاده کنند تا از تأخیر و مسدود شدن به دلیل Rate-limit جلوگیری کنند.

سوم، توکن‌های Bearer یک ریسک هستند. اگرچه نمونه اولیه از هدر Authorization Bearer استفاده می‌کند، گام بعدی اتصال امضای بیرونی به خودِ درخواست HTTP با استفاده از DPoP (RFC 9449) یا امضاهای پیام HTTP (RFC 9421) است تا ریسک Replay در صورت قطع شدن TLS در لایه‌های میانی حذف شود.

حل شکاف «قضاوت»

یک گواهی معتبر از نظر رمزنگاری، «اختیار» را ثابت می‌کند، اما تضمین نمی‌کند که عامل «قضاوت» درستی دارد. یک عامل مبتنی بر LLM ممکن است توسط یک وب‌سایت مخرب فریب بخورد تا ده‌ها خرید ۴۹ یورویی انجام دهد که هر کدام زیر سقف ۵۰ یورو هستند و در نهایت حساب کاربر را تخلیه کند. یک گواهی امضا شده به تنهایی نمی‌تواند وضعیت (State) یا بودجه‌های تجمعی را رصد کند.

برای جلوگیری از این اتفاق، سیستم یک دروازه قطعی (Deterministic Gateway) بین عامل و ابزار اجرا قرار می‌دهد. این دروازه کارهای زیر را انجام می‌دهد:

• تقاطع محدوده و سیاست: قابلیت‌های تفویض شده (allowed_tools, scope) را استخراج کرده و تقاطع سخت‌گیرانه آن‌ها را با سیاست‌های نقطه انتهایی (Endpoint) خودِ فروشنده محاسبه می‌کند.
• ردیابی بودجه تجمعی: یک CumulativeBudgetPolicy که توسط ذخیره‌ساز توزیع‌شده JetStream KV پشتیبانی می‌شود، مبالغ هزینه شده را در برابر سقف‌های پنجره لغزان (Rolling Window) رصد می‌کند تا از تخلیه حساب از طریق تراکنش‌های خرد ناشی از Prompt Injection جلوگیری کند.
• مجوزهای تک‌بار مصرف: اقدامات تأیید شده یک مجوز Ed25519 کوتاه‌مدت دریافت می‌کنند که به هش پارامترهای دقیق متصل است؛ بک‌اند بدون این مجوز هیچ اقدامی را اجرا نخواهد کرد.
• تأییدیه مرحله‌ای (Step-up Authorization): اگر اقدامی از آستانه خودمختار یا سقف سیاست فراتر رود، اجرا متوقف می‌شود. سیستم یک چالش خارج از باند (Out-of-band) را از طریق کانال اعلان عامل یا کیف پول کاربر ارسال می‌کند تا مراسم Passkey WebAuthn روی گوشی کاربر تکمیل شود.

موانع معماری باقی‌مانده

با وجود موفقیت نمونه اولیه، چندین پرسش «سخت» همچنان بی‌پاسخ است. پیاده‌سازی فعلی هنوز لیست‌های ابطال لحظه‌ای گواهی (مانند W3C Bitstring Status Lists)، افشای انتخابی (SD-JWT یا BBS+)، دست‌دادن‌های تعاملی کیف پول (OpenID4VP) یا اتصال‌های HTTP محدود به فرستنده را مدیریت نمی‌کند.

علاوه بر این، زنجیره‌های تفویض چندلایه پویا — جایی که یک عامل به زیر-عاملی در سازمان‌های مختلف تفویض اختیار می‌کند — و فدراسیون‌های اعتماد در دنیای باز، جزو کارهای آینده هستند.

حریم خصوصی نیز یک نگرانی است. اگر کاربر یک شناسه did:web واحد را به هر فروشنده ارائه دهد، به‌راحتی در سراسر وب قابل ردیابی و همبسته‌سازی (Correlatable) می‌شود. توسعه‌دهندگان پیشنهاد می‌کنند که شناسه‌های جفت‌شده (Pairwise) برای هر فروشنده، گام ضروری بعدی برای محافظت از گمنامی کاربر است.

سایر پرسش‌های باز عبارتند از:

• اعتماد به صادرکننده: چه کسی تصمیم می‌گیرد کدام دامنه‌ها قابل اعتماد باشند؟ در حال حاضر دروازه از یک لیست دستی TRUSTED_ISSUER_DOMAINS استفاده می‌کند. ثبت‌های اعتماد غیرمتمرکز مانند OpenID Federation مورد نیاز است.
• سرعت ابطال: عامل‌های ماشینی به سرعت ابطال بسیار بیشتری نسبت به سیستم‌های انسان‌محور نیاز دارند. سیگنالینگ مبتنی بر Push مانند OpenID Shared Signals Framework احتمالاً یک الزام خواهد بود.
• نگهداری کلید: در حالی که P-256 از Enclaveهای سخت‌افزاری پشتیبانی می‌کند، عامل‌هایی که در کانتینرهای ابری موقت اجرا می‌شوند با تهدید استخراج از حافظه روبرو هستند. TEEهای سخت‌افزاری (محاسبات محرمانه) هنوز در حال تکامل هستند.
• مسئولیت قانونی: هنوز از نظر قانونی مبهم است که وقتی یک عامل تفویض‌شده دچار خطا می‌شود، چه کسی هزینه را می‌پردازد: کاربر، توسعه‌دهنده، فروشنده یا صادرکننده گواهی.

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

برای بررسی پیاده‌سازی، توسعه‌دهندگان می‌توانند مخزن fcn06/trust_gateway را در گیت‌هاب برای تست verifier مبتنی بر Rust بررسی کنند.