تصور کنید فاصلهی میان یک پیشنهاد کد و اجرای واقعی آن در دنیای سختافزار به صفر برسد؛ پلتفرم دستگاههای توسعهدهنده گوگل (Google Developer Device Platform) دقیقاً همین اتفاق را رقم زده است. با اعطای دسترسی مستقیم به شبیهسازهای با ظرفیت بالا و دستگاههای فیزیکی، گوگل مسئلهی عاملهای هوش مصنوعی را از بحثهای تئوریکِ مهندسی پرامپت به حوزهی ملموسِ حاکمیت سیستم منتقل کرد.
سالهاست که استاندارد صنعت بر مدل «دستیار کدنویسی» استوار بود؛ مدلی که در آن هوش مصنوعی یک وصله (Patch) پیشنهاد میداد و برنامهنویس انسانی تنها دروازهبان مسئول اجرا و تأیید تغییرات بود. اما پلتفرم جدید گوگل این حائل را حذف میکند. اکنون عاملها (Agents) میتوانند مسیرهای کاربر را شبیهسازی کنند، نتایج را بررسی نمایند، عملکرد را تحلیل کنند و بر اساس مشاهدات لحظهای خود، اپلیکیشنها را اصلاح کنند.
این قابلیت، یک شکاف اعتماد خطرناک ایجاد میکند. وقتی یک عامل در محیطی فعالیت میکند که خودش در حال تغییر آن است، مشاهداتش مستقیماً بر اقدام بعدیاش اثر میگذارد. این حلقه بسیار قدرتمند است زیرا عامل را از یک «پیشنهاددهنده» به یک «محقق و اصلاحکننده» تبدیل میکند. اما طبق گزارشهای فنی، یک پرسش حیاتی باقی میماند: وقتی عامل میتواند یک سیستم واقعی را تشخیص داده و تغییر دهد، چه چیزی تعیین میکند که کدام تغییرات اجازه دارند بهطور خودکار اعمال شوند؟
همانطور که در تحلیلهای پیشین ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، دسترسی گسترده بدون نظارت، ریسکهای سیستمی را افزایش میدهد. در این پلتفرم، ریسک «اصلاح خودکار» (Autonomous Remediation) برجسته است. برای مثال، عاملی که یک باگ رندرینگ را در ۵ دستگاه مختلف پیدا کرده و اصلاح میکند، از نظر فنی موفق است، اما از نظر عملیاتی، همهی اصلاحات یکسان نیستند.
بر اساس مستندات این رویکرد، تغییرات را میتوان به سه دسته تقسیم کرد:
- تغییرات کمریسک: بهینهسازیهای ظاهری که برای استقرار خودکار ایمن هستند.
- تغییرات پرریسک: اصلاحات در بخش احراز هویت، دادههای مشتری، پرداختها یا حریم خصوصی که نیازمند تأیید انسانی است.
- شواهد مبهم: اگر باگی فقط در یکی از ۵ دستگاه ظاهر شود، اقدام درست جمعآوری شواهد بیشتر است، نه تغییر کد.
این تفکیک صرفاً مربوط به دسترسی به ابزار نیست، بلکه به کیفیت شواهد، مدیریت استثنائات و تأییدات سازمانی بازمیگردد.
پیچیدگی حاکمیت با ظهور «فایلهای مهارت» (Skill Files) بیشتر شده است؛ دستورالعملهای بازاستفادهپذیری که به عاملها میآموزند چگونه کارهایی مثل استقرار اپلیکیشن یا تشخیص حوادث را انجام دهند. مطالعهای تحت عنوان Towards a Risk Assessment of Malicious Skill Files in Coding Agents نشان میدهد که این دستورالعملها میتوانند به بردارهای حمله تبدیل شوند.
پژوهشگران ۲۸۲۶ فایل مهارت خصمانه را روی Gemini CLI و Qwen Code در بیش از ۵۶۰۰ اجرا آزمایش کردند. نتایج تکاندهنده بود:
- Gemini CLI در حدود ۹۶٪ موارد، رفتارهای مخرب جاسازی شده در مهارتها را اجرا کرد.
- Qwen Code در ۷۲٪ تا ۷۴٪ موارد از دستورات مخرب پیروی کرد.
- کمتر از ۲٪ آزمایشها به این نتیجه رسید که این مهارتها یک مشکل امنیتی هستند.
وقتی عاملها به دسترسی ترمینال، مجوزهای سیستمفایل یا ابزارهای پروتکل زمینه مدل (Model Context Protocol - MCP) مجهز میشوند، این فایلهای مهارت دیگر مستندات غیرفعال نیستند، بلکه شبیه به وابستگیهای نرمافزاری با حقوق اجرای ممتاز عمل میکنند. بنچمارک AgentJailbreak این موضوع را برجسته میکند زیرا آرتیفکتهای ارزیابی آن عمومی است و اجازه میدهد تیمها رفتار عاملها را در مواجهه با دستورات مشکوح بررسی کنند.
برای حل این بحران، یک مرز معماری جدید لازم است. پلتفرم گوگل و مطالعهی فایلهای مخرب، دو بخش از یک معماری نوظهور را نشان میدهند: «مهارت» به عامل میگوید چگونه کاری را انجام دهد، اما «پلتفرم دستگاه» محیط اجرای آن را فراهم میکند. تکیه بر دستورالعملهای پنهان در پرامپتهای مدل دیگر پایدار نیست.
صنعت اکنون به تفکیک میان «قابلیت عامل» (آنچه میتواند انجام دهد) و «قضاوت سازمانی» (آنچه باید انجام دهد) نیاز دارد. این هستهی اصلی مشخصات بستهی قضاوت (Judgment Pack Specification) است. هدف این است که معیارهای تصمیمات حساس، از دستورالعملهای اجرایی جدا شوند.
در این گردشکار پیشنهادی، عامل همچنان استقلال بالایی در تحقیق و پیشنهاد اصلاحات دارد، اما تصمیم نهایی از این مسیر میگذرد:
مهارتها $\rightarrow$ عامل $\leftrightarrow$ محیط دستگاه $\rightarrow$ شواهد $\rightarrow$ قضاوت $\rightarrow$ وضعیت $\rightarrow$ اجرا/تأیید
به عنوان مثال، یک سازمان میتواند قانونی وضع کند که هر تغییری در کد احراز هویت، در صورت ناقص بودن اعتبارسنجی حریم خصوصی، حتماً باید توسط انسان بررسی شود. حتی اگر مشکل در ۴ دستگاه از ۵ دستگاه حل شده باشد و عملکرد ۱۸٪ بهبود یابد، معیارهای سازمانی بر اعتماد عامل یا معیارهای عملکردی اولویت دارند.
با تبدیل آرتیفکتهای قضاوت به فرمتهای اعلامی (Declarative) و نسخهبندی شده، ویژگیهای اعتماد آنها با «مهارتها» متفاوت میشود. این کار باعث میشود تحلیل شکستها آسانتر شود: آیا عامل شواهد غلط جمع کرد؟ محیط دستگاه مشاهدهای گمراهکننده داشت؟ یا خودِ ارزیاب نقص داشت؟
درسهایی از دنیای متنباز نیز در این مسیر کمککننده است. مطالعهای روی ۲۹۶۲۴ مخزن گیتهاب نشان داد پروژههایی که سیاستهای صریح برای AI داشتند، به جای ممنوعیت، بر پنج محور تمرکز کردند:
- شفافیت
- مسئولیتپذیری
- انتساب
- محدودیتها
- اجرا
پروژههایی با این مرزهای صریح، تعاملات بازبینی غنیتر و کیفیت بالاتری داشتند. این دقیقاً همان چیزی است که معماری عاملها به آن نیاز دارند: ردیابی منشأ مهارت، شخص تأییدکننده، شواهد پشتیبان و مالک معیارهای تصمیمگیری.
پلتفرم گوگل محیطی ایدهآل برای تست این جداسازی است. با مقایسه دو معماری — یکی که در آن عامل خودش تصمیم میگیرد اصلاحیه قابل قبول است و دیگری که معیارها خارجی هستند — توسعهدهندگان میتوانند بفهمند آیا قابلیت و قضاوت را میتوان در یک حلقهی بازخورد واقعی جدا نگه داشت یا خیر.
در معماری دوم، یک اصلاحیه قطعی و کمریسک میتواند بهطور خودکار اجرا شود، اما تغییرات حساس امنیتی به بازبینی انسانی نیاز دارند. نتایج متناقض بین دستگاهها میتواند منجر به تستهای بیشتر شود و نبود اعتبارسنجیهای اجباری میتواند از نهایی شدن تصمیم جلوگیری کند. این رویکرد از ترکیب «جمعآوری شواهد» و «منطق تصمیمگیری» در یک پرامپت بزرگ و کدر جلوگیری میکند و سیستم را قابلفهمتر میسازد.
گام بعدی شما
- اگر از عاملهای کدنویسی استفاده میکنید، دسترسیهای ترمینال و فایلسیستم آنها را بازبینی کنید و از اعطای مجوزهای گسترده بپرهیزید.
- برای سازمانهای توسعهدهنده، تدوین یک «بستهی قضاوت» (Judgment Pack) برای تفکیک معیارهای امنیتی از دستورات اجرایی را در اولویت قرار دهید.
- بنچمارک AgentJailbreak را بررسی کنید تا متوجه شوید چگونه دستورالعملهای به ظاهر مفید میتوانند رفتارهای مخرب را به مدل تزریق کنند.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو