برای یک عامل خودمختار، هیچ pull request ای وجود ندارد
بررسیهای امنیتی سنتی بر یک diff تکیه دارند. کسی یک pull request باز میکند. کسی آن را میخواند. کد موجود در محیط عملیاتی (production) با کدی که بررسی کردهاید مطابقت دارد.
عوامل خودمختار این مدل را از هم میپاشند.
یک عامل در زمان اجرا (runtime) برنامهریزی کرده و ابزارها را فراخوانی میکند. اقدامات را در قالب یک commit ارسال نمیکند. در حین اجرا، درباره اقدامات تصمیم میگیرد. اگر فقط کد اپلیکیشن را بررسی کنید، خطر واقعی را نادیده گرفتهاید.
یک عامل فقط کد نیست؛ بلکه یک پیکربندی زمان اجرا (runtime configuration) است. این پیکربندی شامل موارد زیر است:
• پرامپت سیستم (system prompt) • هارنس (harness) یا حلقه (loop) • سطح ابزار (tool surface) • حافظه و هویت • سیاستهای خروج شبکه (network egress policies) • ایمیجهای کانتینر (container images)
دو عامل که از یک مدل یکسان استفاده میکنند، میتوانند بر اساس این تنظیمات رفتارهای متفاوتی داشته باشند. مدل ثابت میماند، اما پیکربندی همه چیز را تغییر میدهد.
بسیاری از تیمها با پرامپتهای سیستم مانند تنظیمات ساده یک کادر متنی برخورد میکنند. آنها را در یک داشبورد ویرایش میکنند. این یک اشتباه است. تغییر تنها یک خط میتواند یک حفاظ (guardrail) را از بین ببرد. یک پرامپت قابل ویرایش، در واقع یک مسیر کد بررسینشده است.
حوادث واقعی این موضوع را ثابت میکنند:
• یک بات برای هفتهها به مالکان توصیههای غیرقانونی میکرد. • یک بات پشتیبانی به دلیل بهروزرسانی پرامپت، شروع به فحاشی به مشتریان کرد. • فایلهای مخرب از کاراکترهای نامرئی برای دور زدن قوانین استفاده کردند.
اینها شکستهای مدل نبودند؛ بلکه تغییرات پیکربندی بودند که هیچکس آنها را بررسی نکرده بود.
شما باید با پیکربندی مانند کد رفتار کنید.
پرامپتهای سیستم و پیکربندیهای هارنس خود را در سیستم کنترل نسخه (version control) قرار دهید. آنها را فقط از طریق pull requestها تغییر دهید. از diffها برای مشاهده تغییرات استفاده کنید.
برای پیکربندی مستقر شده (deployed configuration) خود از یک هش محتوا (content hash) استفاده کنید. این هش باید شامل نسخه پرامپت، شناسه مدل (model ID) و خلاصهی کانتینر (container digest) باشد. اگر پرامپت را تغییر دهید، هویت عامل تغییر میکند. شما نمیتوانید یک پرامپت را بهصورت بیصدا (silent) جایگزین کنید.
تشخیص انحراف (drift detection) را در سطح عامل اعمال کنید. فقط میزبان (host) را مانیتور نکنید؛ لیستهای سرور MCP و سیاستهای خروج (egress policies) خاص آن عامل را مانیتور کنید.
هنگام ثبت وقایع (logging)، این دو مورد را دنبال کنید:
• اندازه بافت (context size) در زمان تصمیمگیری: مدل هنگام انجام عمل، چه مقدار اطلاعات داشت؟ • پرامپت والد: در سیستمهای چندعاملی، عامل فراخوان چه چیزی ارسال کرده است؟
شما به ابزارهای جدید نیاز ندارید. از سیستم کنترل نسخه و لاگگذاری ساختاریافته (structured logging) موجود خود استفاده کنید. فقط کافی است آنها را به جای درست هدایت کنید.
آیا پرامپتهای سیستم خود را نسخهبندی و بررسی میکنید؟ یا هر کسی با دسترسی به کنسول میتواند آنها را بدون ردی تغییر دهد؟
Optional learning community: https://t.me/GyaanSetuAi
