تصور کنید یک عامل هوشمند به دلیل یک دستور اشتباه، هزاران ایمیل مزاحم ارسال کند یا دستوری تخریبی را در سرورهای شما اجرا کند. برای جلوگیری از این فاجعه، در ۱۲ ژوئیه ۲۰۲۶، یک توسعهدهنده الگویی ساختاری برای ایجاد دروازه تایید «انسان در حلقه» (Human-in-the-Loop) معرفی کرد که در آن رضایت انسانی دیگر یک توصیه مودبانه در پرامپت نیست، بلکه یک پیشنیاز فنی و سخت است که به عنوان یک وابستگی دادهای (Data Dependency) عمل میکند. این رویکرد یادآور راهکارهای مشابهی است که تایید انسانی به عنوان سد دفاعی در برابر توهمات مالی عاملها به کار گرفته شد.
بسیاری از توسعهدهندگان ابتدا سعی میکنند با نوشتن جملاتی مثل «همیشه قبل از ارسال بپرس» در پرامپت سیستمی (System Prompt) — که شبیه دستورالعملهای یک دفترچه راهنما برای مدل است — عاملها را مهار کنند. طبق گزارش وبسایت dev.to، این روش اساساً معیوب است؛ زیرا مدلهای زبانی بزرگ (LLM) میتوانند با استدلالهای خود، دستورات متنی را دور بزنند. مدل ممکن است تصمیم بگیرد که یک مورد خاص استثنایی است و نیاز به تایید ندارد، یا در حین انجام یک وظیفه پیچیده، قانون را فراموش کند، و یا اجازه دهد موارد خاص و حاشیهای (Edge Cases) بدون نظارت عبور کنند.
وقتی روی پرامپت تکیه میکنید، در واقع به همان بخشی اعتماد میکنید که قصد دارید مهارش کنید. برای ایمنسازی واقعی، دستورالعمل باید به یک سد ساختاری تبدیل شود. عامل نباید بتواند به مرحله اجرا برسد، مگر اینکه یک مقدار واقعی (Value) به نام «تایید شده» از بیرون دریافت کند. در واقع، دستور پیشین باید جای خود را به یک مسدودکننده ساختاری بدهد. این نیاز به جایگزینی مهندسی پرامپت با سیستمهای نظارتی، مشابه آنچه در پلتفرم LoopFlow برای اتوماسیون کدنویسی مشاهده شد، است.
همانطور که در تحلیلهای پیشین ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، وابستگی به رفتار مدل (Behavioral) ریسک بالایی دارد. این معماری جدید شبیه گاوصندوقی است که عامل فقط کلید ندارد، بلکه باید ابتدا یک کد یکبار مصرف از مدیر انسانی بگیرد تا در باز شود. در این معماری، عامل نمیتواند به شاخه اجرایی کد خود برسد، مگر اینکه یک مقدار «تایید شده» خاص از یک منبع خارجی بازگردانده شود. در اینجا، چک کردن ایمنی از یک درخواست زبانی به یک الزام فنی تبدیل میشود.
بر اساس مستندات منتشر شده در dev.to، نویسنده این الگو را پس از پیادهسازی زیرساختهای مشابه در سه پروژه مجزا تکامل داد: یک کرونجاب (Cron Job) برای تولید پیشنویسها، یک فایل seen.json برای جلوگیری از تکرار، و یک رابط کاربری (UI) کوچک برای تاییدات موبایلی. این تجربه منجر به ایجاد یک توالی خاص مبتنی بر REST شد:
- پیشنهاد (Proposal): عامل اقدام پیشنهادی (مثلاً پیشنویس یک ایمیل) را به یک API ارسال میکند. برای مثال، یک درخواست POST به مسیر
/v1/actionsممکن است شامل یکkindمانندemail.sendو یک بدنه پیشنمایش به فرمت Markdown باشد. این درخواست بلافاصله وضعیت «در انتظار» (Pending) را برمیگرداند. - پایش (Polling): عامل وارد یک حلقه میشود و هر ۵ ثانیه وضعیت آن ID خاص از اقدام را چک میکند. عامل در این حلقه باقی میماند تا زمانی که وضعیت دیگر «در انتظار» نباشد.
- اجرا (Execution): عامل تنها در صورتی عملیات نهایی را اجرا میکند که وضعیت به «تایید شده» (Approved) تغییر کند. اگر وضعیت «رد شده» (Rejected) باشد، مسیر کاملاً مسدود میشود.
این منطق از طریق پروتکل زمینهٔ مدل (MCP) و با استفاده از سه ابزار خاص impri_push_action ،impri_await_decision و impri_report_result قابل پیادهسازی است. این موضوع اجازه میدهد تا الگو در کلاینتهایی مثل Claude Code، Cursor یا Claude Desktop بدون نیاز به نوشتن کدهای SDK اختصاصی کار کند.
برای پیادهسازی این دروازه، دو روش وجود دارد که تفاوت آنها حیاتی است؛ زیرا دروازه تنها زمانی واقعی است که مسیر «تایید شده»، تنها راه عامل برای ایجاد اثر در دنیای واقعی باشد:
۱. همکاری (Cooperative): در این حالت، عامل ابزار تایید را فراخوانی میکند، منتظر میماند و سپس خودش عملیات را اجرا میکند. اگرچه این روش بهتر از پرامپت است چون تایید را به یک وابستگی دادهای تبدیل میکند، اما همچنان ریسکی است. اگر عامل در حال حاضر اعتبارنامههای خام ایمیل (Raw Credentials) را در اختیار داشته باشد، یک عامل دارای باگ یا همراستاسازی غلط میتواند مستقیماً تابع ارسال را صدا بزند و مرحله تایید را کاملاً دور بزند. این چالشهای لایهبندی شده، دلیل اهمیت استفاده از تاییدات لایهای در برابر پرامپتهای سادهی بله/خیر است.
۲. رهگیری (Interception): در این روش، ابزار هدف بهگونهای بستهبندی (Wrap) میشود که هر تلاش برای استفاده از ابزار (Tool Use) پیش از اجرا رهگیری شود. در اینجا، مجری (Executor) تا زمانی که تصمیم «تایید شده» بازنگردد، فراخوانی نمیشود. در این حالت، تعریف ابزاری که مدل میبیند بدون تغییر باقی میماند، اما مسیر اجرای فیزیکی از طریق این دروازه هدایت میشود.
حتی در روش رهگیری، سیستم تنها زمانی کار میکند که این Wrapper تنها نقطه گلوگاه (Chokepoint) باشد. دادن کلیدهای خام به عامل یا ایجاد ابزاری دوم که به همان سرویس دسترسی دارد، مانند ساختن «در دوم» است که به عامل اجازه میدهد امنیت را دور بزند.
فرآیند تایید لزوماً نباید در یک داشبورد پیچیده باشد. درخواستها میتوانند به شکل پیامهای دارای دکمههای «تایید» و «رد» در سرویسهایی مثل اسلک، دیسکورد یا تلگرام ارسال شوند تا کاربر بتواند با یک ضربه روی گوشی خود تصمیم بگیرد.
علاوه بر این، سیستم از گردش کار «ویرایش پیش از تایید» (Edit-before-approve) پشتیبانی میکند. این قابلیت به انسان اجازه میدهد تا واژگان یا محتوای یک پیشنویس را اصلاح کند و سپس عامل نسخه ویرایششده را دریافت کرده و اجرا نماید. هر تصمیم در یک گزارش بازرسی (Audit Log) ثبت میشود که ردیابی میکند چه کسی، چه چیزی را در چه زمانی تایید کرده و چه ویرایشهایی صورت گرفته است.
برای کسانی که نمیخواهند سیستم را از صفر بسازند، ابزار متنباز Impri (تحت لایسنس MIT) منتشر شده است که شامل اینباکس، تاییدات چت-محور و گزارش بازرسی است و با یک دستور Docker Compose قابل استقرار است. اگرچه یک نسخه بتا (Hosted) وجود دارد، اما نویسنده مسیر میزبانی شخصی (Self-hosted) را از طریق مخزن گیتهاب (https://github.com/sekera-radim/impri) و مستندات impri.dev توصیه میکند.
این تغییر رویکرد نشان میدهد که با افزایش خودمختاری عاملها، باید ایمنی را بهجای یک مشکل «رفتاری»، به عنوان یک مشکل «مسیریابی» (Routing) ببینیم. هدف این است که عامل را به یک در واحد محدود کنیم و تضمین کنیم که هیچ مسیر دومی به دنیای واقعی باقی نماند.
گام بعدی شما
- اگر از عاملهای AI برای کارهای حساس (مثل ارسال ایمیل یا مدیریت فایل) استفاده میکنید، بررسی کنید آیا دسترسی آنها «مستقیم» است یا از یک لایه رهگیر (Interception) عبور میکند.
- ابزار Impri را از مخزن گیتهاب بررسی کنید تا با مدل «وابستگی دادهای» در تاییدات آشنا شوید.
- در طراحی ابزارهای خود، هرگز اعتبارنامههای خام (API Keys) را در دسترس مستقیم مدل قرار ندهید.
اما چالشهای مدیریت حافظه در این عاملها، پیچیدگیهای بیشتری دارد؛ برای درک نحوه ذخیرهسازی متمرکز، تحلیل ما دربارهی پنجرههای متنی بلندمدت را بخوانید.
گفتگو