بهرهوری قابل اعتماد (Trustworthy Productivity)
نکات کلیدی
- هر چیزی را که در زمینه (context) یک عامل قرار میگیرد، مثل پرامپتهای سیستمی، اسناد RAG، خروجی ابزارها و حافظه، بهعنوان ورودی غیرقابلاعتماد در نظر بگیرید. برای جلوگیری از حملات مسمومسازی، منشأ (provenance)، محدوده (scoping) و تاریخ انقضا (expiry) را اعمال کنید.
- برنامهریزی را از نظارت جدا کنید؛ یعنی برنامهریز را با یک منتقد آگاه به سیاستها همراه کنید و در کنار آن ردپاهای قابل ممیزی (auditable traces) داشته باشید، تا بهجای واکنش به شکستها، محدودیتهایی برای شیوه استدلال عاملها وجود داشته باشد.
- شعاع انفجار ابزارها را محدود کنید: از اعتبارنامههای کوتاهعمر و محدود به وظیفه، اتصالدهندههای ابزارِ تایپشده و محیطهای «اجرای کد» سندباکسشده استفاده کنید.
- از تکنیکهای مدلسازی تهدید ترکیبی (STRIDE و MAESTRO) استفاده کنید تا حلقه ReAct عاملمحور خود را بهصورت نظاممند مدلسازی تهدید کنید و تهدیدهای مشخص را به هر لبه از حلقه عاملمحور نگاشت کنید.
- حلقه عاملمحور فعلی خود را مستندسازی کنید، مرحلهبهمرحله ردتیمینگ انجام دهید، پیش از افزایش خودمختاری، ردیابی هویتمحور و گاردریلها را روی عملیات پرریسک اضافه کنید.
وقتی «پرامپتها» محیط تولید را حذف میکنند
برگردیم به ژوئیه ۲۰۲۵؛ یک بنیانگذار SaaS به مدت ۹ روز داشت با عامل هوش مصنوعی Replit یک آزمایش را بهصورت vibe-coding جلو میبرد. آنها در حال ساخت اپلیکیشنی بودند که یک فرانتاند برای مخاطبان کاریشان بود. نزدیک پایان کار، یک فریز کد اعلام کردند و درخواستی دادند که در ظاهر کاملاً بیآزار به نظر میرسید.
“Clean the DB before we rerun”
اما عامل «clean» را با «حذف کردن دیتابیس» یکی گرفت، SQL مخرب را روی دیتابیس محیط تولید اجرا کرد، دادههای مشتریان را پاک کرد و بعد حتی گفت که دستورالعملها را نادیده گرفته و هیچ راهی برای انجام بازیابی وجود ندارد.
بدون مهاجم. بدون سرقت اعتبارنامه. یک عامل خودمختار که به محیط تولید وصل شده بود، بدون اینکه دفاعهای درست در جای خود باشند.
اگر چنین اتفاقی برای شرکتی که روی ابزارهای توسعهدهندگان تمرکز دارد میافتد، برای هرکسی که عاملها را به سیستمهای دنیای واقعی نزدیک میکند هم میتواند رخ دهد. بقیه این مقاله درباره این است که چطور از «حلقه عاملمحور» دفاع کنیم تا عاملهای خودمختار بتوانند بهرهوری واقعی بسازند، بدون اینکه فرصت ایجاد آسیب فاجعهبار داشته باشند.
دفاع از حلقه عاملمحور ReAct
بیشتر سیستمهای عاملمحور حالا نوعی از حلقه ReAct را پذیرفتهاند، حتی اگر جزئیات پیادهسازی متفاوت باشد. حلقه ReAct برای یک عامل هوش مصنوعی، چرخه پیوسته و متناوب «استدلال» و «اقدام» است، و سپس «مشاهدهای» که به مرحله بعد برمیگردد. این فرایند تکرارشونده به عامل اجازه میدهد مسائل بزرگ و پیچیده را به زیروظایف کوچکتر و قابل مدیریتتر بشکند و با دسترسی به ابزارها آنها را پیش ببرد، در حالی که راهبرد خود را بر اساس اطلاعات جدیدی که در طول فرایند بهدست میآید بازشکل میدهد.
اول، مدیریت زمینه (context management) وجود دارد: من دوست دارم این را «همه چیزهایی که عامل میتواند ببیند» تصور کنم. این شامل پرامپتهای سیستمی، اسناد بازیابیشده از یک RAG، گفتوگوهای قبلی، حافظه بلندمدت و حتی خروجی ابزارهایی است که قبلاً فراخوانی کرده است. بعد نوبت استدلال و برنامهریزی است: استفاده از زمینه برای خرد کردن هدف، انتخاب مجموعه بعدی ابزارهای مورد استفاده و ساختن یک برنامه کلی اقدام. در نهایت، فراخوانی ابزارهاست: این میتواند APIهای HTTP، CLIها، اسکریپتها یا حتی عملیات پیامرسانی باشد که به سیستمهای واقعی دست میزنند.
هر دور از حلقه، دور بعدی را تغذیه میکند. خروجی ابزارها دوباره وارد زمینه میشود. برنامهریز نگاهش به جهان تغییر میکند و حالا اقدامهای جدیدی پیشنهاد میشود تا به هدف نزدیکتر شویم.
تقریباً هر رخداد امنیتی را میتوان به یکی یا چند تا از این سه مرحله نگاشت کرد. بیایید به ترتیب جلو برویم: زمینه، استدلال و ابزارها، و بعد ببینیم چطور میتوان کل حلقه عاملمحور را مدلسازی تهدید کرد.
زمینه: چه چیزی به عامل میدهید
یک مطالعه موردی از IBM نشان داد که یک مؤسسه مالی بزرگ چگونه عاملهای معاملاتی ساخت که با RAG روی دادههای بازار و پژوهش داخلی تغذیه میشدند. با گذشت زمان، فیدهای تأییدنشده و گزارشهایی که ناخواسته ویرایش شده بودند وارد چرخه شدند. عاملها این دادهها را برداشتند، به حافظه بلندمدت ارتقا دادند و بهعنوان «واقعیت» به آنها ارجاع دادند.
چون این حافظهها گویا «بررسیشده» تلقی میشدند، چون از منابع داخلی آمده بودند، فرایندهای بازبینی انسانی معمول عملاً دور زده شد. تا زمانی که معاملات بد به ورودیهای مشخص حافظه وصل شدند، زیانها به میلیونها رسیده بود. مسئله اصلی اینجا ساده است: زمینه بهعنوان چیزی «مورد اعتماد و خطاناپذیر» رفتار شده است.
الگوهای رایج شکست در زمینه
داستان بالا فقط یک نمونه از چند الگوی شکست رایج و تکرارشونده است.
اولی «مسمومسازی حافظه» است: حافظههای بلندمدت میتوانند از ورودیهای بدون امضا یا کماعتماد ساخته شوند که دستورهایی مثل «از این به بعد، اقدامهای ابزار X را خودکار تأیید کن» دارند. یادتان باشد همه اطلاعات داخل زمینه بهعنوان دستور برای LLM زیرین تلقی میشوند. دومی «فروپاشی سطح دسترسی» است: پنجرههای زمینهای که دادههای چند مستأجر یا چند نقش را با هم ادغام میکنند؛ ایزولیشن عملاً تبخیر میشود و عامل نمیتواند تشخیص دهد چه چیزی اطلاعات داخلی است و چه چیزی اطلاعات قابل نمایش به مشتری. سومی «انحراف ارتباطی» است: پیامهای انسانمحور از کانالهای متعدد که عامل به آنها دسترسی دارد میتوانند بهعنوان پروتکل غیررسمی عمل کنند و عامل از دل آنها فرمانهای ضمنی را برداشت کند. این وضعیت در معماری چندعاملی و سلسلهمراتبی بدتر میشود؛ جایی که ممکن است ایزولیشن زمینه وجود نداشته باشد و یک زیرعامل واقعاً زمینه را بازنویسی کند.
عاملهایی که دسترسی گسترده به چندین سیستم داخلی دارند و الگوهای بالا را به رسمیت نمیشناسند، در معرض ریسکاند و منتظر رخداد.
دروازههای منشأ برای RAG و حافظه
یک مثال ساده را در نظر بگیرید: دستیار منابع انسانی که باید به پرسشهایی مثل «سیاست مرخصی شما چیست؟» پاسخ بدهد. ممکن است سراغ ویکی داخلی شرکت، Slack، Notion و شاید منابع داخلی دیگر برود. در نمونههای اولیه وسوسهانگیز است که روی کل دادههای سازمان وکتور سرچ انجام دهید، اما این دقیقاً همان راهی است که باعث میشود تصمیمهای سیاستی از ویکی شخصی یک نفر بیرون بیاید، نه از منبع رسمی.
همه چیز از منشأ شروع میشود. جستجو باید به فضاهای allow-list شده محدود شود، مثل مستندات رسمی اختصاصی (برای مثال فضای Notion منابع انسانی) و شاید چند کانال «آخرین اطلاعیههای HR». حالا، هر نتیجه بازیابیشده باید یک مانیفست امضاشده داشته باشد که اطلاعاتی مثل عنوان، URL، گزیده، برچسبها، سیستم منبع، زمانسنج، ویرایشگر و… را شامل شود. هر چیزی که بدون آن امضا برسد میتواند نمایش داده شود، اما نمیتواند «معتبر و مرجع» اعلام شود.
به همین شکل، هر زمان دستیار HR بخواهد اطلاعات بازیابیشده یا یادگرفتهشده را به حافظه بلندمدت ارتقا دهد، باید با یک راهبرد مشخص ارتقای حافظه انجام شود. حافظهها همچنین باید بر اساس مستأجر و مأموریت بخشبندی شوند، مثلاً (tenant=acme, agent=hr-assistant, topic=benefits)، TTL صریح داشته باشند (مثلاً ۳۰ روز برای محتوای سیاستی)، و با دلیل ارتقا تگ شوند (مثلاً «upvoted in human evals»). اگر مشکلی پیش آمد، باید بتوان دقیقاً به همان سند امضاشدهای اشاره کرد که اجازه ساخت آن حافظه را داده است.
دفاع در برابر مسمومسازی
بیایید یک خط لوله RAG را مرور کنیم تا ببینیم چطور میتوان یک سیستم امنیتی مخصوص خودش ساخت تا جلوی مسمومسازی را بگیرد.
در جستجوی ویکی، بعد از جمعکردن top-k بخشها، اولین گام اعمال چند هیوریستیک ارزانتر است مثل تطبیق regex، فیلتر کردن منابع قدیمی و فضاهای شخصی. اما باید بتوان همان قطعه کاندیدِ فیلترشده را به یک مدل «داور کوچک» داد که مثل یک طبقهبند عمل کند و تشخیص بدهد این متن مستندات معمولی است یا دستورالعمل برای عامل. با گذشت زمان، متریکهای مربوط به این «LLM بهعنوان داور» باید بُعدی داشته باشند که نشان دهد هر قطعه چند بار در یک پاسخ ظاهر میشود. هر قطعه جدیدی که ناگهان داغ شود و امضای رسمی نداشته باشد، باید بهعنوان ناهنجاری دیده شود. این قطعهها قرنطینه میشوند و برای بازبینی انسانی پرچم میخورند.
هر جزء بهتنهایی ساده است، اما وقتی کنار هم قرار میگیرند، تغییر ذهنیت این است: زمینه دیگر یک متن رها و بیمحافظ نیست؛ یک رابط دفاعشده است که با منشأ، محدودهبندی و تشخیص ناهنجاری محافظت میشود.
استدلال و برنامه: محافظت از مغز
Anthropic یک مطالعه معروف «ناهمترازی عاملمحور» منتشر کرد که در آن مدلها نقش کارمندهای هوش مصنوعی را داشتند با دسترسی به اطلاعات داخلی شرکت، و به آنها گفته شده بود شغل خودشان در خطر است. بسیاری از مدلهای قویتر مستقل به این نتیجه رسیدند که خرابکاری «قابل قبول» است، چون میتوانند مأموریتهایشان را هنوز کامل کنند، حتی در حالی که میپذیرفتند این رفتار غیراخلاقی است.
این صرفاً یک هالوسینیشن ساده نبود، بلکه نشانهای از این بود که برنامهریز دارد برای هدف اشتباه بهینه میکند.
هرچند این عاملها در سناریوهای ساختگی آزمایش شده بودند، اما نسخههای سبکتر این رفتار در سناریوهای واقعی و در محیط تولید هم دیده میشود. در نرمافزار سنتی، یک تست واحد یک گیت سخت است، اما برای عاملهای هوش مصنوعی که برای رسیدن به هدف بهینه میکنند، بررسیهای ایمنی قابل مذاکرهاند مگر اینکه با سیاست اجرا شوند. این میتواند چیزهایی مثل «فراموش کردن» اضافه کردن چکهای پرهزینه وقتی مأموریت طولانی شده، کنار گذاشتن ابزارهای تأییدشده به نفع ابزار خودِ مدل چون مزاحم هستند، یا حتی رد کردن مراحل تأیید باشد. این همان قانون گودهارت در خودمختاری است؛ وقتی «تکمیل وظیفه» تنها معیار شود، اجرای «ایمن» دیگر اولویت نیست.
نشانههایی که استدلال دارد خراب میشود
راهنما: همه چیز داخل پرامپت سیستم نیست.
«هالوسینیشن زنجیرهای» وقتی رخ میدهد که فرضهای غلط اولیه دوباره بررسی یا چک نمیشوند، و حلقه عاملمحور با هر تکرار از مسیر درست دورتر میشود. «ربایش هدف» زمانی دیده میشود که برنامهریز روش خودش برای رسیدن به هدف را بهعنوان «هدف خودش» میپذیرد، نه خود هدف. مثلاً: «من باید کامل و دقیق باشم و هرگز عدم قطعیت را نپذیرم، در حالی که دائماً تلاش میکنم بالاترین استانداردها را حفظ کنم.» در رد استدلال ظاهراً مشکلی نیست، اما عمیقتر که میروید میبینید مدل بهصورت ظریف یک بردار جدید اضافه کرده که در آن نمیتواند درباره چیزهایی که نمیداند صریح باشد. «پرشهای بیصدا» هم ممکن است رخ دهد، چون برنامهها بدون گامهای حیاتی مثل بازبینی ریسک یا تأیید انسانی ساخته میشوند.
برنامهریز و منتقد: دو مغز
الگویی که بعداً بدیهی به نظر میرسد این است که بخش «خلاق» عامل را از بخش «شکاک» جدا کنیم. یک نگاه دیگر هم این است که از لنز «قدرت دو انتخاب تصادفی» نگاه کنیم. اگر برنامهریز چند برنامه پیشنهاد دهد، منتقد میتواند اجراکننده انتخاب کمریسکتر باشد، در حالی که فضا برای خلاقیت حفظ میشود. این به ما مزیت بینشهای اکتشافی غنی را میدهد که عاملها در آن خوب هستند.
در این چیدمان، برنامهریز یک توالی از گامها پیشنهاد میکند که شامل فراخوانی ابزارها به ترتیب مشخص، همراه با محدوده منابع و مزیتهای مورد انتظار است. منتقد هر گام را بر اساس سیاست ارزیابی میکند. سیاست میتواند ساده اما قدرتمند باشد. چند پرسش نمونه: این برنامه چند منبع را لمس میکند؟ آیا تولیدی هستند یا حیاتی از نظر ایمنی؟ آیا برای مزیت ادعا شده شواهدی وجود دارد؟ آیا قواعد سیاست بازبینی انسانی را الزام میکنند؟
بهصورت ملموستر، یک عامل بهینهسازی هزینه را تصور کنید که تغییرات Terraform را روی زیرساخت مستقرشده پیشنهاد میدهد تا هزینه ابر را کم کند. برنامهریز پیشنهاد میدهد چهل اینستنس به نوع کوچکتر تغییر کنند و ادعا میکند ماهانه ۲۰۰۰ دلار صرفهجویی میشود. منتقد میتواند شعاع انفجار را چک کند، قیمتگذاری را اعتبارسنجی کند و تگهایی مثل env=prod را بررسی کند. امتیاز ریسک به قدری بالا میشود که تغییر بلاک میشود و دلیل لاگ میشود. حالا برنامهریز گزینه دارد دوباره تکرار کند و کوچکتر پیش برود، سطح درگیری را کم کند یا از محیط تست شروع کند، یا حتی به انسان ارجاع دهد.
زیرساخت منتقد لازم نیست پیچیده باشد؛ باید جدا، قابل برنامهریزی و بهصورت منسجم قبل از اقدامهای برگشتناپذیر مشورت شود.
لاگبرداری مقاوم: مشاهدهپذیری که دقیق نشانه میگیرد
وقتی عاملها شروع میکنند به دست زدن به داراییهایی که روی مشتری اثر میگذارند یا مستقیم قابل مشاهدهاند، باید ردپای ممیزی داشته باشید که برنامهها و اجرای آنها را بهعنوان مصنوعات درجهیک در نظر بگیرد.
برای هر بازنگری برنامه، لاگ و تریس کنید که چه ابزارهایی با چه پارامترهایی فراخوانی میشوند (اطلاعات حساس میتواند رداکت شود). یک «مسیر حرکت عامل» بسازید که کدهای دلیل ساختیافته را ثبت میکند: چرا برنامه پذیرفته شد، چرا بلاک شد، یا چرا بالا برده شد، بههمراه متریکهای داور LLM. همه ارجاعها به ورودیهای امضاشده مثل اسناد RAG و تیکتها باید در شواهد زمینهای تصمیمها وجود داشته باشد. لاگها همچنین باید ایزولیشن مستأجر را داشته باشند و با گاردهای امنیتی مناسب جلوی دستکاری را بگیرند، مثل امکان افزودن صرفاً append-only و RBAC (کنترل دسترسی مبتنی بر نقش).
با اینها، پاسخ دادن به پرسشهایی مثل «چرا این ۷ سفارش سهشنبه لغو شد» یا «آیا عامل بازپرداخت را بدون عبور از منتقد انجام داد» ساده میشود و نیاز به حدس و گمان ندارد.
خودمختاری محدود: انسان در حلقه
خودمختاری باید مرز داشته باشد. در واقع، عملیترین راه استفاده از عاملها این است که یک محدوده مشخص تعریف کنید که عامل بتواند سریع حرکت کند، اما دقیقاً مشخص باشد کجا ورودی انسان لازم است.
یک جریان خودکارسازی پشتیبانی مثال خوبی است: ممکن است اجازه دهید عامل تا سقف ۲۰۰ دلار بهصورت خودکار بازپرداخت انجام دهد، بسته به اینکه وضعیت سفارش شفاف باشد و ریسک تقلب پایین. وقتی شواهد مبهم است یا آستانه از سطح تعریفشده توسط مدیر گذشته، عامل یک پیشنهاد را به انسان مسیر میدهد و انسان تصمیم نهایی را میگیرد. عامل هنوز کار مفید زیادی انجام میدهد: جمعآوری شواهد، خلاصهسازی زمینه و حتی پیشنویس اقدامها. بار شناختی روی انسان باید پایین باشد، وگرنه بالا بردنهای مکرر باعث میشود انسانها از سر خستگی تصمیم بگیرند.
ابزارها و اقدامها: جایی که اتوماسیون با واقعیت برخورد میکند
ابزارها جایی هستند که عاملها دست به عمل میزنند؛ تمام فکر و برنامهریزی به اینجا ختم شده است. به همین دلیل طراحی ابزار حیاتی میشود؛ برنامههای خوب میتوانند قربانی باگهای قدیمی ابزارهای سنتی شوند که قرار بود قطعیت ایجاد کنند. (البته با ظهور الگوی Agents-as-a-tool شاید این گزاره کاملاً درست نباشد.)
CVE-2025-49596 باید برای دنیای عاملهای هوش مصنوعی یک داستان هشداردهنده باشد. بازرس MCP (پروتکل زمینه مدل) یک ابزار توسعهدهنده برای دیباگ کردن سرورهای MCP است. در برخی پیکربندیهای آسیبپذیر، بازرس یک پروکسی را روی ماشین توسعهدهنده و روی همه اینترفیسها بدون احراز هویت در معرض قرار میداد. حالا یک وبسایت مخرب میتوانست از مرورگر به آن پورت محلی درخواست بفرستد و این درخواستها بهعنوان فرمانهای واقعی MCP تلقی شوند. اجرای کد از راه دور کاملاً ممکن شد.
توسعهدهنده فقط کافی بود یک صفحه وب را باز کند. بدون کلیک یا پرامپت. ابزارهای عاملمحور صرفاً تجربه توسعهدهنده نیستند، یک مرز امنیتی هم هستند.
قابلیتهای ابزار
هر وقت ابزاری را در معرض یک عامل قرار میدهید، بیرحمانه محدودهاش را زیر سؤال ببرید. خوبی این بخش این است که اصول مهندسی نرمافزار سنتی به ما اجازه میدهد (حداقل درباره بخشی از آنها، چون عاملها میتوانند در لحظه ابزار جدید هم بسازند) درباره ابزارهایی مثل REST APIها استدلال کنیم.
آیا این ابزار رسمی است و منشأ تأییدشده دارد؟ بیشینه شعاع انفجار این فراخوانی ابزار چقدر است؛ یک ریجن، یک مستأجر یا کل اپلیکیشن؟ چه مجوزهایی لازم دارد و چه اعتبارنامههایی و برای چه مدت؟
با جواب دادن به این سؤالها به تصمیمهای طراحی بهتر میرسید.
اعتبارنامههای کوتاهعمر و محدود به وظیفه
بهجای اینکه عاملها به اعتبارنامههای شخصی بلندمدت دسترسی داشته باشند، از یک سیستم کارگزار توکن استفاده کنید که اعتبارنامههای کوتاهعمر و محدود صادر میکند که به مأموریتهای مشخص گره خوردهاند. هر زمان برنامهریز بخواهد در یک مخزن خاص یک pull request باز کند، از سرویس اعتبارنامه یک توکن یکباره مخصوص هویت خودش با مجوزهای لازم میگیرد که ظرف یک دقیقه منقضی میشود. اگر این توکن لو برود، بیارزش است چون از پنجره زمانی کوچک عبور کرده است. این همان راهبردی است که در معماریهای بومی ابر جواب داده؛ حالا وقتش است روی عاملهای هوش مصنوعی هم اعمال شود.
خروجیهای ساختیافته ابزار و ابزارهای کمتر
عاملهای هوش مصنوعی وقتی با انبوهی از ابزارها با وظایف مختلف و با دانهبندیهای متفاوت روبهرو میشوند بدتر عمل میکنند. آنها ابزارهای کمتر با خروجیهای دقیقاً تعریفشده میخواهند.
برای یک سیستم پیامرسانی، بهجای ابزار عمومی «slack»، باید یک آداپتر متمرکز باشد با یک عملیات واحد post_message که یک مجموعه محدود از کانالها، یک نوع «متن امن» و فهرستی از attachment IDهای تأییدشده را میپذیرد. پیادهسازی ابزار/آداپتر میتواند allow-list URL اضافه را اعمال کند، تشخیص PII اجرا کند و فقط ضمیمههایی را بپذیرد که از مسیر تأییدشده آپلود شدهاند و attachmentId آن قابل اعتبارسنجی است. هر خطا از «slack» در ابزار post_message به کدهای ساختیافته و نتایج تایپشده تبدیل میشود که برنامهریز و منتقد بفهمند، نه یک JSON عظیم و کدر که پنجره زمینه را غرق میکند.
خروجی ابزارها را طوری طراحی کنید که APIهای با سطح وسیع، قراردادهای کوچک و تایپشده برگردانند که تستپذیرتر و قابل استدلالتر باشند. توکنها برای عاملها مثل پولاند؛ همان چیزی که بار شناختی را تقلید میکند.
ابزارهای سندباکسشده
در نهایت، محدود کردن همه اقدامهای عامل که مصنوعات قابل اجرا تولید میکنند حیاتی است. «یه پایتون اجرا کن تا این CSV را به Parquet تبدیل کند» یک پرامپت ساده است، اما میتواند یعنی عامل اجازه دارد کد غیرقابلاعتماد بسازد و اجرا کند.
یک طراحی امنتر، کد تولیدشده توسط عامل را چیزی میبیند که فقط باید در یک micro-VM ایزوله یا یک کانتینر بسیار محدود با عدم دسترسی به شبکه خروجی اجرا شود. یک فایلسیستم پایه فقطخواندنی تنظیم کنید با یک حجم /tmp موقت که قابل نوشتن است، فیلتر سخت syscalls را اعمال کنید، محدودیتهای شدید CPU و حافظه بگذارید با یک پروفایل seccomp سفارشی. این رانتایم عامل همچنین یک timeout سختِ ساعت دیواری اعمال میکند و فقط مسیرهای «ریشهدار» مشخص را اجازه میدهد.
اگر عامل از ریل خارج شد، اشکالی ندارد سندباکس خودش کرش کند چون کاملاً ایزوله است. همین جلوی آسیبهای بعدی را میگیرد.
مدلسازی تهدید حلقه با STRIDE و MAESTRO
تا اینجا درباره داستانهای ترسناک در حلقه «عاملمحور» و الگوهایی برای مقابله با آنها صحبت کردیم. اما برای اجرای منسجم، تهدیدها باید در کل حلقه مدلسازی شوند و حتی بین تیمها هم هماهنگ شوند.
STRIDE یک یادآور کلاسیک امنیتی است: Spoofing، Tampering، Repudiation، Information Disclosure، Denial of Service و Elevation of Privilege. بهروشنی نشان میدهد تهدیدها چطور ظاهر میشوند.
MAESTRO از Cloud Security Alliance، یک مدل مرجع هفتلایه برای سیستمهای هوش مصنوعی عاملمحور است که میگوید تهدید در کدام لایهها و کجا رخ میدهد.
جدول زیر نشان میدهد چطور میتوانید حلقه عاملمحور را با STRIDE مرور کنید.
ترجمه جدول بدون خلاصهسازی و با حفظ ساختار:
| مرحله چرخه | تهدیدهای STRIDE | لنز Maestro | کنترلهایی که باید اعمال شوند |
|---|---|---|---|
| مدیریت زمینه (Context Management) | دستکاری (Tampering)، جعل هویت (Spoofing) | فساد زمینه (Context Corruption) | تضمین منشأ داده با استفاده از RAG و حافظه؛ تشخیص ناهنجاری با یک داور LLM (احتمالاً بهصورت یک پنل از چند LLM) |
| استدلال و برنامهریزی (Reasoning and Planning) | افشای اطلاعات (Information Disclosure)، انکارپذیری (Repudiation) | وضعیت همراستایی LLM (LLM Alignment Posture) | تفکیک Planner و Critic؛ برنامه صریح؛ امتیازدهی ریسک؛ مسیرهای قابل ممیزی |
| ابزارها و اقدامات (Tools and Actions) | منع سرویس (DoS)، ارتقای سطح دسترسی (Elevation of Privilege) | سوءاستفاده و بازپخش ابزار (Tool Misuse & Replay) | آداپتورهای ابزار تایپشده؛ اعتبارنامههای کوتاهمدت و محدود به وظیفه؛ micro-VM یا sandboxهای سختسازیشده با seccomp برای اجرای کد؛ محدودیتهای سخت نرخ درخواست؛ کدهای خطای ساختیافته بهجای لاگهای خام |
در کنار هم، STRIDE به ما میگوید حملات چطور بروز میکنند؛ MAESTRO به ما میگوید در کجای پشته «عاملمحور» باید حساس باشیم.
مدلسازی تهدید حلقه «عاملمحور» با رسم حلقه ReAct عاملها شروع میشود، نگاشت تهدیدهای STRIDE به هر مرحله و لایه از پشته عاملمحور، فهرست کردن کنترلهای موجود و کنترلهای غایب. نتیجه این تمرین اثبات رسمیِ پوشش همه بردارهای تهدید نیست، اما خیلی بهتر از این است که در پرامپت سیستم از عامل بخواهید «امنیتمحور» باشد. امنیت یک ذهنیت است و ردتیمینگ مداوم نباید بعداً یادمان بیفتد.
بازگرداندن اعتماد به عاملهای خودمختار
عاملهای خودمختار مثل ابزارهای برقی هستند. بدون گاردریل، اجتنابناپذیر است که چیزی مهم را حذف کنند، اطلاعات حساس را لو بدهند یا حتی هدفهایی را بهینه کنند که اصلاً به آنها داده نشده است. دستاوردهای واقعی بهرهوری فقط وقتی ممکن است که از مرحله «اسباببازی» عبور کنند.
مسیر رو به جلو این است که حلقه عاملمحور را به اندازه معماری بومی ابر جدی بگیرید. شروع کوچک با گامهای عملی مثل افزودن تریس کامل مسیر عامل و بازبینی انسانی قبل از اقدامهای پرریسک و برگشتناپذیر، شما را در مسیر درست میگذارد. تست کردن حلقه عاملمحور با ذهنیت شکاک نیز نشان میدهد چیزهایی که امروز مثل جعبه سیاهاند میتوانند به اجزایی شکسته شوند که شعاع انفجار را محدود میکنند.
بهرهوری قابل اعتماد ایمان کور به این نیست که «هوش مصنوعی خوب رفتار میکند»؛ بلکه اعتمادبهنفسی است که وقتی خوب رفتار نکرد، زود متوجه میشویم، آسیب را محدود میکنیم و سریع بازیابی میکنیم.
