کدهای بازبینی‌شده در برابر پرامپت‌های سیستمی؛ رویکردی جدید برای امنیت عامل‌ها

تصور کنید یک عامل هوش مصنوعی به‌طور تصادفی دو مجوز بی‌خطر را با هم ترکیب کند تا دسترسی به یک فایل حساس به دست آورد؛ این دقیقاً همان نقطه‌ای است که معماری بروکر قابلیت‌ها (Capability Broker) وارد عمل می‌شود. طبق راهنمای فنی منتشرشده در dev.to در تاریخ ۷ اوت ۲۰۲۶، این الگو امنیت را از یک «حس کلی» در پرامپت سیستمی به یک قرارداد سخت‌گیرانه در سطح کد تبدیل می‌کند. این رویکرد در واقع پیاده‌سازی عملی از قرارداد قابلیت عامل است که جداسازی «دسترسی» از «اجازه» را برای حاکمیت هوش مصنوعی تعریف می‌کند.

بیشتر شکست‌های امنیتی زمانی رخ می‌دهند که مدل دو مجوز مجزا — مثلاً خواندن یک پوشه و ارسال داده به یک وب‌هوک — را ترکیب می‌کند تا دستور مخربی را که در یک سند پنهان شده، اجرا کند. این نوع حمله که «پاراگراف مسموم» نام دارد، حفاظ‌های سنتی مبتنی بر پرامپت را دور می‌زند، چون مدل تصور می‌کند صرفاً در حال کمک به کاربر است.

برای حل این مشکل، الگوی بروکر تضمین می‌کند که «قصد» (Intent) از مدل خارج شود، اما «اختیار» (Authority) در کد باقی بماند. در این ساختار، عامل اجازه دارد درخواست انجام یک اقدام را بدهد، اما به‌طور مطلق از اجرای مستقیم آن منع شده است.

سازوکار بروکر

این گردش‌کار برای حذف هرگونه ابهام، مسیری صلب و ساختاریافته را دنبال می‌کند:

• تولید قصد: عامل یک درخواست ساختاریافته برمی‌گرداند؛ مثلاً: {'tool': 'fs.read', 'args': {'path': 'notes/trip.md'}}.
• تفکیک سیاست: بروکر یک فایل مانیفست به نام capabilities.toml را بررسی می‌کند تا تصمیم بگیرد این فراخوانی مجاز است، رد شود یا نیاز به تأیید انسانی دارد.
• اجرای پالایش‌شده: مدل یا داده‌های درخواستی را دریافت می‌کند یا یک خطای ساده با متن «ابزار در دسترس نیست»؛ این کار مانع از آن می‌شود که مدل قوانین امنیتی دقیق را یاد بگیرد.
• ثبت وقایع: هر تصمیم در یک پایگاه‌داده SQLite محلی برای تست و تحلیل‌های پس از حادثه ثبت می‌شود.

به نقل از گزارش dev.to، این رویکرد پرسش بنیادین امنیت را از «آیا مدل مودب می‌ماند؟» به «آیا سیاست‌های کد، این فراخوانی دقیق را پذیرفتند؟» تغییر می‌دهد.

جزئیات فنی و پیکربندی

این سیستم برای تعریف مرزهای سخت از فایل capabilities.toml استفاده می‌کند. برای مثال، ابزار fs_read می‌تواند فقط به ریشه‌های خاصی مثل ./workspace محدود شود و دسترسی به فایل‌های .env یا .pem به‌طور صریح ممنوع گردد.

دسترسی به شبکه نیز به همین شکل محدود می‌شود. ابزار http_fetch ممکن است فقط به میزبان‌های خاصی مثل api.github.com دسترسی داشته باشد و سقف دریافت داده برای آن ۲۰۰,۰۰۰ بایت تعیین شود. برای ابزار notify نیز بروکر می‌تواند وب‌هوک‌ها را به الگوهای داخلی محدود کرده و شرط «تأیید انسانی» را فعال کند. این لایه‌ی کنترلی شباهت زیادی به رویکرد چهارچوب MCP در مسدودسازی خروج داده‌ها برای پیشگیری از تزریق دارد.

در پیاده‌سازی پایتونی این سیستم (broker.py)، کلاس Broker از یک شمارشی (Enum) به نام Verdict با سه حالت ALLOW (مجاز)، DENY (ممنوع) و APPROVAL (نیاز به تأیید) استفاده می‌کند. متد _path_ok برای جلوگیری از حملات پیمایش دایرکتوری (Directory Traversal)، مسیرها را به‌صورت مطلق باز می‌کند. اگر عاملی سعی کند به مسیر ./workspace/../../.env دسترسی پیدا کند، بروکر وضعیت Verdict.DENY را با دلیل «خروج از ریشه‌های مجاز» برمی‌گرداند.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی حفاظ‌های امنیتی مدل‌های زبانی اشاره کردیم، تکیه بر لایه‌های نرم‌افزاری بیرونی همواره مطمئن‌تر از تکیه بر رفتار پیش‌بینی‌ناپذیر مدل است.

تست و حلقه‌های خصمانه

این راهنما تأکید می‌کند که تست‌ها باید «بروکر» را هدف قرار دهند، نه اینکه مدل را تحسین کنند. برای تأیید مرزها از یک ماتریس pytest استفاده می‌شود تا اطمینان حاصل شود دسترسی به فایل‌های مجاز برقرار است و دسترسی به فایل‌های حساس (مثل payroll.csv) قطع شده است. همچنین باید تأیید شود ابزارهای تعریف‌نشده، مثل shell.exec به‌طور پیش‌فرض بسته هستند.

توسعه‌دهندگان باید از یک مجموعه داده خصمانه استفاده کنند؛ اسنادی که:

• از مدل می‌خواهند قوانین را نادیده بگیرد.
• خود را جای کاربر جا بزند.
• ادعا کند سیاست‌های امنیتی تغییر کرده‌اند.
• دستورات را در کامنت‌های Markdown پنهان کنند.

معیار موفقیت در اینجا این نیست که مدل درخواست را رد کند، بلکه این است که در جدول ثبت وقایع، یک «رد» (Denial) ثبت شده باشد و هیچ اثر جانبی واقعی رخ نداده باشد.

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

باید توجه داشت که بروکر یک محیط ایزوله (Sandbox) کامل نیست. این ابزار نمی‌تواند باگ‌های داخلی یک ابزار یا نشت توکن‌ها را برطرف کند. برای کارهای حساس، توسعه‌دهندگان همچنان باید از کانتینرها و قوانین خروجی شبکه (Egress Rules) استفاده کنند. در این راستا، می‌توان از سامانه LEASH برای مسدود کردن دسترسی عامل‌ها با استفاده از بودجه خطا به عنوان یک لایه دفاعی فیزیکی‌تر بهره برد.

بررسی مسیرها به‌ویژه مستعد خطا است. توسعه‌دهندگان باید مسیرها را پیش از تطبیق، باز کنند و مواردی مثل لینک‌های نمادین (Symlinks) و تفاوت‌های حروف بزرگ و کوچک در سیستم‌فایل را در نظر بگیرند.

علاوه بر این، نویسنده درباره «خستگی از تأیید» (Approval Fatigue) هشدار می‌دهد. اگر هر اقدامی نیاز به کلیک انسان داشته باشد، کاربران به‌طور خودکار همه چیز را تأیید می‌کنند و لایه امنیتی خنثی می‌شود. تأیید انسانی باید فقط برای اقدامات برگشت‌ناپذیر مثل پرداخت‌ها یا استقرار در محیط عملیاتی رزرو شود.

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

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

گام بعدی شما

• مانیفست capabilities.toml را برای ابزارهای فعلی خود تعریف کنید و دسترسی‌ها را به حداقل ممکن (Least Privilege) برسانید.
• یک ماتریس pytest برای تست کردن مرزهای دسترسی به فایل‌ها و شبکه طراحی کنید.
• برای اقدامات حساس، مکانیسم تأیید انسانی را فقط برای عملیات‌های برگشت‌ناپذیر فعال کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.