تصور کنید ابزاری را نصب می‌کنید که در لحظه اول تأیید شده است، اما درست پیش از اجرا، یک کد مخرب جایگزین آن می‌شود. یک امضای نصب تأیید شده، در واقع یک بررسی در یک نقطه زمانی خاص است که به محض به خطر افتادن حافظه پنهان (Cache) یا جایگزینی یک فایل باینری در حافظه، شکست می‌خورد. اگر از عامل‌های هوش مصنوعی برای اتوماسیون کارهای حساس استفاده می‌کنید، باید بدانید که امضای دیجیتال در زمان نصب، تنها یک چک‌لیست لحظه‌ای است و امنیت واقعی در زمان اجرا (Runtime) تعریف می‌شود. پروتکل Pilot با تغییر تمرکز امنیتی از «منشأ آرتیفکت» به «محیط اجرا»، تضمین می‌کند که ابزارهای شخص ثالث، فارغ از منشأ آن‌ها، تحت محدودیت‌های سخت‌گیرانه قرار گیرند.
بسیاری از معماری‌های فعلی عامل (Agent) — شبیه دستیاری که دستورات شما را اجرا می‌کند اما هر بار ابزارهای جدیدی را از اینترنت می‌گیرد — دچار آسیب‌پذیری TOCTOU (Time-of-Check-to-Time-of-Use) هستند. به این معنا که بین لحظه «بررسی اعتبار» و «استفاده از ابزار»، یک شکاف زمانی وجود دارد. یک عامل ممکن است ابزاری را در هنگام نصب تأیید کند، اما تا زمان اجرای آن ابزار، یک ترفند Symlink یا یک کانال به‌روزرسانی آلوده می‌تواند باینری اصلی را جایگزین کند. از آنجایی که عامل‌ها در حلقه‌های با سرعت بالا عمل می‌کنند — یعنی نصب، خواندن و اقدام بدون بازبینی انسانی — این شکاف‌ها پنجره‌های بحرانی برای بهره‌برداری مهاجمان ایجاد می‌کنند.
مدل تهدید در زمان اجرا (Runtime Threat Model)
وقتی عامل‌ها ابزاری را نصب می‌کنند، در واقع در حال افزودن یک زنجیره تأمین به حلقه ابزارهای خود هستند. هر نصب، کدی را که کاربر ننوشته است به محیط اجرای اضافه می‌کند که مسئولیت آن بر عهده کاربر است. ریسک‌های اصلی در این مدل عبارتند از:
- تزریق پرامپت (Prompt Injection): ابزاری محتوایی را برمی‌گرداند که رفتار عامل را منحرف کرده و آن را به مسیر دیگری هدایت می‌کند.
- کدهای مخرب: اپلیکیشن با خواندن فایل‌های غیرمجاز، باز کردن سوکت‌ها یا مصرف بیش از حد حافظه و توصیف‌گرهای فایل (File Descriptors)، رفتار غیرطبیعی نشان می‌دهد.
- استخراج داده‌ها (Data Exfiltration): ابزارهایی که دسترسی به شبکه دارند می‌توانند بافت (Context) عامل را به خارج از محیط ارسال کنند.
- سوءاستفاده از منابع: یک اپلیکیشن معیوب که مدام کرش کرده و دوباره اجرا می‌شود، می‌تواند منجر به حمله منع سرویس (DoS) علیه میزبان شود.
طبق راهنمای فنی منتشر شده در ۱۶ اوت ۲۰۲۶، این تهدیدات ثابت می‌کنند که عبارت «تأیید شده در زمان نصب» ناکافی است. برای کاهش این خطرات، پروتکل Pilot از چهار کنترل runtime خاص استفاده می‌کند تا شعاع تخریب (Blast Radius) را محدود کند:
۱. تأیید مستمر آرتیفکت‌ها
به جای اعتماد به یک بررسی تک‌باره در زمان نصب، سیستم هش sha256 باینری را تثبیت (Pin) کرده و یک امضای ed25519 را همراه آن نگه می‌دارد. دیمون (Daemon) سیستم، درست پیش از هر بار ایجاد فرآیند (Spawn)، هش باینری را مجدداً چک می‌کند. اگر باینری به یک Symlink تبدیل شده باشد یا هش آن دیگر با مقدار تثبیت شده مطابقت نداشته باشد، سیستم اجرا را رد می‌کند. این مکانیسم شکاف TOCTOU را با شناسایی باینری‌هایی که بین اسکن نصب و زمان اجرا جایگزین شده‌اند، می‌بندد.
۲. مجوزهای محدود به دامنه (Grant-Scoped Permissions)
در این مدل هیچ «قدرت پیش‌فرض» یا Ambient Authority وجود ندارد. هر اپلیکیشن باید مجوزهای مورد نیاز خود — مانند دسترسی به شبکه یا ورودی/خروجی فایل (File I/O) — را در یک مانیفست اعلام کند. یک کارگزار (Broker) این مجوزها را در زمان اجرا اعمال می‌کند؛ به این معنی که یک اپلیکیشن نمی‌تواند صرفاً به دلیل پیوستن به سیستم به یک منبع دسترسی داشته باشد، بلکه باید یک مجوز صریح و پذیرفته شده داشته باشد. این امر از حالت شکست رایج در معماری‌های پلاگین جلوگیری می‌کند، جایی که پیوستن به سیستم به معنای اعتماد کامل است.
۳. نظارت بر فرآیند (Process Supervision)
محیط اجرا به جای یک لانچر ساده، نقش یک ناظر (Supervisor) را ایفا می‌کند که مالک چرخه حیات فرآیند است. این ناظر تمام مراحل را مدیریت می‌کند، از جمله:
- راه‌اندازی خودکار (Auto-spawning): استقرار خودکار بلافاصله پس از نصب.
- تشخیص حلقه‌های کرش: پیاده‌سازی استراتژی Exponential Backoff برای جلوگیری از تخلیه منابع میزبان.
- تعلیق (Suspension): توقف خودکار اپلیکیشن‌ها پس از شکست‌های مکرر.
- محدودیت منابع: سقف‌های سخت‌گیرانه برای توصیف‌گرهای فایل و فضای آدرس (Address-space).
- قابلیت حسابرسی: ارسال تمام رویدادهای چرخه حیات به یک لاگ حسابرسی چرخشی.
۴. سطوح فراخوانی تایپ‌شده (Typed Call Surfaces)
برای جلوگیری از ایجاد نقاط اتصال پنهان یا لوله‌کشی‌های REST مخفی، سیستم از یک سطح فراخوانی سخت‌گیرانه JSON-in/JSON-out استفاده می‌کند. مجموعه 'exposes' در مانیفست، کل سطح قابل فراخوانی را تعریف می‌کند. کارگزار هر درخواستی را که صریحاً در آن لیست نشده باشد، حتی اگر درخواست از طرف خودِ دیمون باشد، رد می‌کند. با حذف مرورگرها و نقاط اتصال پنهان، سطح حمله به اندازه‌ای کوچک می‌ماند که بتوان آن را به صورت واقع‌بینانه حسابرسی کرد.
مطالعه موردی: فروشگاه اپلیکیشن پروتکل Pilot
در یک پیاده‌سازی عملی، فروشگاه اپلیکیشن پروتکل Pilot از یک حلقه «رد پیش‌فرض» (Deny-by-default) پیروی می‌کند: کشف، بازرسی، نصب و فراخوانی. گردش کار به شرح زیر است:
۱. کشف (Discover): دستور pilotctl appstore catalogue لیست ابزارهای قابل نصب را نمایش می‌دهد.
۲. بازرسی (Inspect): دستور pilotctl appstore view io.pilot.cosift به کاربر اجازه می‌دهد پیش از تایید، فروشنده، متدها و مجوزها را بررسی کند.
۳. نصب (Install): دستور pilotctl appstore install io.pilot.cosift باعث می‌شود دیمون ابزار را دریافت کرده، sha256 و امضا را تأیید کند و ابزار را به صورت خودکار اجرا (Auto-spawn) کند.
۴. فراخوانی (Call): دستور pilotctl appstore call io.pilot.cosift cosift.search '{"q":"raft consensus","k":"5"}' یک متد تایپ‌شده را اجرا می‌کند.
امنیت در تمام لایه‌ها توزیع شده است. خودِ کاتالوگ با یک کلید اختصاصی ed25519 امضا شده است (که نیمه عمومی آن در کلاینت کامپایل شده)، تا از تغییر مسیر نصب‌ها به بسته‌های مخرب توسط یک CDN آلوده جلوگیری شود. ارتباطات اپلیکیشن-به-اپلیکیشن توسط دو گیت کنترل می‌شود: گیت 'exposes' (برای تأیید وجود متد) و گیت 'grant' (برای تأیید اینکه فراخواننده مجوز ipc.call را دارد).
این سیستم همچنین شامل یک اپلیکیشن فایروال در زمان اجرا به نام AEGIS است تا تزریق پرامپت را پیش از آنکه عامل محتوا را بخواند، مسدود کند و همین کلاس دفاعی را در لایه ورودی اعمال نماید.
یک اعتراف حیاتی در مستندات این است که سندباکسینگ در سطح سیستم‌عامل، مانند landlock یا seccomp، هنوز ادغام نشده است. اجرای فعلی به جای یک سندباکس کامل هسته (Kernel)، بر rlimits و کارگزار syscall/IPC تکیه دارد. این تمایز برای کاربرانی که اپلیکیشن‌های شخص ثالث را در محیط‌های واقعاً خصمانه اجرا می‌کنند، حیاتی است.
چک‌لیست امنیتی برای محیط‌های اجرای عامل
اگر در حال ساخت یا استفاده از سرورهای MCP، پلاگین‌ها یا حلقه‌های ابزار سفارشی هستید، باید سیستم خود را بر اساس این سوالات حسابرسی کنید:
- حفاظت از کلیدها: چه کسی آرتیفکت‌ها را امضا می‌کند، چه کسی می‌تواند کلیدها را بچرخاند (Rotate) و آیا سیستم در صورت شکست در تأیید اعتبار، به صورت Fail-closed (بسته شدن کامل) عمل می‌کند؟
- اقتدار: آیا مدل مجوزها با مانیفست مطابقت دارد یا قدرت پیش‌فرض (Ambient Authority) وجود دارد؟
- نظارت: آیا مالک فرآیندی وجود دارد که منابع را محدود کرده و حلقه‌های کرش را شناسایی کند؟
- ابطال: اگر یک اپلیکیشن خصمانه شود، آیا حذف آن یک عملیات واقعی است یا یک توهم؟
- قابلیت حسابرسی: آیا می‌توانید تمام کارهایی که اپلیکیشن می‌تواند انجام دهد را فهرست کنید و اگر این لیست تغییر کند، متوجه شوید؟
این تغییر در رویکرد، فرض بنیادی امنیت عامل را تغییر می‌دهد. این حرکت صنعت را از «اعتماد به فروشنده» به سمت «محدود کردن فرآیند» می‌برد. برای توسعه‌دهندگان، این بدان معنای آن است که امنیت یک پشته (Stack) عامل دیگر توسط شهرت نویسنده پلاگین تعریف نمی‌شود، بلکه توسط سخت‌گیرانه بودن کارگزار محیط اجرا (Runtime Broker) تعیین می‌گردد. در کنار این محدودیت‌های اجرایی، استفاده از متدولوژی GitOps برای مدیریت ابزارها می‌تواند از تغییرات ناخواسته در پیکربندی عامل‌ها جلوگیری کرده و پایداری زیرساخت را تضمین کند.
هدف این است که اطمینان حاصل شود تأیید در زمان نصب تصمیم می‌گیرد چه چیزی وارد شود، اما سندباکسینگ در زمان اجرا تصمیم می‌گیرد که آن ابزار چقدر می‌تواند آسیب بزند. برای تست این مدل، کاربران می‌توانند محیط را از طریق دستور curl -fsSL https://pilotprotocol.network/install.sh | sh مستقر کرده و مانیفست ابزارهای نصب شده را برای مشاهده عملکرد ناظر بررسی کنند.
اما امنیت در لایه سخت‌افزار ابعادی پیچیده‌تر دارد؛ برای درک نحوه ایزوله‌سازی در سطح تراشه، تحلیل ما درباره‌ی معماری‌های TEE را بخوانید.
گفتگو