تصور کنید یک خطای بحرانی در کد سیستم شما رخ داده، اما در گزارش‌های محیط عملیاتی، تنها متنی کلی می‌بینید که می‌گوید «هوش مصنوعی این تغییر را اعمال کرد». اگر از سامانه‌های چندعاملی استفاده می‌کنید، این ابهام دقیقاً همان نقطه‌ای است که امنیت و قابلیت پاسخگویی سازمان شما را به خطر می‌اندازد. در یک سناریوی پیچیده که وظایف بین چندین زیر-عامل (Sub-agent) تقسیم شده است، یک جریان گزارش (Trace) مشترک باعث می‌شود که چه کسی عملاً یک اقدام خاص را انجام داده و چرا این کار صورت گرفته، در پشت یک لایه ماسک شده و پنهان بماند.
به گزارش Armorer Labs، در سامانه‌هایی که چندین عامل (Agent) — شبیه به تیمی از کارمندان متخصص که هر کدام دسترسی‌های متفاوتی به فایل‌ها دارند — با هم همکاری می‌کنند، استفاده از یک جریان گزارش مشترک باعث می‌شود مشخص نشود چه کسی، چرا و با چه دسترسی‌ای یک اقدام خاص را انجام داده است. این وضعیت یک «شکاف نظارتی» خطرناک و یک نقطه شکست عملیاتی برای هر تیمی که هوش مصنوعی چندعاملی را مستقر می‌کند، ایجاد می‌کند. طبق مستندات فنی این شرکت، بحرانی‌ترین شکست‌ها دقیقاً در «درز» (Seam) یا همان نقطه انتقال وظیفه بین دو عامل رخ می‌دهد. در حالی که مشکل حسابرسی برای یک عامل واحد کوچک است — زیرا تنها یک اجرا، یک مجموعه فراخوانی ابزار و یک جریان رسید وجود دارد — اما وقتی تیمی از عامل‌ها وارد عمل می‌شوند، این مسئله به‌طور ناگهانی بسیار سخت‌تر می‌شود. این چالش‌ها در واقع ریشه در نبود استانداردهای دقیق در تبادل وظایف دارد؛ موضوعی که در بررسی قوانین قراردادی برای جلوگیری از شکست سامانه‌های چندعاملی به تفصیل به آن پرداخته‌ایم.
حالت شکست در انتقال وظیفه
در یک گردش کار واقعی در محیط تولید، ممکن است یک عامل تیکت را بخواند، برنامه اصلاحی را طراحی کند و سپس اجرای تغییرات فایل را به عامل دوم (عامل B) بسپارد؛ چرا که عامل B ابزارهای مناسب‌تر و محدوده دسترسی (Scope) محدودتر و دقیق‌تری دارد. اگر این دو عامل یک گزارش مشترک داشته باشند، توسعه‌دهنده‌ای که صبح روز بعد یک Pull Request را بررسی می‌کند، نمی‌تواند به‌راحتی تشخیص دهد کدام زیر-عامل یک تغییر کد (Diff) خاص را اعمال کرده یا در لحظه نوشتن کد، اعتبارنامه‌های کدام عامل فعال بوده است.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، نبود شفافیت در سطح دسترسی‌ها می‌تواند منجر به آسیب‌های گسترده شود. در این ساختار، فقدان جزئیات باعث می‌شود ردیابی جریان اقتدار (Flow of Authority) تقریباً غیرممکن شود. به‌طور مشخص، تیم‌ها نمی‌توانند به‌راحتی به این چهار پرسش پاسخ دهند:
- کدام زیر-عامل این تغییر کد (Diff) خاص را تولید کرد؟
- در لحظه اعمال تغییر، جلسه (Session) کدام زیر-عامل اعتبارنامه دسترسی به نوشتن را در اختیار داشت؟
- اگر تغییر اشتباه بود، محدوده تأیید (Approval Scope) کدام عامل دقیقاً این نوشتار را پوشش می‌داد؟
- در کجای این زنجیره، یک دستورالعمل غیرقابل‌اعتماد از بستر عامل A به پرامپت عامل B منتقل شد؟
برای حل این مشکل، Armorer Labs الگوی «رسید تحویل» (Handoff Receipt) را معرفی کرده است. این رسید به‌جای یک گزارش کلی و متنی، یک رکورد ساختاریافته است که دقیقاً در لحظه تفویض اختیار تولید می‌شود. این رکورد تضمین می‌کند که انتقال بین جلسات، صریح و به‌صورت رشته‌ای قابل جست‌وجو (Grep-able) باشد.
جزئیات رسید تحویل
بر اساس چارچوب ارائه شده توسط Armorer Labs، تحویل وظیفه همان «درز» بین دو جلسه مجزا است و این درز استحقاق دارد که رکورد مخصوص به خود را داشته باشد. هر رسید تحویل باید داده‌های مشخص و حیاتی زیر را حمل کند:
- پیوندهای شناسایی: ثبت هر دو شناسه‌ی اجرای والد (Parent Run ID) و فرزند (Child Run ID).
- پرامپت دقیق: متن واقعی و کامل وظیفه ارسالی به فرزند، نه یک خلاصه یا بازنویسی از آن.
- تفاوت محدوده (Scope Delta): مقایسه دقیق شیء محدوده (Scope Object) که فرزند به ارث برده است در برابر آنچه واقعاً استفاده کرده است؛ تفاوت میان این دو، نقطه بحرانی حسابرسی است.
- شناسایی اعتبارنامه: هویت دقیق مورد استفاده برای اقدام، مانند یک حساب سرویس (Service Account) اختصاصی برای هر عامل، توکن OAuth محدود شده، یا یک کلید موقت (Ephemeral Key).
- اشاره به استدلال: پیوندی به زنجیره تفکر (Reasoning Trail) والد در لحظه تفویض، تا بازبین بفهمد والد هنگام انتخاب این فرزند خاص برای انجام وظیفه، به چه چیزی فکر می‌کرده است.
- تصمیمات سیاستی: لیستی کوتاه از تصمیمات، از جمله اینکه آیا محدوده فرزند محدودتر از والد بود، آیا اقدام انجام شده قابل بازگشت (Reversible) بود و آیا خودِ عملیات تحویل طبق قوانین سطح‌بندی (Tier Rules) نیاز به تأیید انسانی داشت یا خیر.
این سازوکار متفاوت از حفاظ‌های معمول در فراخوانی ابزار (Tool-call Guard) عمل می‌کند. در حالی که رسید فراخوانی ابزار ردیابی می‌کند که «چه توانایی‌ای» فراخوانی شده است (مثلاً یک تماس MCP، هدف، آرگومان‌ها و تصمیم سیاستی)، رسید تحویل توضیح می‌دهد که «چرا» آن زیر-عامل خاص در وهله اول اجازه داشت آن تماس را برقرار کند.
بدون این تفکیک، تیم‌ها با پدیده‌ای به نام «نمایش تأیید» (Approval Theater) مواجه می‌شوند؛ وضعیتی که در آن یک عامل والد اقدامی را تأیید می‌کند، در حالی که خودش بستر و اطلاعات لازم برای ارزیابی درست آن اقدام را ندارد. این جداسازی تنها راه شناسایی «لغزش محدوده» (Scope Drift) است؛ یعنی جایی که یک عامل فرزند به‌طور مخفیانه از محدوده دسترسی گسترده‌تری نسبت به آنچه به او سپرده شده استفاده می‌کند، یا مواردی که تزریق پرامپت در بستر والد، باعث آلودگی فراخوانی‌های ابزاری در فرزند می‌شود.
پیاده‌سازی هویت جلسه برای هر عامل
این رویکرد بر پایه الگوی هویت جلسه مجزا برای هر عامل بنا شده است. اگر هر زیر-عامل اعتبارنامه، شیء محدوده و جریان رسید مخصوص خود را داشته باشد، لحظه تحویل، نقطه‌ی اتصال صریح این هویت‌هاست. اگر زیر-عامل‌ها به‌جای این کار، یک اعتبارنامه و محدوده مشترک داشته باشند، مسیر حسابرسی به یک توده (Blob) واحد و دشوار تبدیل می‌شود که در آن تنها می‌توان گفت «عامل این کار را کرد» و جزئیات گم می‌شوند.
برای توسعه‌دهندگانی که در حال حاضر امکان ساخت یک محیط زمان-اجرا (Runtime) کامل را ندارند، این شرکت یک نقطه شروع عمل‌گرایانه پیشنهاد می‌دهد که نیازی به فورک کردن سیستم ندارد:
۱. اختصاص یک شناسه‌ی ثابت و قابل جست‌وجو به هر زیر-عامل.
۲. ثبت یک رکورد تحویل دقیقاً پیش از نخستین فراخوانی ابزار توسط زیر-عامل.
۳. ثبت یک رکورد بستن جلسه (Close-out Record) هنگامی که زیر-عامل کار خود را به پایان می‌رساند، به طوری که به شناسه‌ی اجرای والد و اثرات جانبی (Side Effects) حاصله ارجاع دهد.
نگاه به رکوردهای تحویل به عنوان مصنوعات درجه اول (First-class Artifacts) و تبدیل آن‌ها به بخشی از چک‌لیست بازبینی پس از اجرا، تفاوت میان داشتن یک گزارش مشترک ساده و دانستن واقعی این است که «چه کسی، چه کاری را انجام داده است».
تعیین منبع معتبر
در حال حاضر Armorer Labs در حال ارزیابی این موضوع است که این رکورد باید در کجا تولید شود. آن‌ها سه مکان محتمل را بررسی می‌کنند:
- توسط عامل والدِ سازمان‌دهنده (Orchestrating Parent) به عنوان بخشی از خروجی برنامه‌ریزی‌اش.
- توسط زمان-اجرایی (Runtime) که میزبان زیر-عامل در لحظه ایجاد (Spawning) است.
- توسط یک سطح کنترل مشترک (Shared Control Plane) که هر دو عامل والد و فرزند در آن ثبت‌نام می‌کنند.
این شرکت تمایل دارد تولید رکورد در Runtime صورت گیرد، زیرا این تنها جایی است که هر دو طرفِ «درز» را می‌شناسد و می‌تواند جداسازی اعتبارنامه‌ها و محدوده‌ها را اجبار کند. اگر عامل والد منبع معتبر باشد، کل سیستم در برابر حملات تزریق پرامپت (Prompt Injection) آسیب‌پذیر خواهد بود.
این تغییر معماری، هسته اصلی طراحی Armorer (یک سطح کنترل محلی) و Armorer Guard (یک اسکنر مبتنی بر Rust که سیاست‌ها را در مرزهای فراخوانی ابزار اعمال می‌کند) است. با جداسازی رکورد تحویل از خروجی متنی خود عامل، سیستم یک مسیر حسابرسی آماده برای جرم‌شناسی دیجیتال (Forensics-ready) برای عامل‌های نرم‌افزاری ایجاد می‌کند.
گام بعدی شما
- اگر از سامانه‌های چندعاملی استفاده می‌کنید، بررسی کنید آیا در حال حاضر گزارشات شما «توده‌ای» است یا هر عامل هویت مستقلی دارد.
- برای هر انتقال وظیفه بین عامل‌ها، یک رکورد حاوی «تفاوت محدوده دسترسی» (Scope Delta) تعریف کنید تا از لغزش محدوده جلوگیری شود.
- به جای تکیه بر تأییدات عامل والد، یک چک‌لیست بازبینی پس از اجرا (Post-run Review) بر اساس رسیدهای تحویل ایجاد کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو