تصور کنید یک عامل هوش مصنوعی در یک لحظه دچار توهم شود و به جای خرید ۱۰ عدد قطعه، ۱۰ هزار عدد سفارش دهد و حساب بانکی شرکت شما را خالی کند. برای جلوگیری از این کابوس، باید مرزی نفوذناپذیر بین «فکر کردن» و «عمل کردن» مدل ایجاد کرد.
به نقل از مستندات منتشر شده در ۹ سپتامبر ۲۰۲۶، پیادهسازی جدیدی به نام trust_gateway پیشنهاد میدهد که یک جداسازی معماری سختگیرانه بین نحوه تفکر هوش مصنوعی و نحوه عمل آن ایجاد کند. این سیستم تضمین میکند که فارغ از میزان اعتمادبهنفس یک مدل زبانی بزرگ (LLM) درباره یک تراکنش — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — هیچ دستوری که با قراردادهای دوجانبه پیشامضا شده در تضاد باشد، اجرا نشود.
این تحول در حالی رخ میدهد که عاملهای خودمختار از فراخوانی ابزارهای ساده به سمت یک «اقتصاد عاملی» (Agent Economy) کامل حرکت میکنند؛ جایی که ماشینها با سرعت خیرهکننده، مستقلاً مذاکره و پرداخت میکنند. همانطور که در تحلیل قبلی ما دربارهی Pangram و تلاشهای آن برای ساخت لایه اعتماد هوش مصنوعی اشاره کردیم، تمرکز اکنون از همراستاسازی مدلها (Model Alignment) به سمت اجرای رمزنگاریشده (Cryptographic Enforcement) تغییر کرده است. در دنیایی که شرکتها نمیتوانند مدل طرف مقابل را بازرسی کنند، آنها به راهی نیاز دارند تا به خروجی اعتماد کنند، بدون آنکه لزوماً به خودِ هوش مصنوعی اعتماد کنند.
زمینه و ضرورت اعتماد عاملی
در حال حاضر، اکثر تعاملات عاملها با APIها بر پایه «اعتماد کورکورانه» است. وقتی عامل شرکت A با API شرکت B صحبت میکند، شرکت B معمولاً همان اعتمادی را میدهد که به یک اسکریپت داخلی میدهد و امیدوار است پرامپت سیستمی مدل را کنترل کرده باشد. اما یک LLM نمیتواند تضمین رسمی و ریاضی درباره رفتار خود بدهد.
درون دیوارهای یک شرکت، این یک شرطبندی معقول است. اما در تعاملات بین طرفهای قرارداد، این یک ریسک و مسئولیت حقوقی (Liability) است. یک تزریق پرامپت (Prompt Injection)، یک تغییر در بافتار (Context Shift) یا حتی یک توهم (Hallucination) ساده در سمت طرف مقابل — وقتی مدل با اطمینان چیزی میگوید که اصلاً وجود ندارد، شبیه دوستی که خاطرهای را اشتباه تعریف میکند — میتواند فوراً به یک تراکنش غیرمجاز تبدیل شود. پرسش بنیادی برای یک اقتصاد عاملی کارآمد این است: چه چیزی بهطور عینی مانع از آن میشود که عامل یک سازمان، کاری را انجام دهد که سازمان دیگر هرگز با آن موافقت نکرده است؟ این چالش دقیقاً همان نقطهای است که شکست نظارتهای استاتیک در برابر سیستمهای پویا را آشکار میکند.
معماری دو صفحهای
فرضیه اصلی این است که استدلال و اجرا باید در لایههای متفاوتی زندگی کنند تا خطاهای احتمالی مدل یا حملات تزریق پرامپت به تراکنشهای مالی غیرمجاز تبدیل نشوند.
صفحه معنایی (Semantic Plane) بخش احتمالی (Probabilistic) عملیات را مدیریت میکند. اینجا جایی است که مدلهای زبانی متنهای بدون ساختار را تحلیل میکنند، هدف طرف مقابل را میفهمند، ابزارها را کشف میکنند و اقدامات بعدی محتمل را پیشنهاد میدهند. نکته حیاتی این است که این لایه هیچ اعتبار اجرایی (Execution Credentials) ندارد و نمیتواند وضعیت سیستم را تغییر دهد. این بخش «نامنظم» است که مدلها در آن مهارت دارند، اما چون این بافتار قابل دستکاری است، هرگز اجازه ندارد مرز اختیارات خود را تعیین کند.
صفحه کنترل (Control Plane) با زبان Rust و بهصورت قطعی (Deterministic) ساخته شده و هیچ مدل یادگیری ماشینی در آن دخالت ندارد. این لایه قصد مدل را تفسیر نمیکند؛ در عوض، اقدام پیشنهادی را با واقعیتهای سخت میسنجد. اگر اقدام تایید شود، صفحه کنترل یک مجوز اجرای کوتاهمدت و یکبار مصرف (Execution Grant) را با استفاده از امضاهای Ed25519 صادر میکند. این رویکرد در واقع تکاملی از جایگزینی تاییدات استاتیک با امتیازدهی پویا برای دستیابی به انطباق واقعی در محیطهای عملیاتی است.
نردههای ایمنی رمزنگاریشده
برای جلوگیری از دستکاری، سیستم از استاندارد RFC 8785 برای یکسانسازی JSON (JCS) و هشینگ SHA-256 استفاده میکند. طبق گزارش توسعهدهندگان، این سازوکار تضمین میکند که اگر عاملی سعی کند شماره حساب یا مبلغ را پس از تایید تغییر دهد، عدم تطابق هش باعث رد فوری درخواست میشود. هر مجوز دارای یک Nonce یکبار مصرف است تا از حملات بازپخش (Replay Attacks) جلوگیری شود.
اختیار اجرا در تلاقی سختگیرانه سه مرز مستقل تعریف میشود:
- شرایط مذاکره شده (دوجانبه): اینها قابلیتهای مورد توافق متقابل هستند، شامل سقف تراکنشها، نوع ارز و محدوده جغرافیایی.
- سیاست سازمانی (محلی): اینها محدودیتهای داخلی میزبان هستند، مانند سقف تعداد درخواست در دقیقه (Rate Limits)، ساعات خاص عملیاتی و پنجرههای تعمیر و نگهداری.
- هویت عامل (رمزنگاریشده): این اثباتی است که نشان میدهد عامل دقیقاً همان کسی است که ادعا میکند، و از طریق did:web و کلیدهای فعال تایید میشود.
مکانیسمهای ایمنی لایه صفر
این درگاه یک حفاظ «لایه صفر» برای جلوگیری از حلقههای بینهایت و اتمام منابع (Resource Exhaustion) که در سامانههای چندعاملی رایج است، پیاده کرده است. این لایه پیش از ارزیابی هرگونه سیاست تجاری عمل میکند:
- تشخیص چرخه: اگر ابزار یا عاملی در حال حاضر در پشته فراخوانی (Call Stack) فعال باشد، سیستم درخواست را رد میکند تا از حلقههای تکراری A↔B جلوگیری شود.
- سقف عمق: حداکثر ۱۰ گام (Hop) برای هر وظیفه بهصورت پیشفرض اجبار میشود.
- سقف فرکانس: محدودیت تعداد فراخوانی برای هر ابزار تعریف میشود، مثلاً حداکثر ۳ بار فراخوانی در هر وظیفه.
- یکپارچگی نشست: درگاه پشته فراخوانی معتبر خود را بر اساس Trace ID نگه میدارد. هرگونه تاریخچه جعلی یا ناقص (Truncated) که توسط عامل ارائه شود، شناسایی و رد میشود.
قراردادهای تعامل دوجانبه (NICP)
برای تعاملات کسبوکار با کسبوکار (B2B)، این چارچوب از قراردادهای تعامل دوجانبه (NICP) استفاده میکند. این رویکرد از چتباتهای ساده مصرفکننده که سبد خرید را بررسی میکنند، فراتر رفته و به سیستمی تبدیل میشود که در آن دو کسبوکار اجازه میدهند عاملهایشان تحت شرایط مذاکره شده درباره مسئولیت (Liability) و پرداخت با هم تعامل کنند.
دو طرف که از طریق did:web شناسایی شدهاند، توافقی را روی قابلیتها و محدودیتها تنظیم میکنند. آنها این توافق را با استفاده از RFC 8785 یکسانسازی و هش میکنند و هر دو طرف هش را با Ed25519 امضا میکنند. در زمان اجرا، هر پیشنهاد با این قرارداد فعال سنجیده میشود. برای مثال، اگر یک مدل ۱۰۰٪ مطمئن باشد که باید سفارشی به مبلغ ۳۰ هزار یورو ثبت کند، اما قرارداد دوجانبه سقف سفارشات خودکار را ۲۵ هزار یورو تعیین کرده باشد، صفحه کنترل پیش از آنکه درخواست حتی به پایگاه داده برسد، آن را رد میکند.
ابزارها و سانسور دادهها
پروژه شامل trustctl است؛ یک ابزار خط فرمان (CLI) که به عنوان نقطه اجرای سختگیرانه عمل میکند. این ابزار طرحهای JSON ابزارها (JSON Schemas) را میخواند و آنها را به پرچمهای CLI متصل میکند. این ابزار هشهای ورودی یکسانسازی شده را محاسبه کرده و پاسخهای درگاه را به کدهای خروجی POSIX تبدیل میکند:
- ۰: موفقیت
- ۱: خطای طرح (Schema failure)
- ۱۲۶: رد سیاست امنیتی (Policy denied)
- ۱۲۷: ابزار ناشناخته
همچنین یک سیستم سانسور خروجی (Egress Redaction) برای محافظت از دادههای حساس وجود دارد. این سیستم از پاکسازی با Regex برای ایمیلها، شماره کارتها، توکنهای Bearer و کلیدهای API استفاده میکند. این سیستم برای اشیاء تودرتو از پیمایش بازگشتی JSON استفاده کرده و بسته به اینکه فراخوان یک عامل خارجی است یا یک بازرس داخلی، ماسکهای متفاوتی (Audience-aware masking) اعمال میکند.
چالشهای پیشرو و محدودیتها
با وجود اینکه کد واقعی است و در گیتهاب منتشر شده، نویسنده به چندین چالش اشاره کرده است که مانع از تبدیل شدن آن به یک محصول نهایی یا استاندارد میشود:
- تأخیر (Latency): سربار یکسانسازی، امضا و گامهای درگاه قابل توجه است. صدور کامل مجوز (Grant-minting) ممکن است برای عملیاتهای خواندن با فرکانس بالا، بیش از حد سنگین باشد.
- تکامل طرحها (Schema Evolution): در حال حاضر هیچ روش تعریف شدهای برای اینکه یک قرارداد دوجانبه چگونه باید تغییرات طرحهای بکاند را بدون شکستن گردشکارهای فعال مدیریت کند، وجود ندارد.
- اعتبارسنجی امنیتی: سیستم هنوز تحت حسابرسی امنیتی خارجی یا تست نفوذ (Penetration Testing) برای مراسمهای رمزنگاری یا ماشینهای وضعیت (State Machines) قرار نگرفته است.
- توازن انعطاف و سختگیری: یافتن نقطه تعادل بین دادن فضای کافی به عامل برای حل مسائل و حفظ نردههای ایمنی سختگیرانه، همچنان یک پرسش باز است.
این معماری فرض بنیادی ایمنی عاملها را تغییر میدهد. بهجای تلاش برای «سربهراه کردن» مدلها از طریق پرامپتهای سیستمی، با هوش مصنوعی بهعنوان یک پیشنهاددهنده غیرقابلاعتماد و با درگاه Rust بهعنوان تنها منبع حقیقت برخورد میکند. برای توسعهدهندگان، این یعنی انتقال منطق امنیتی از پرامپت به زیرساخت.
گام بعدی شما
- اگر در حال استقرار عاملها در محیط عملیاتی هستید، مخزن fcn06/trust_gateway در گیتهاب را برای بررسی مدل تهدید و پیشنویس مقاله سفید (Whitepaper) بررسی کنید.
- منطقهای امنیتی را از پرامپتهای سیستمی خارج کرده و به لایههای کدنویسی قطعی (Deterministic) منتقل کنید.
- برای تعاملات بینسازمانی، استانداردهای امضای دیجیتال مانند Ed25519 را در معماری خود بگنجانید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو