اگر امروز یک عامل هوشمند را بدون سیستم نظارتی دقیق در محیط عملیاتی رها کردهاید، احتمالاً در حال ساختن یک بمب ساعتی هستید. طبق گزارش گارتنر (Gartner) در ۲۶ می ۲۰۲۶، حدود ۴۰٪ از سازمانها تا سال ۲۰۲۷ مجبور میشوند عاملهای هوش مصنوعی زاینده (Generative AI) خود را به دلیل حوادث پیشبینینشده و نبود حاکمیت داده، بازنشسته یا محدود کنند. این پیشبینی نشاندهنده یک شکست بحرانی در نحوه استقرار جریانهای کاری عاملمحور (Agentic Workflows) بدون وجود حفاظهای کافی است. راهکار پیشنهادی گارتنر برای رفع این مشکل، طبقهبندی عاملها در چهار سطح خودمختاری و متناسب کردن کنترلها با هر سطح است.
بسیاری از تیمهای فنی با عاملهای هوشمند مثل یک کلید برق برخورد میکنند؛ یا خاموشاند یا کاملاً خودکار. اما در واقعیت، فاصله بین یک نمونه اولیه (Prototype) و یک سیستم صنعتی (Production-grade)، یک خلأ نظارتی عمیق است. بدون وجود روشی برای بازرسی (Audit) اینکه چرا یک عامل تصمیم خاصی گرفته است، یک حادثه واحد با تأثیر بالا میتواند منجر به تعطیلی فوری کل برنامه AI شرکت شود. همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، نبود سیستمی برای ردیابی منطق تصمیمگیری، ریسک عملیاتی را به شدت افزایش میدهد. در همین راستا، بررسی ضعفهای تأییدیههای یکباره در مدیریت ریسک نشان میدهد که رویکردهای ایستا برای کنترل عاملهای خودمختار ناکارآمد هستند.
برای حل این بحران، انیل پراساد (Anil Prasad)، بنیانگذار Ambharii Labs، پیادهسازی فنی مدل چهارسطحی گارتنر را پیشنهاد میدهد. این رویکرد، عاملها را بر اساس قابلیت اثباتشده به جای خوشبینی، از مشاهده غیرفعال به خودمختاری کامل میبرد. این پیادهسازی تنها با استفاده از کتابخانه استاندارد پایتون انجام میشود تا ابزارهایی شامل یک مانیفست، یک گیت نظارتی، یک گزارش اقدامات فقط-افزودنی، یک قطعکننده مدار و یک سیستم بررسی قابلیت اطمینان ایجاد کند.
چهار سطح خودمختاری
حاکمیت با یک «مانیفست» شروع میشود که مرزهای عامل را تعریف میکند. این مانیفست جایی است که سیستم یکپارچهسازی مداوم (CI) مجوزهای عامل را میخواند. یک مانیفست استاندارد شامل موارد زیر است:
agent_id: شناسه منحصربهفرد عامل (مثلاًrefunds_v3).autonomy_level: سطح خودمختاری تعیین شده.allowed_tools: لیستی از ابزارهای مجاز (مانندcrm.readبرای خواندن دادهها وpayments.refundبرای بازپرداخت وجه).policy_version: نسخه سیاستهای حاکمیتی (مثلاً2027.01).owner: نام مالک یا تیم مسئول (مثلاًpayments_platform).
این سطوح به شرح زیر دستهبندی میشوند:
- سطح ۱ (مشاهده - Observe): دسترسی فقط-خواندنی؛ عامل نمیتواند هیچ تغییری در وضعیت سیستم ایجاد کند.
- سطح ۲ (مشاوره - Advise): عامل پیشنویس اقدامات را تهیه میکند، اما اجرای نهایی بر عهده انسان است.
- سطح ۳ (اقدام تأییدشده - Approved Action): عامل تنها پس از تأیید و امضای یک انسان میتواند دادهها را بنویسد یا تغییر دهد.
- سطح ۴ (خودمختار - Autonomous): عامل در چارچوب حفاظهای (Guardrails) پیشتعریفشده، بهطور مستقل عمل میکند.

گیت نظارتی و گزارش اقدامات
هر فراخوانی ابزار (Tool Call) باید بدون استثنا از یک تابع واحد به نام «گیت» عبور کند. این تابع تصمیم میگیرد که آیا اقدام مجاز است یا خیر و فارغ از نتیجه، یک رکورد از این تلاش ثبت میکند. گیت، سطح خودمختاری عامل را با پروفایل ریسک ابزار مورد نظر تطبیق میدهد. برای مثال، ابزارهایی مانند payments.refund (بازپرداخت)، crm.update (بهروزرسانی مشتری) و email.send (ارسال ایمیل) در دسته «ابزارهای نوشتاری» (WRITE_TOOLS) طبقهبندی میشوند.
قوانین گیت به این صورت است: اگر ابزاری در لیست allowed_tools مانیفست نباشد، درخواست رد میشود. اگر ابزار از نوع نوشتاری باشد و سطح عامل پایینتر از ۳ باشد، درخواست رد میشود. اگر عامل در سطح ۳ باشد اما یک تأییدکننده (Approver) نامبرده شده وجود نداشته باشد، حکم گیت به needs_approval (نیاز به تأیید) تغییر میکند.
نکته حیاتی، وجود یک گزارش اقدامات «فقط-افزودنی» (Append-only Action Log) است. برخلاف لاگهای استاندارد خروجی که فقط گفتههای مدل را ثبت میکنند، این گزارش ثبت میکند که عامل «مجاز به چه کاری بود و چرا». این سیستم از فرمت «یک خط برای هر اقدام» استفاده میکند، نه «یک رکورد برای هر جلسه». هر رکورد شامل موارد زیر است:
- اصالت (Principals): ثبت همزمان نام عامل و انسان یا سیستمی که اقدام به نام او انجام شده است (
on_behalf_of). ثبت هر دو طرف، تنها راه پاسخ به این سؤال است که اقدام تحت چه اختیاری اجرا شده است. - متادیتا (Metadata): برچسب زمانی دقیق، سطح خودمختاری در لحظه اجرا، ابزار مورد استفاده و نسخه سیاست.
- یکپارچگی (Integrity): استفاده از هش SHA-256 از محتوای ورودی (Payload) برای جلوگیری از هرگونه دستکاری در گزارشات.
در محیط عملیاتی، این خطوط باید به فضای ذخیرهسازی منتقل شوند که عاملها دسترسی نوشتاری به آن ندارند. همچنین هر رکورد باید به هش رکورد قبلی زنجیر شود تا هرگونه تغییر در تاریخچه گزارشات فوراً قابل شناسایی باشد.

قطعکننده مدار و معیارهای قابلیت اطمینان
برای جلوگیری از «کاوش» (Probing) — وضعیتی که در آن یک عامل مکرراً سعی میکند از ابزاری ممنوعه استفاده کند — یک قطعکننده مدار (Circuit Breaker) پیاده میشود. این یک الزام سختگیرانه برای عاملهای سطح ۴ است. اگر عامل به آستانهای از احکام رد شده برسد (مثلاً سه بار رد شدن در یک بازه ۳۰۰ ثانیهای)، مدار باز میشود.
وقتی مدار باز است، عامل از انجام هرگونه اقدام متوقف شده و فوراً به مالک خود هشدار (Page) میدهد. در این حالت، سیستم تلاش مجدد (Retry) نمیکند؛ زیرا عاملی که مدام در حال جستجوی ابزارهای ممنوعه است، سیگنالی است مبنی بر اینکه مداخله انسانی ضروری است. برای ارتقای امنیت در این لایه، برخی شرکتها مانند رویکرد Cognous در انتقال حفاظها به سختافزار تلاش میکنند تا کنترلها را از محیط اجرای نرمافزاری جدا کنند.
ارتقای یک عامل به سطح خودمختاری بالاتر نباید بر اساس یک یا چند اجرای موفق اتفاق بیفتد. طبق مطالعهای در مارس ۲۰۲۶ در arXiv (کد ۲۶۰۳.۲۹۲۳۱) روی ۲۳,۳۹۲ اپیزود، مشخص شد که رتبهبندی تواناییها (Capability) اغلب با رتبهبندی قابلیت اطمینان (Reliability) متفاوت است. دقت داشبوردها فقط نشان میدهد عامل «یک بار» چه کرده است، اما ارتقا نیازمند دانستن این است که عامل «هر بار» چه میکند.

برای اندازهگیری واقعی قابلیت اطمینان، سیستم عامل را در برابر ۸ تغییر صادقانه (Honest Variations) از یک وظیفه تست میکند. این تغییرات شامل موارد زیر است:
- بازنویسی درخواستها با لحن متفاوت.
- تغییر ترتیب رکوردهای ورودی.
- ایجاد فیلدهای خالی واقعگرایانه در دادهها.
هشت فراخوانی یکسان تنها حافظه پنهان (Cache) را اندازه میگیرند، اما هشت تغییر صادقانه، پایداری سیستم را میسنجد. یک عامل تنها زمانی ارتقا مییابد که قابلیت اطمینان آن از یک آستانه مشخص عبور کند، مدارش در آن بازه باز نشده باشد و یک مالک نامبرده، تغییر مانیفست را امضا کند. در مقابل، اگر مدار باز شود، سطح خودمختاری عامل بهطور خودکار کاهش مییابد.
بررسیهای CI و شکافهای ایمنی
بسیاری از شکستهای عملیاتی به این دلیل رخ میدهند که یک عامل بهطور بیصدا در سطح ۴ اجرا میشود، چون هیچکس خلاف آن را اعلام نکرده است. برای جلوگیری از این اتفاق، تستهای CI باید طوری پیاده شوند که در صورت وجود موارد زیر، فرآیند ساخت (Build) با خطا مواجه شود:
۱. اگر یک عامل سطح ۴، فاقد فیلد level4_approved_by در مانیفست باشد.
۲. اگر به عاملی ابزارهای نوشتاری اختصاص داده شده باشد اما سطح خودمختاری آن کمتر از ۳ باشد.
این تغییر در رویکرد، استقرار AI را از یک تصمیم «جلسهای» به یک تصمیم «دادهمحور» تبدیل میکند. این امر تضمین میکند که وقتی یک حسابرس میپرسد چرا یک بازپرداخت وجه صادر شده است، شرکت یک رکورد تغییرناپذیر از اختیار مورد استفاده در اختیار داشته باشد. در موارد حساس مالی، حتی تعیین سقف هزینههای خارج از محیط اجرا برای جلوگیری از تخریبهای مالی گسترده ضروری است.
برای کسانی که امروز عاملها را مستقر میکنند، اولویت فوری پیادهسازی «گیت» است. بدون آن، شما عملاً عاملهای سطح ۴ را بهطور پیشفرض اجرا میکنید، فارغ از اینکه در مستنداتتان چه نوشتهاید. توجه داشته باشید که آستانههای خاص (مانند سه رد در پنج دقیقه) نقاط شروعی هستند که باید با دادههای واقعی سازمان شما تنظیم شوند.
برای تکمیل این حفاظها، توصیه میشود به ۱۰ مورد برتر OWASP برای برنامههای عاملمحور (دسامبر ۲۰۲۵) برای دفاع در برابر تزریق پرامپت (Prompt Injection) در خروجی ابزارها مراجعه کنید. سایر حوزههای حیاتی برای توسعه آینده، شامل فدراسیون هویت بین سازمانها از طریق پروتکل A2A و ارائهدهندگان هویت (Identity Providers) است.
گام بعدی شما
- مانیفستهای دسترسی را برای تمام عاملهای فعلی خود تعریف کنید و سطح خودمختاری هر کدام را صراحتاً اعلام نمایید.
- یک تابع گیت (Gate) مرکزی برای تمام فراخوانیهای ابزار (Tool Calls) ایجاد کنید تا هر اقدام ثبت شود.
- برای عاملهای سطح ۴، مکانیزم قطعکننده مدار (Circuit Breaker) را بر اساس نرخ خطای مجاز تعریف کنید.
اما برای دفاع در برابر تزریق پرامپت در خروجی ابزارها، باید استانداردهای OWASP را بررسی کنید؛ در گزارش بعدی به بررسی لایههای دفاعی خروجی خواهیم پرداخت.




گفتگو