تصور کنید یک پیمانکار تازه‌کار را بدون هیچ‌گونه مصاحبه یا بررسی پیشینه‌ای استخدام کرده‌اید و در همان دقایق اول، کلیدهای خزانه و دسترسی کامل به سرورهای حساس شرکت را به او داده‌اید. این دقیقاً همان اتفاقی است که هنگام راه‌اندازی عامل‌های هوش مصنوعی (AI Agents) می‌افتد. در حالی که یک نیروی انسانی ممکن است روزها برای دریافت دسترسی به ایمیل یا مخازن کد منتظر بماند و در مسیری کند از تهیه لپ‌تاپ و ارسال درخواست‌های تیکتی برای مجوزها پیش برود، یک عامل هوش مصنوعی اغلب در کمتر از یک دقیقه فعال می‌شود. این عامل‌ها معمولاً کار خود را با دسترسی کامل به محیط (Shell)، کلیدهای شخصی API که از قبل در محیط تعریف شده‌اند، دسترسی شبکه بدون محدودیت و دسترسی خواندن به کل دایرکتوری خانگی کاربر — از جمله پوشه .ssh که بسیاری از کاربران فراموش می‌کنند آن را محافظت کنند — آغاز می‌کنند.
طبق تحلیل امنیتی منتشرشده در ۴ جولای ۲۰۲۶ در وب‌سایت dev.to، این شکاف باعث ایجاد یک نقطه ضعف عظیم می‌شود که در آن عامل‌ها به‌طور ساختاری تبدیل به «نماینده‌های گیج‌شده» (Confused Deputies) می‌گردند. این آسیب‌پذیری تداعی‌کننده حوادثی است که در آن نقص‌های مشابه منجر به نشت گسترده داده‌ها شد؛ برای نمونه می‌توان به نقص «نایب سرگردان» در عامل‌های متا اشاره کرد که منجر به افشای اطلاعات هزاران حساب کاربری گردید. همان‌طور که در تحلیل قبلی ما درباره‌ی تغییرات توکنایزر در مدل‌های Claude Sonnet 5 و اثر آن بر جهش هزینه‌های عامل‌ها اشاره کردیم، ریسک‌های عملیاتی همواره وجود دارند، اما شکاف‌های امنیتی اکنون تهدیدی وجودی ایجاد کرده‌اند که فراتر از ضررهای مالی است و می‌تواند کل زیرساخت را به خطر اندازد.
مکانیسم «نماینده گیج‌شده»
در مدل سنتی کنترل دسترسی، فرض بر این است که صاحب حساب تصمیم می‌گیرد حساب چه کاری انجام دهد. اگر یک کارآموز انسانی اشتباهی مرتکب شود، دستورات همچنان از مغز خود او صادر شده است. اما یک عامل هوش مصنوعی، دستورات خود را از هر متنی که با آن برخورد کند می‌گیرد. این منابع شامل موارد زیر است:
- پرامپتی که شما به‌صورت دستی تایپ کرده‌اید.
- صفحات وب که عامل در حین مرور وب‌گردی دریافت می‌کند.
- فایل‌های README در مخازنی که کلون (Clone) شده‌اند.
- کامنت‌های مربوط به Issueها که از طریق API خوانده می‌شوند.
- توصیف ابزارهایی که در پنجره متنی (Context Window) — مثل میز کاری که جا برای چند ورق دارد، نه برای کل کتابخانه — بارگذاری می‌شوند.
این بدان معناست که هر کانال ورودی، در واقع یک کانال فرمان احتمالی است. اگرچه سازندگانی مثل OpenAI و Anthropic در حال بهبود مقاومت مدل‌ها در برابر تزریق پرامپت (Prompt Injection) هستند، اما شما نمی‌توانید کلیدهای SSH خود را به این امید که یک مدل هر بار به دستور مخرب بگوید «نه»، به خطر بیندازید. با این حال، حتی با وجود ابزارهای امنیتی، اتکای کامل به هوش مصنوعی بدون نظارت انسانی ریسک‌های جدی دارد؛ چنان‌که رویکرد «میز قتل» نشان می‌دهد چرا مدل‌های هوش مصنوعی در شکار باگ‌های امنیتی پیچیده بدون دخالت انسان شکست می‌خورند. برای بستن این شکاف، تحلیل مذکور یک چارچوب سخت‌گیرانه شامل ۶ قانون برای محصورسازی (Containment) پیشنهاد می‌دهد تا امنیت از یک «چک‌باکس اداری» به یک «مرز عملیاتی» تبدیل شود:
۱. محدودسازی بر اساس وظیفه (Task-Based Scoping)
از دسترسی‌های کلی و Wildcard مانند Bash(*) پرهیز کنید. این دسترسی‌ها اغلب به این دلیل استفاده می‌شوند که تعریف دسترسی‌های محدود خسته‌کننده است؛ اما Bash(*) اجازه می‌دهد هر دستور تزریق‌شده‌ای که در شل شما قابل اجراست، توسط مهاجم اجرا شود. به جای آن، فقط دستورات خاص مورد نیاز برای آن وظیفه را اجازه دهید:
- برای کارهای مربوط به مخزن کد، فقط از
Bash(git *)استفاده کنید. - برای کارهای مربوط به CI، فقط
Bash(npm run test)را فعال کنید.
هرگاه یک وظیفه قانونی به دلیل نبود دسترسی شکست خورد، لیست مجوزها را تنها یک خط گسترش دهید. این اصطکاک عمدی است؛ دقیقاً همان اصطکاکی که باعث می‌شود پیش از دادن دسترسی محیط عملیاتی (Production) به یک کارآموز، دوباره فکر کنید.
۲. هویت‌های اختصاصی (Dedicated Identities)
هرگز توکن شخصی خود را به عامل ندهید. برای هر عامل یک هویت خدماتی (Service Identity) مجزا با حداقل دسترسی (Minimal Scopes) و اعتبار کوتاه‌مدت تعریف کنید. این کار دو مشکل اساسی را حل می‌کند:
- شعاع انفجار (Blast Radius): اگر کلیدی از طریق یک تلاش برای استخراج داده (Exfiltration) نشت کند، شما تنها یک کلید محدود را تغییر می‌دهید، نه اینکه کل زندگی دیجیتال خود را بازنشانی کنید.
- ردپای بازرسی (Audit Trails): یک هویت مجزا به شما اجازه می‌دهد دقیقاً تشخیص دهید کدام اقدامات توسط عامل انجام شده و کدام توسط شما؛ این موضوع در زمان وقوع خطا حیاتی است.
۳. زندانی کردن سیستم فایل (Filesystem Jailing)
عامل را به یک دایرکتوری کاری واحد محدود کنید که فقط در آنجا اجازه نوشتن داشته باشد. تمام متریال‌های مرجع باید به‌صورت «فقط خواندنی» (Read-only) متصل (Mount) شوند. هر چیز دیگر — از جمله dotfiles، پروفایل‌های مرورگر و ذخیره‌سازهای رمز عبور — اصلاً نباید برای عامل قابل شناسایی یا دسترسی باشد.
توجه ویژه‌ای به محیط (Environment) داشته باشید. اگر اسرار (Secrets) در متغیرهای محیطی باشند که شلِ عامل آن‌ها را به ارث می‌برد، هر دستور «دامپ محیط» (Environment Dump) به یک ابزار سرقت داده تبدیل می‌شود. دستور «چاپ متغیرهای محیطی برای عیب‌یابی»، یکی از قدیمی‌ترین و رایج‌ترین متدهای تزریق پرامپت است. اسرار باید در یک مدیریت‌کننده یا بروکر (Broker) باقی بمانند که آن‌ها را به پروسه‌های خاص تحویل می‌دهد، نه در فضای نامی (Namespace) که عامل بتواند آن‌ها را فهرست کند.
۴. فهرست سفید شبکه‌ای (Network Allowlisting)
عاملی که بتواند یک رمز را بخواند اما نتواند آن را به دنیای بیرون ارسال کند، برای مهاجم کاربرد بسیار کمی دارد. از آنجایی که اکثر دستورات تزریقی برای ارسال داده‌ها به بیرون نیاز به دسترسی شبکه دارند، شما باید راه خروج را ببندید.
فهرست‌های سفید خروجی (Egress Allowlists) کنترل‌های بسیار ارزشمندی هستند: فقط دامنه‌هایی را فهرست کنید که عامل واقعاً به آن‌ها نیاز دارد و بقیه را به‌صورت پیش‌فرض مسدود (Deny) کنید. گزارش‌های مربوط به مسدودسازی‌ها در اینجا به عنوان یک منبع تشخیص رایگان عمل می‌کنند؛ زیرا تلاش ناگهانی یک عامل برای دسترسی به دامنه‌ای تأیید نشده، سیگنال اصلی یک حمله است.
۵. تایید انسانی برای اقدامات غیرقابل‌بازگشت (Irreversible Action Gating)
برای اقداماتی که نمی‌توان آن‌ها را به حالت قبل برگرداند، حتماً تایید انسانی بخواهید. این موارد شامل:
- ارسال پیام‌ها یا انتشار محتوا در فضای عمومی.
- حذف داده‌ها.
- هزینه کردن پول.
- اعطای دسترسی‌های جدید به کاربران یا عامل‌های دیگر.
برای جلوگیری از «خستگی از هشدار» (Alert Fatigue) — وضعیتی که در آن کاربر بدون خواندن، دکمه تایید را می‌زند — این لیست را کوتاه نگه دارید. اقدامات بازگشت‌پذیر را اتوماتیک کنید و فقط موارد غیرقابل‌بازگشت را به‌صورت دستی تایید نمایید.
۶. بازرسی و هرس منظم (Regular Audit and Trim)
تمام فراخوانی‌های ابزار (Tool Call) را ثبت (Log) کنید. پس از دو هفته، گزارش‌ها را بررسی کرده و هر دسترسی که عامل هرگز از آن استفاده نکرده است را پس بگیرید. «تورم امتیازات» (Privilege Creep) در عامل‌ها سریع‌تر رخ می‌دهد، زیرا دادن دسترسی تنها با یک کلیک انجام می‌شود، اما سیستمی برای یادآوری لغو آن وجود ندارد. بررسی ماهانه کافی است تا بپرسید: «این هویت واقعاً چه کاری انجام داد و چرا دسترسی‌اش بیشتر از نیاز است؟»
این رویکرد با عامل مانند یک نیروی تازه‌وارد باهوش اما بدون درک زمینه برخورد می‌کند که ممکن است «یادداشت‌های» غریبه‌ها را در اینباکس خود دریافت کرده و اجرا کند. شما هرگز به چنین شخصی دسترسی Root نخواهید داد. با فرض اینکه عامل در نهایت مورد تزریق موفق قرار خواهد گرفت، هدف از «جلوگیری از هر حادثه» به «بقاء در برابر حوادث» تغییر می‌کند. وقتی «روز بد» فرا می‌رسد، می‌خواهید آن اتفاق تنها یک مزاحمت باشد، نه یک فاجعه وجودی.
خلاصه سیاست‌های پیشنهادی برای پیاده‌سازی
برای کسانی که امروز قصد پیاده‌سازی این موارد را دارند، شکل توصیه‌شده سیاست‌ها به این قرار است:
- مجوزها: فهرست سفید صریح، بدون Wildcard.
- هویت: کلیدهای اختصاصی، محدودترین دامنه دسترسی، اعتبار کوتاه‌مدت.
- سیستم فایل: یک فضای کاری قابل نوشتن، سایر نقاط فقط-خواندنی، عدم دسترسی به dotfiles و پروفایل مرورگر.
- شبکه: فهرست سفید خروج، مسدودسازی پیش‌فرض، ثبت گزارش مسدودسازی‌ها.
- تاییدیه: الزامی برای ارسال، انتشار، حذف، پرداخت یا اعطای دسترسی.
- اسرار: ذخیره در مدیریت‌کننده (Manager)، هرگز در متغیرهای محیطی یا فایل‌های قابل خواندن.
- نگهداری: بررسی ماهانه و حذف مجوزهای بلااستفاده.
زمانی که سیستم فایل عامل خود را زندانی کردید، گام بعدی باید بازرسی گزارش‌های خروجی (Egress Logs) باشد تا دقیقاً شناسایی کنید عامل شما برای عملکرد صحیح، به کدام دامنه‌های خارجی نیاز دارد.
گام بعدی شما
- دسترسی‌های Bash عامل‌های خود را از حالت Wildcard خارج کرده و به دستورات خاص محدود کنید.
- کلیدهای API شخصی را با Service Accounts جایگزین کنید.
- لیست خروجی‌های شبکه (Egress) را بررسی کرده و دامنه‌های غیرضروری را ببندید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو