تصور کنید یک مهندس تازهکار کلید دسترسی به تمام سرورهای حیاتی شرکت را داشته باشد؛ خطر اصلی نه در نیت او، بلکه در احتمال یک اشتباه کوچک است که کل شبکه را فلج کند. دقیقاً همین ریسک در مورد عاملهای هوش مصنوعی (AI Agents) است. یک عامل هوش مصنوعی میتواند در عرض چند ثانیه یک سرویس پرداخت معیوب را شناسایی کند، اما دادن دسترسی ریشه (Root) مستقیم به یک خوشهی عملیاتی (Production Cluster)، نسخهای برای فاجعه است. یک خطای منطقی ساده در مدل میتواند به یک بحران زیرساختی گسترده تبدیل شود. این چالشها یادآور ریسکهای جدیتری هستند که در تحلیلهای اخیر دیدیم، جایی که برخی مدلهای پیشرفته توانایی خروج از محیطهای ایزوله و دسترسی غیرمجاز را نشان دادند و امنیت زیرساختها را به مخاطره انداختند.
به نقل از مستندات پروژهی MANDATE، این سامانه که برای هکاتون Agents of SigNoz ساخته شده است، با ایجاد یک دروازهی قطعی (Deterministic Gateway) بین منطق مدل و ابزارهای تغییر سیستم، تعادلی بین کارایی عامل و امنیت زیرساخت برقرار میکند. این پروژه در واقع یک لایهی «اقتدار» (Authority Layer) است که برای مدیریت تنش میان کاربردی بودن عامل و امنیت سیستم طراحی شده است. اکثر شرکتها امروز با یک انتخاب دوتایی روبرهاند: یا عامل را به یک ناظر صرفاً خواندنی (Read-only) تبدیل کنند یا اعتبارنامههای خطرناکی مثل kubectl را به آن بدهند. این وضعیت یک شکاف حاکمیتی عظیم ایجاد میکند که در آن «استدلال» مدل در لاگها دیده میشود، اما «اختیار» آن یک ریسک صفر و یک (همه یا هیچ) است.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای عاملمحور اشاره کردیم، تفکیک سطح دسترسی از لایهی تصمیمگیرنده، تنها راه رسیدن به اتوماسیون ایمن است. MANDATE هویت، محدوده منابع و سطوح ریسک را از پیکربندیهای امضا شده (Signed Configuration) استخراج میکند، نه از پرامپتهای مدل هوش مصنوعی. این یعنی دروازه، تصمیمات مربوط به دسترسی را خارج از مدل نگه میدارد. ممکن است یک عامل گام بعدی مفیدی را پیشنهاد دهد، اما این دروازهی قطعی است که ریسک، بودجه و سیاست تاییدیه را تعیین میکند.
ساختار مرجع این سامانه شامل مؤلفههای زیر است:
- Gateway: یک بکاند با Python/FastAPI برای مدیریت منطق و اعتبارنامهها.
- Console: کنسول مدیریت بر پایه Next.js برای نظارت و کنترل عملیاتی.
- Approvals: یکپارچگی با اعلانهای Slack برای اعتبارسنجی انسانی در چرخه (Human-in-the-loop).
- Infrastructure: بارهای کاری Kubernetes در محیط Kind و استقرار SigNoz که از طریق Foundry آمادهسازی شده است.
- Telemetry: استفاده از OpenTelemetry برای سیگنالها و انتقال دادهها.
برای جلوگیری از نشت اعتبارنامهها، کلیدهای سرویساکانت SigNoz و دسترسیهای کوبرنتیز صرفاً در سمت دروازه (Gateway) باقی میمانند. عاملها از طریق پروتکل زمینهٔ مدل (Model Context Protocol - MCP) یا REST متصل میشوند؛ به این معنا که هوش مصنوعی هرگز کلیدهایی را که برای اجرای دستورات استفاده میکند، «نمیبیند». این معماری باعث میشود درخواست عامل از مجوز سیستم کاملاً تفکیک شود.
این سیستم SigNoz را از یک داشبورد غیرفعال (که فقط دادهها را نمایش میدهد) به یک ارائهدهندهی فعال شواهد تبدیل میکند. سیگنوز دیگر فقط جایی نیست که اثرات (Traces) پس از وقوع حادثه به آن ارسال شوند؛ بلکه اکنون حادثه را تشخیص داده و شواهد محدودی را برای تصمیمگیری تامین میکند. این رویکرد تکاملی در واقع گامی فراتر از استفاده از Llama 3.1 برای تحلیل خودکار ریشهی خطاها بر اساس تلهمتری SigNoz است و امکان اجرای ایمن اصلاحات را فراهم میکند.
در یک دموی عملی، یک انتشار کنترلشده، استقرار payment-service را به یک ایمیج قدیمیتر و معیوب تغییر داد که باعث ایجاد شکست در پرداختها (Checkouts) شد. دو قانون خاص برای نظارت بر این وضعیت تعریف شده است:
- هشدار متریک: یک هشدار بومی در SigNoz نرخ شکست پرداختها را در بازه ۵ دقیقه بررسی میکند. شرط این هشدار به این صورت است:
> 100 * sum(rate("checkout_requests_failed_total"[5m])) / clamp_min(sum(rate("checkout_requests_total"[5m])), 1) > 5. این مورد به عنوان نقض بحرانی SLO علامتگذاری میشود. - قانون مبتنی بر اثر (Trace): قانونی که یک Span با نام
mandate.release.deployرا شناسایی میکند که در آن مقدارmandate.release.regressed = trueباشد.
زمانی که هر یک از این هشدارها فعال شود، SigNoz یک وبهوک را به MANDATE ارسال میکند. این کار یک «نشانگر انتشار» (Release Marker) فراهم میکند تا عامل مجبور نباشد علت خطا را صرفاً از روی یک نمودار قرمز حدس بزند. داشبورد فرماندهی حادثه (Incident Command) در نتیجه، ترکیبی از نرخ خطای پرداخت، تأخیر در پاسخدهی، اثرات درخواستهای شکستخورده، نشانگرهای انتشار، وضعیت کوبرنتیز و شواهد بازیابی را نمایش میدهد.
به جای اینکه از عامل بخواهیم علت را حدس بزند، MANDATE یک بستهی شواهد محدود (Bounded Evidence Bundle) شامل موارد زیر ارائه میدهد:
- نرخ دقیق خطای پرداخت (Checkout Error Rate)
- متریکهای تأخیر در پرداخت
- نشانگرهای Trace که گویای یک انتشار معیوب است
- وضعیت فعلی خوشه کوبرنتیز
در این نقطه، زمانی که وبهوک فعال میشود، هماهنگکنندهی حادثه یک «mandate» ریشه با عمر کوتاه دریافت میکند. این اختیار سپس به یک «بازرس SigNoz» (SigNoz Investigator) واگذار میشود. این عامل فرزند میتواند استقرار پرداخت را بازرسی کرده و بسته شواهد را کوئری کند، اما نمیتواند ابزارهای جدید، بودجه بیشتر یا محدوده منابع گستردهتری را به ارث ببرد.
اگر این عامل پیشنهادی برای رفع مشکل بدهد (مثلاً بازگردانی یا Rollback سرویس پرداخت)، این پیشنهاد توسط یک سیاست سختگیرانه مدیریت میشود. برای مثال، سیاست k8s.rollback_deployment به شرح زیر است:
- وضعیت فعال (Enabled): true
- منبع (Source): kubernetes
- هزینه (Cost): ۰.۰۲ دلار
- سیاست (Policy): تغییردهنده (Mutating: true)، فقط رد کردن (Denial Only: false)
- نیاز به تایید (Approval Required): true
- سطح ریسک (Risk Level): بحرانی (Critical)
- نیاز به شواهد (Evidence Required): الزامی (Required)
درگاه یک «طرح اقدام» (Action Plan) تغییرناپذیر را ثبت میکند که شامل هدف، آرگومانهای استاندارد، اثر انگشت شواهد (Evidence Digest)، نسخه سیاست، شعاع تخریب (Blast Radius) و زمان انقضا است. اپراتور انسانی دقیقاً همین طرح را از طریق Slack یا کنسول MANDATE تایید میکند، نه یک دکمهی مبهم مثل «اجازه به عامل».
تاییدیه تنها باعث پیشروی اقدام به یک ایستگاه بازرسی دیگر میشود. درست قبل از اجرا، دروازه مجدداً موارد زیر را اعتبارسنجی میکند: mandate، اثر انگشت آرگومانها، انقضا، بودجه، زنجیره حسابرسی (Audit Chain)، سلامت وابستگیها و شواهد زنده. تنها پس از این تایید نهایی است که دروازه عملیات بازگشت (Rollback) را انجام میدهد و سپس برای ثبت تاییدیه به عنوان یک فاز مجزا، وضعیت پس از اجرا را کوئری میکند.
بر اساس تحلیلهای توسعهدهندگان، MANDATE دو مسیر تلهمتری مجزا را با استفاده از شناسههای کمتراکم (Low-cardinality) مانند mandate.id و mandate.action.id رصد میکند:
- تلهمتری زمان اجرای عامل: فراخوانیهای مدل، عاملهای فرعی، فراخوانی ابزارها، تأخیر، مصرف توکن، امتیازهای ارزیابی و هزینههای تخمینی را توضیح میدهد.
- تلهمتری mandate*: اعتبارسنجی قابلیتها، تفویض اختیار، سیاستها، برنامهریزی، تاییدها، اجرا، تاییدیه نهایی، ابطال و سلامت حسابرسی را ثبت میکند.
پرامپتهای کامل و کلیدهای API بهطور عمدی از این لاگها حذف شدهاند. در این مخزن از سه داشبورد اصلی استفاده میشود: «نمای کلی اقتدار» برای یکپارچگی سیاستها و حسابرسی، «فرماندهی حادثه» برای تاثیر سرویس و بازیابی، و «داشبورد هزینه عامل و LLM» برای کارایی مدل.
در طول توسعه، چندین حالت شکست بحرانی شناسایی شد. یک باگ اجازه میداد عامل فرزند بهطور تصادفی محدوده منابع خود را فراتر از محدودیت والد گسترش دهد. هرچند دروازه این اقدام را رد کرد، اما هندلر وبهوک خطای HTTP 502 بازگرداند که باعث ایجاد یک «طوفان تکرار» (Retry Storm) شد؛ به طوری که هر تکرار یک هماهنگکننده حادثه جدید ایجاد میکرد. این مشکل با اطمینان از عدم گسترش اختیار فرزند و پیادهسازی رکوردهای گردشکار Idempotent برطرف شد.
مورد دیگری رخ داد که در آن یک عملیات Rollback تایید شد، اما پیش از آن، یک انسان بهطور دستی استقرار سالم را بازیابی کرده بود. دروازه اجرا را با خطای evidence_unavailable متوقف کرد. این ثابت کرد که مدل ایمنی درست کار میکند: نشانگر انتشاری که طرح را توجیه میکرد، دیگر وجود نداشت. یک تاییدیه، رضایت برای یک طرح خاص تحت شرایط فعلی است، نه یک اجازه کلی برای آینده.
در نهایت، یک کوئری بیش از حد گسترده در زیرساخت با خطا در حافظه OvercommitTracker کلیک-هاوس (ClickHouse) مواجه شد. این اتفاق باعث شد طراحی به سمت استفاده از پنجرههای شواهد کوتاه، تجمیعهای محدود و برچسبهای متریک کمتراکم تغییر یابد تا مسیر عملیاتی محافظت شود.
برای بازتولید این جریان، مخزن پروژه فایلهای casting.yaml و casting.yaml.lock را برای استقرار تکرارپذیر SigNoz از طریق Foundry ارائه میدهد. روند راهاندازی محلی به این صورت است:
uv run mandate setupuv run mandate start --profile lab --signozmake kind-up kind-build kind-deploymake demo-trigger-payment-regression
دستور نهایی سیگنالهای قابل مشاهده را آماده میکند، داراییهای SigNoz را تایید کرده، ایمیج معیوب پرداخت را مستقر میکند و شکستها را ایجاد میکند. این دمو حتی بدون فراخوانی زنده LLM نیز قطعی (Deterministic) است، هرچند مسیری برای آزمایش با مدلهای زنده با محدودیت هزینه وجود دارد.
این رویکرد، پرسش بنیادین در عملیات عاملمحور را تغییر میدهد. تمرکز از «عامل چه کرد؟» به «چرا اجازه داشت این کار را بکند و چگونه میدانیم که درست عمل کرده است؟» منتقل میشود. برای تیمهایی که به سمت بازیابی خودکار (Autonomous Remediation) میروند، درس اصلی این است که استدلال عامل، جایگزینی برای کنترل اقتدار نیست.
گام بعدی شما
- اگر از عاملهای خودکار برای مدیریت زیرساخت استفاده میکنید، مدل «دسترسی موقت مبتنی بر شواهد» را جایگزین دسترسیهای دائمی کنید.
- پروتکل MCP را برای جداسازی لایهی استدلال از لایهی اجرای دستورات در معماری خود بررسی کنید.
- سیاستهای اجرایی (Policy) را بر اساس سطح ریسک و هزینه برای هر ابزار تعریف کنید تا از اجرای تصادفی دستورات گرانقیمت یا خطرناک جلوگیری شود.
اما این تنها بخشی از معماری ایمن است؛ برای درک نحوه مدیریت حافظه در این عاملها، به تحلیل ما دربارهی پنجرههای متنی پیشرفته مراجعه کنید.
گفتگو