تصور کنید یک عامل هوش مصنوعی بدون تأیید انسانی، دستور بازگشت وجه (Refund) را صادر می‌کند، در حالی که تمام قراردادهای فنی آن کاملاً معتبر هستند. اگر تنها خط دفاعی شما یک اسکیمای توصیفی است که می‌گوید «تأیید لازم است»، شما یک بیانیه دارید، نه یک کنترل امنیتی. طبق راهنمای فنی منتشر شده در ۷ اکتبر ۲۰۲۶، شکاف بحرانی در هوش مصنوعی عامل‌محور (Agentic AI)، فاصله میان «مرز اعلام‌شده» و «مسیر واقعی اجرا» است.
این وضعیت شبیه به این است که یک قرارداد دیجیتال را به عنوان مجموعه‌ای از قوانین خانه در نظر بگیرید. نوشتن عبارت «ورود با کفش ممنوع» روی یک تابلو، صرفاً یک اعلامیه است. اما درِ قفل‌شده‌ای که فقط برای مهمانان بدون کفش باز می‌شود، یک مرز اجرایی است. بسیاری از توسعه‌دهندگان امروز در همان مرحله تابلوی اعلانات متوقف می‌شوند و به اشتباه تصور می‌کنند مدل چون در مرحله طراحی اعتبارسنجی شده، حتماً از قوانین پیروی خواهد کرد.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد به لایه‌های توصیفی بدون نظارت سخت‌افزاری یا نرم‌افزاری، ریسک‌های عملیاتی را افزایش می‌دهد. این چالش‌ها در واقع ریشه در ابهامات عملیاتی در گردش‌کارهای AI دارند که باعث می‌شود تعریف دقیق «پایان» یا «تأیید» در یک فرآیند دشوار شود.
چهار ادعای حاکمیت
برای پر کردن این شکاف، Hlinor Agent Registry چهار سطح یا ادعای متمایز از حاکمیت را تعریف می‌کند. این‌ها ادعاهای متفاوتی هستند که هر کدام به شواهد متفاوتی نیاز دارند:
- اعلام‌شده (Declared): قراردادی که توصیف می‌کند چه اتفاقی باید بیفتد.
- اعتبارسنج‌شده (Validated): ابزاری (Checker) که ساختار قرارداد و فیلدهای ضروری را می‌پذیرد.
- اجرایی (Enforced): مسیر اجرا که پیش از هر اثر جانبی، قانون مربوطه را چک کرده و در صورت رد، عملیات را متوقف می‌کند.
- مشاهده‌شده (Observed): سوابق زمان اجرا یا تست‌هایی که نشان می‌دهند در یک مسیر خاص چه رخ داده است.
یک اسکیمای معتبر ثابت نمی‌کند که سیستم هنگام اجرا به آن مراجعه می‌کند. به همین ترتیب، یک گزارش تصمیم‌گیری (Decision Log) ثابت نمی‌کند که تمام مسیرها از گیت‌های امنیتی عبور کرده‌اند، و یک قرارداد امضاشده ثابت نمی‌کند که قوانین آن تمام ریسک‌های خاص مورد نظر شما را پوشش می‌دهد. هر یک از این‌ها مفید هستند، اما هیچ‌کدام جایگزین سطح بعدی نمی‌شوند.
جزئیات پیاده‌سازی
در معماری Hlinor Agent Registry، سیاستی مانند «عدم ثبت اطلاعات حساس مشتری در لاگ‌ها» (no-customer-pii-in-logs) صرفاً یک بستر توصیفی باقی می‌ماند، مگر اینکه یک PolicyChecker (بررسی‌کننده سیاست) مستقیماً در کد سیم‌کشی و ادغام شده باشد. کامپایلر این سامانه منابع نام‌برده در مانیفست را می‌خواند. سپس PolicyChecker لیست‌های مجاز (Allowlists)، لیست‌های مسدود (Blocklists)، الگوهای منابع و سیاست‌های تایپ‌شده‌ی پشتیبانی‌شده را ارزیابی می‌کند.
بدون یک گیت عملیاتی، این سیاست‌ها حتی یک پیام لاگ را هم بازرسی یا سانسور نمی‌کنند. مخزن کد ممکن است حاوی قراردادهایی باشد که از بازبینی یا اعتبارسنجی مستقل پشتیبانی می‌کنند، اما این‌ها لزوماً در تصمیم‌گیری‌های PolicyChecker مشارکت نمی‌کنند. قابلیت‌ها می‌توانند به عنوان یک موجودی (Inventory) کامپایل شوند بدون اینکه به یک گیت مجوز تبدیل شوند. حتی بودجه‌های اعلام‌شده و محدودیت‌های نرخ فراخوانی (Rate Limits) به‌طور خودکار توسط بررسی‌کننده اجرا نمی‌شوند. این نیاز به جداسازی لایه‌ی استدلال از اجرا است تا دسترسی‌های غیرمجاز در سطح سیستمی مهار شوند.
تست مرز اثرات جانبی
برای تست این مرزها، باید «اثر جانبی» (Side Effect) را بررسی کرد، نه فقط گزارش تصمیمات را. توسعه‌دهندگان با استفاده از بسته پایتون hlinor-registry می‌توانند با دستوراتی مثل hlinor-registry init و hlinor-registry compile --manifest registry.yaml --output bundle.json یک عامل سخت‌گیرانه را به‌صورت محلی تولید و کامپایل کنند.
به نقل از مستندات این ابزار، توسعه‌دهندگان می‌توانند توابع را با دکوراتور @governed بپوشانند. در یک مورد تست مربوط به تابع بازگشت وجه (که در برابر نسخه مخزن a9af5e5 تست شد)، سیستم خطای POLICY_SIGNAL_MISSING را چاپ کرد و با موفقیت از اجرای بدنه تابع جلوگیری کرد. این تضمین می‌کند که تعداد فراخوانی‌های پایین‌دستی صفر باقی ماند. این نتیجه شواهدی برای یک ادعای محدود ارائه می‌دهد: این فراخوانی خاص از پوشش عبور کرده و رد شده است. اما این ثابت نمی‌کند که هیچ مسیر بازگشت وجه بدون پوشش وجود ندارد یا اینکه اعتبارنامه‌ها نمی‌توانند در جای دیگری استفاده شوند.
احراز هویت در مقابل شکل ظاهری
با این حال، این سامانه هشدار می‌دهد که یک «شیء با شکلِ تأییدیه» (Approval-shaped object) با یک «تأییدیه احراز شده» متفاوت است. API سیگنال‌های مستقیم PolicyChecker ادعاهایی را می‌پذیرد که توسط فراخوان (Caller) ارائه شده است. این ابزار می‌تواند نقش کاربر، اتصال درخواست و تازگی (Freshness) آن را چک کند، اما نمی‌تواند ثابت کند که یک انسان واقعاً تأییدیه را صادر کرده است.
در آزمایش‌ها، یک سیگنال محلی که نام refund_payment:order/1234 را داشت، اجازه یک فراخوانی پوشش‌داده‌شده را داد. در حالی که استفاده از آن برای سفارش order/9999 رد شد، اما تغییر مبلغ در حالی که نام سفارش همان order/1234 باقی مانده بود، پذیرفته شد. دلیل این اتفاق آن است که سیگنال نامِ اقدام و منبع را می‌برد، نه تمام آرگومان‌های کامل بازگشت وجه را. یک رشته متنی از نقش کاربر، جایگزین یک شخص احراز شده نیست و یک شناسه سفارش، به معنای تأیید مبلغ نیست. این دقیقاً همان نقطه‌ای است که شکاف‌های امنیتی در داشبوردهای عامل‌ها رخ می‌دهد؛ جایی که تراکنش‌ها موفق به نظر می‌رسند اما در واقع احراز هویت صحیحی صورت نگرفته است.
برای اطمینان بیشتر، این سامانه مسیر آزمایشی BoundTool را ارائه می‌دهد که شامل ویژگی‌های زیر است:
- اعتبارسنجی نرمال‌شده آرگومان‌ها
- تأییدیه‌های امضاشده جداگانه و اختیاری
- کلیدهای مورد اعتماد
- محافظ‌های ضد تکرار (Replay Guards)
این کنترل‌ها باید در لحظه فراخوانی سیم‌کشی شوند؛ وجود آن‌ها در مخزن کد به‌تنهایی از یک پوشش ساده محافظت نمی‌کند.
بازبینی گردش‌کار سرتاسری
این تغییر دیدگاه، پرسش بنیادی مهندسان هوش مصنوعی را عوض می‌کند. به‌جای اینکه بپرسیم «آیا مخزن ما اسکیمایی برای این کار دارد؟»، تمرکز باید به این تغییر کند که «کدام تکه کد، در کدام مسیر این فیلد را می‌خواند و اگر قانون شکست بخورد چه اتفاقی می‌افتد؟»
برای هر گردش‌کار حساس، باید این زنجیره را به‌طور کامل ترسیم کنید:
- اثر واقعی: کدام تابع و اعتبارنامه می‌تواند دنیای بیرون را تغییر دهد؟
- گیت: رد شدن در کجا باعث توقف تابع می‌شود و آیا مسیری برای دور زدن آن هست؟
- اتصال (Binding): آیا منبع بررسی‌شده همان آرگومانی است که تابع واقعاً استفاده می‌کند؟ آیا تأییدیه، مبلغ و گیرنده را پوشش می‌دهد؟
- منبع اعتماد: چه کسی می‌تواند سیگنال‌های تأیید را صادر، بسته (Bundle) را جایگزین یا کلیدهای مورد اعتماد را تغییر دهد؟
- رفتار در شکست: در صورت نبود تأییدیه، ورودی بدشکل یا خرابی بسته، چه رخ می‌دهد؟
- شواهد: کدام تست‌های منفی نشان می‌دهند که فراخوانی پایین‌دستی واقعاً رخ نداده است؟
در رابط خط فرمان (CLI) این سامانه، عدد ۰ به معنای اجازه، ۱ به معنای رد و ۲ به معنای عدم دستیابی به تصمیم است. یک گردش‌کار «بسته در صورت شکست» (Fail-closed) تضمین می‌کند که هم رد شدن سیاست و هم خطای سیستمی (مانند یک بسته خراب)، مانع از اقدام شوند. باید توجه داشت که یک بسته خراب یک خطای عملیاتی است، نه دلیلی بر رد موفقیت‌آمیز سیاست.
این رویکرد صنعت را از ادعاهای مبهم مبنی بر «حاکمیت بر عامل‌ها» به سمت یک استاندارد مهندسی قابل تأیید می‌برد. این متدولوژی، اعتماد به پرامپت را با شواهد در مسیر اجرا جایگزین می‌کند و به مهندسان دیگر اجازه می‌دهد به‌طور مستقل امنیت اقدامات یک عامل را حسابرسی کنند.
گام بعدی شما
- بررسی کنید آیا در عامل‌های خود، لایه‌ی اعتبارسنجی اسکیمای YAML را با یک گیت اجرایی (Enforcement Gate) در کد جایگزین کرده‌اید یا خیر.
- برای توابع حساس، تست‌های منفی (Negative Tests) بنویسید تا مطمئن شوید در صورت نبود سیگنال تأیید، اثر جانبی (Side Effect) واقعاً صفر است.
- اگر از توابع حساس استفاده می‌کنید، از مدل‌های BoundTool برای امضای دیجیتال تأییدیه‌ها استفاده کنید تا از جعل سیگنال‌ها جلوگیری شود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو