عامل‌های هوش مصنوعی به «نایب‌های سردرگم» با دسترسی‌های مدیریتی تبدیل شده‌اند

تصور کنید یک تیکت پشتیبانی ساده حاوی دستوری پنهان باشد که عامل هوش مصنوعی شما را مجبور کند کل پایگاه داده مشتریان را به یک سرور خارجی ارسال کند. این دیگر یک سناریوی تئوریک نیست، بلکه واقعیت عملیاتی برای هر شرکتی است که از عامل‌های خودمختار استفاده می‌کند. به نقل از تحلیل امنیتی دقیقی که در ۱۰ سپتامبر ۲۰۲۶ در dev.to منتشر شد، عامل‌های هوش مصنوعی در حال تبدیل شدن به «نایب‌های سردرگم» (Confused Deputies) هستند؛ بازیگرانی با امتیازات بالا که می‌توانند توسط ورودی‌های غیرقابل‌اعتماد، برای سوءاستفاده از اختیاراتشان فریب بخورند.

این خطر به این دلیل رخ می‌دهد که عامل‌ها مرز سنتی بین احراز هویت کاربر و اجرای کد را از بین می‌برند. در یک اپلیکیشن استاندارد، کد از منطق پیش‌بینی‌پذیری پیروی می‌کند؛ اما در یک سامانه عامل‌محور (Agentic)، منطق تحت تأثیر متن است. اگر یک عامل بتواند ایمیلی مخرب را بخواند و سپس ابزار delete_customer_account را فراخوانی کند، مرز امنیتی دیگر فرم ورود نیست، بلکه هر تکه از محتوای غیرقابل‌اعتمادی است که عامل پردازش می‌کند.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد به لایه‌ی متنی برای کنترل دسترسی، یک اشتباه استراتژیک است. این چالش‌ها در راستای پیش‌بینی‌هایی است که عامل‌های هوش مصنوعی تا سال ۲۰۲۶ نقاط کور امنیتی جدیدی ایجاد می‌کنند.

مسئله نایب سردرگم

خطر اصلی این نیست که هوش مصنوعی «تصمیم بگیرد» بدخواه باشد. بلکه مسئله این است که عامل دارای اعتبارنامه‌های قانونی — مثل توکن‌های API، دسترسی به پایگاه داده یا مجوزهای ابری — است، اما قدرت تشخیص تفاوت بین یک درخواست مشروع کاربر و یک دستور مخرب جاسازی‌شده در یک سند را ندارد.

یک عامل ممکن است مجموعه‌ای از امتیازات گسترده زیر را در اختیار داشته باشد:

• توکن‌های API و محدوده‌های OAuth
• اعتبارنامه‌های پایگاه داده و مجوزهای دسترسی به زیرساخت‌های ابری
• دسترسی به شل (Shell) و سیستم فایل سیستم
• نشست‌های فعال مرورگر و دسترسی به شبکه‌های داخلی سازمان
• توانایی ارسال پیام به انسان‌ها یا تعامل با سامانه‌های دیگر

با این حال، ورودی‌هایی که این امتیازات را هدایت می‌کنند اغلب از منابع غیرقابل‌اعتماد می‌آیند: تیکت‌های مشتریان، ایمیل‌ها، گزارش‌های گیت‌هاب (GitHub issues)، صفحات وب، فایل‌های PDF، رکوردهای پایگاه داده، فایل‌های لاگ یا حتی نتایج حاصل از ابزارهای شخص ثالث. این وضعیت سطح حمله جدیدی می‌سازد که در آن متن غیرقابل‌اعتماد، در ترکیب با استدلال عامل و ابزارهای دارای امتیاز، به مهاجمان اجازه می‌دهد امنیت سنتی را دور بزنند. این تحلیل تأکید می‌کند که تزریق پرامپت (Prompt Injection) — شبیه به گافل کردن یک نگهبان با یک یادداشت جعلی — دیگر فقط یک مسئله ایمنی مدل نیست، بلکه یک مشکل بنیادی در مجوزدهی (Authorization) و جریان داده است.

تزریق پرامپت به مثابه کنترل دسترسی

تزریق پرامپت اغلب به عنوان شکست در ایمنی مدل دیده می‌شود، اما در محیط عملیاتی، این یک مسئله کنترل دسترسی است. در حالی که تزریق مستقیم زمانی رخ می‌دهد که کاربر صراحتاً به عامل می‌گوید قوانین را نادیده بگیرد، تزریق غیرمستقیم بسیار موذیانه‌تر است. در اینجا، دستورات مخرب از طریق محتوایی که عامل پردازش می‌کند می‌رسند؛ مثلاً بدنه تیکتی که می‌گوید «نمی‌توانم وارد شوم»، و بلافاصله پس از آن دستوری پنهان برای فراخوانی ابزار export_customers و ارسال نتایج به یک URL جمع‌آوری‌کننده (Collector URL) قرار دارد.

از آنجا که مدل‌ها یک مرز امنیتی نیستند، صرفاً گفتن این جمله به مدل که «تزریق‌ها را نادیده بگیر»، کافی نیست. اگر تنها چیزی که بین یک متن خصمانه و یک فراخوانی API مخرب، یک پرامپت سیستمی باشد، شما یک سامانه «امیدوارانه» ساخته‌اید، نه یک سامانه امن. بر اساس مستندات این تحلیل، یک الگوی عملی برای برچسب‌گذاری داده‌ها بر اساس سطح اعتماد پیشنهاد می‌شود:

• user_direct: ورودی‌هایی که مستقیماً از کاربر احراز هویت شده می‌آیند.
• internal: داده‌های سیستم‌های داخلی که قابل اعتماد هستند.
• untrusted_external: محتوای ایمیل‌ها، صفحات وب یا اسناد شخص ثالث.

با اجرای سیاستی که در آن اقدامات حساس (مانند send_email یا export_customers یا delete_record) در صورت فعال شدن پس از پردازش محتوای untrusted_external مسدود شوند، توسعه‌دهندگان می‌توانند از اجرای دستورات خصمانه جلوگیری کنند. کنترل‌های تکمیلی شامل الزام به تأیید انسانی پس از پردازش محتوای خارجی، مسدود کردن خروجی‌های شبکه (Egress) پس از خواندن اسناد غیرقابل‌اعتماد و جداسازی کامل عامل‌های خلاصه‌ساز از عامل‌های اجرایی است.

مقاوم‌سازی محیط اجرای ابزار

توسعه‌دهندگان باید با متادیتای ابزارها به عنوان «تأثیر اجرایی» برخورد کنند. نام و توضیحات ابزارها صرفاً مستندات نیستند، بلکه دستوراتی هستند که مدل را هدایت می‌کنند. برای مثال، ابزاری با نام cleanup_old_users برای مدل متفاوت از delete_users_without_recent_login به نظر می‌رسد. توضیحی که پیشنهاد می‌دهد ابزاری را با «امتیازات کامل مدیریتی و بدون تأییدیه» اجرا کند، یک مستند امن نیست، بلکه یک دستور مستقیم برای مدل است.

این موضوع زمانی خطرناک‌تر می‌شود که ابزارها از ریجستری‌های پلاگین شخص ثالث یا سرورهایی که به‌صورت پویا شناسایی می‌شوند، تامین شوند. یک ارائه‌دهنده ابزارِ هک‌شده می‌تواند صرفاً با انتشار متادیتای جذاب یا فریبنده، عامل‌ها را تحت تأثیر قرار دهد. شناسایی ابزارها باید به عنوان یک رویداد موجودی (Inventory Event) تلقی شود، نه یک اعطای اعتماد خودکار.

دفاع‌های عملی عبارتند از:

• هش کردن تعاریف ابزار: استفاده از SHA-256 روی یک نمایش JSON استاندارد از تعریف ابزار برای اطمینان از اینکه هر تغییری در نام، توصیف یا طرح (Schema) ابزار قابل شناسایی باشد و نیاز به یک گیت تأیید جدید داشته باشد.
• برچسب‌گذاری سطح اعتماد: اجرای سیاست‌ها بر اساس منبع داده‌ای که فراخوانی ابزار را تحریک کرده است.
• انسان در حلقه (Human-in-the-Loop): الزام به تأیید صریح انسانی برای اقدامات پرریسک مانند ارسال ایمیل‌های خارجی یا تغییر رکوردهای محیط تولید.
• بازبینی متادیتا: بررسی توصیفات ابزارها مانند کد و اطمینان از اینکه توصیفات طرح (Schema) حاوی هیچ توصیه امنیتی دستوری نباشند.
• کنترل نسخه: هش کردن و نسخه‌بندی متادیتای ابزارها تا هرگونه تغییر قابل ردیابی باشد.

ریسک‌های دسترسی به پایگاه داده و شل

دادن دسترسی «فقط خواندنی» (Read-only) به یک عامل، یک اشتباه رایج است. دسترسی فقط خواندنی همچنان می‌تواند منجر به نشت اطلاعات حساس (PII)، اعتبارنامه‌ها، توکن‌ها، کامنت‌های داخلی، سوابق مالی یا داده‌های مشتریان مختلف (Tenant data) شود. همچنین می‌تواند اطلاعات طرح (Schema) را فاش کند که برای حملات بعدی مفید است. اگر عامل دسترسی نوشتن داشته باشد، می‌تواند کاربران ادمین بسازد، پرچم‌های ویژگی (Feature flags) را تغییر دهد یا داده‌هایی را مسموم کند که عامل‌های دیگر بعداً می‌خوانند؛ این کار یک مکانیسم ماندگاری (Persistence) برای تزریق پرامپت ایجاد می‌کند که در آن ردیف‌های پایگاه داده به دستورات ذخیره‌شده تبدیل می‌شوند.

حفاظ‌های پایگاه داده:

• پرهیز از SQL خام: جایگزینی اجرای SQL دلخواه با توابع محدود و هدفمند مانند get_customer_by_id(customerId)، list_open_tickets(customerId) یا search_orders(customerId, filters).
• لیست سفید شناسه‌ها: برای مرتب‌سازی یا فیلتر کردن پویا، ستون‌ها را در برابر یک مجموعه سخت‌گیرانه (مثلاً created_at یا status یا total_cents) اعتبارسنجی کنید، به جای اینکه رشته‌ها را کورکورانه در کوئری جایگذاری کنید.
• اجرای مرزها: پیاده‌سازی محدودیت‌های مربوط به مستاجر (Tenant scoping)، محدودیت تعداد ردیف‌ها، حذف ستون‌های حساس (Redaction) و تعیین زمان پایان (Timeout) برای کوئری‌ها.
• جداسازی زیرساخت: استفاده از نسخه‌های Read Replica مجزا و منع بازرسی طرح (Schema introspection) در صورت امکان.
• کنترل‌های نوشتن: برای دسترسی نوشتن، استفاده از رکوردهای پیش‌نویس (Draft)، وضعیت‌های در انتظار (Pending)، کلیدهای Idempotency و محدودیت‌های تراکنش را ترجیح دهید.

دسترسی به شل حتی خطرناک‌تر است. عاملی با دسترسی به شل می‌تواند فایل‌ها را بخواند، متغیرهای محیطی را بازرسی کند، اسرار را استخراج کند، پکیج‌ها را نصب کند یا به میزبان‌های داخلی نفوذ کند. بدترین الگو، اجازه دادن به عامل برای ترکیب رشته‌های دستوری است که مستقیماً به تزریق دستور (Command Injection) منجر می‌شود. رویکرد امن‌تر، استفاده از یک «نقشه دستورات ثابت» است؛ جایی که عامل یک تشخیص نام‌گذاری‌شده (مثلاً disk-usage که به df -h متصل است، memory-usage به free -m یا uptime به uptime) را انتخاب می‌کند، نه اینکه خودِ دستور را بنویسد.

کنترل‌های امنیتی شل:

• ایزوله‌سازی: اجرای ابزارهای شل در یک کانتینر یا microVM با استفاده از یک کاربر اختصاصی غیر-root.
• محدود کردن محیط: مونت کردن سیستم‌فایل‌ها به‌صورت فقط خواندنی، مسدود کردن نقاط انتهایی متادیتای ابری و حذف متغیرهای محیطی غیرضروری (مثلاً تنظیم PATH روی /usr/bin:/bin).
• اعتبارسنجی سخت‌گیرانه: اگر آرگومان‌ها ضروری هستند (مثلاً مسیر ریپوزیتوری برای git log)، از Regexهای سخت‌گیرانه استفاده کنید تا مطمئن شوید مسیر در یک دایرکتوری امن است (مثلاً /srv/safe-repos/[a-z0-9-]+)
• محدودیت منابع: محدود کردن CPU، حافظه (مثلاً ۲۵۶ مگابایت) و زمان اجرا برای جلوگیری از حملات منع سرویس (DoS).
• ایمنی اجرا: استفاده از execFile به جای exec برای جلوگیری از تفسیر شل (Shell interpolation) و تنظیم GIT_TERMINAL_PROMPT: "0" برای ابزارهای گیت.

نشت اسرار و خروج شبکه

عامل‌هایی که قادر به ارسال درخواست‌های HTTP هستند، بردارهای طبیعی برای حملات SSRF (جعل درخواست سمت سرور) هستند. بدون لیست‌های سفید خروجی (Egress allowlists) سخت‌گیرانه، یک عامل می‌تواند به سمت نقاط انتهایی متادیتای داخلی (مانند 169.254.169.254)، داشبوردهای مدیریتی، سرویس‌های localhost یا APIهای خصوصی ابری سوق داده شود. اگر عاملی بتواند هم داده‌های حساس را بخواند و هم URLهای خارجی را فراخوانی کند، می‌تواند آن داده‌ها را خارج کند. برای مقابله با این نوع نشت داده‌ها، می‌توان از معماری‌هایی مانند TrustGraph برای محدود کردن خروجی‌ها بهره برد.

برای جلوگیری از این اتفاق، توسعه‌دهندگان باید سیاست خروجی (Egress Policy) را اجرا کنند که محدوده‌های IP خصوصی و آدرس‌های Link-local را مسدود کرده، HTTPS را اجبار کند و اقدامات خواندن/نوشتن را با هم مرتبط سازد. برای مثال، سیستم می‌تواند خروج خارجی را برای یک بازه زمانی کوتاه (مثلاً ۱۰ دقیقه) بلافاصله پس از دسترسی عامل به داده‌های حساس مسدود کند. همچنین، حملات DNS rebinding و زنجیره‌های تغییر مسیر (Redirect chains) نیازمند کنترل‌های در سطح زیرساخت هستند.

علاوه بر این، اسرار (Secrets) اغلب از طریق متغیرهای محیطی، پیام‌های خطا یا نتایج ابزارها به بستر متن (Context) عامل نشت می‌کنند. وقتی یک راز وارد کانتست شود، مدل ممکن است آن را در یک خلاصه تکرار کند، در یک پچ تولید شده بگنجاند یا به یک ابزار خارجی ارسال کند. راهکار توصیه شده، تزریق اسرار مستقیماً به پیاده‌سازی ابزار از طریق یک واسط اسرار (Secret Broker) است تا برای فرآیند استدلال مدل کاملاً نامرئی بمانند. همچنین، باید از پیش‌پردازشگرها برای حذف الگوهای شناخته شده مانند کلیدهای دسترسی AWS (AKIA...)، کلیدهای API (sk-...) یا توکن‌های Bearer قبل از ورود به کانتکست مدل استفاده شود.

معماری تولید برای عامل‌های امن

طبق گزارش dev.to، یک معماری امن باید مرزهای سیاستی سختی را دور عامل قرار دهد. عامل فقط باید یک اقدام را «پیشنهاد» کند، که سپس توسط یک موتور سیاست و موتور ریسک مجزا بررسی شده و در نهایت در یک محیط ایزوله اجرا شود.

اجزای این معماری:

• موتور سیاست (Policy Engine): تصمیم می‌گیرد چه دسته‌هایی از اقدامات بر اساس محیط (تست یا تولید) و کانتکست اعتماد مجاز هستند. پیش‌فرض باید deny (رد) باشد و اقدامات خاص را صراحتاً اجازه دهد (مثلاً اجازه logs.read در محیط تست برای کانتکست‌های internal را بدهد، اما policy.update را برای هر عاملی منع کند).
• موتور ریسک (Risk Engine): کانتکست را ارزیابی می‌کند؛ می‌پرسد آیا اقدام بازگشت‌ناپذیر است، آیا هدف محیط تولید است، آیا ورودی غیرقابل‌اعتماد بوده، آیا ابزار تازه اضافه شده یا هزینه اجرا بالا است.
• مجری ایزوله (Sandboxed Executor): ابزارها را با حداقل امتیازات اجرا می‌کند (مثلاً: docker run --rm --user 10001:10001 --read-only --network none --memory 256m --cpus 0.5).
• لایه تأیید: اجرای عامل را برای اقدامات پرریسک متوقف کرده و از انسان می‌خواهد argsHash را بازبینی کرده و اجازه دهد. این کار از تبدیل شدن عامل به یک ریسک که می‌تواند به‌طور خودکار پایگاه داده را پاک کند یا داده‌ها را خارج کند، جلوگیری می‌کند.

زنجیره تأمین و قابلیت حسابرسی

سرورهای ابزار شخص ثالث (مانند سرورهای مدل MCP) ریسک‌های زنجیره تأمین را وارد می‌کنند. یک ابزار که توسط جامعه مدیریت می‌شود، می‌تواند کوئری‌ها را به‌صورت خارجی لاگ کند یا نتایجی را با دستورات جاسازی‌شده برای ربودن عامل برگرداند. توسعه‌دهندگان باید مدل لایه‌بندی اعتماد را بپذیرند:

• داخلی شخص اول: حسابرسی کامل، اعتبارنامه‌های محدود شده.
• تجاری تأییدشده: بازبینی قراردادی، اجرای ایزوله.
• متن‌باز جامعه: بازبینی کد، محیط سندباکس، منع اقدامات حساس.
• ابزار راه دور ناشناخته: هرگز به عامل‌های محیط تولید متصل نشود.

در نهایت، لاگ‌های حسابرسی باید از حالت عیب‌یابی (Debugging) خارج شده و به بخشی از مدل امنیتی تبدیل شوند. یک لاگ آماده تولید باید ورودی اثرگذار بر عامل، تصمیم سیاستی که اجازه اقدام را داده و نتیجه نهایی را به هم مرتبط کند. یک رویداد حسابرسی مفید باید شامل runId، argsHash، policyDecision (اجازه/رد/نیاز به تأیید) و trustLevel منبع داده باشد. لاگ‌ها باید فقط-افزودنی (Append-only)، مقاوم در برابر دستکاری و بر اساس سطح ریسک قابل جستجو باشند. بدون این‌ها، عامل صرفاً یک «جعبه سیاه با اعتبارنامه‌های مدیریتی» باقی می‌ماند.

این تغییر دیدگاه به این معناست که عامل‌های هوش مصنوعی قوانین امنیتی جدیدی ایجاد نمی‌کنند؛ آن‌ها صرفاً مشکلات قدیمی — مانند تزریق و ارتقای امتیازات — را در قالبی سریع‌تر و خودمختارتر فشرده می‌کنند. هدف، اجتناب از ابزارها نیست، بلکه پیچیدن آن‌ها در لایه‌های ایزولاسیون و کنترل انسانی است. یک عامل نباید به این دلیل مورد اعتماد باشد که سخنانش منطقی به نظر می‌رسد؛ بلکه تنها زمانی باید اجازه اقدام داشته باشد که سیستم از قبل تصمیم گرفته باشد این نوع اقدام، در این کانتکست و با این شعاع تخریب (Blast Radius)، به اندازه کافی امن است.

برای ایمن‌سازی استک فعلی خود، با بازبینی اعتبارنامه‌های عامل‌ها و پیاده‌سازی یک لیست سفید خروجی سخت‌گیرانه برای تمام ابزارهای دارای قابلیت HTTP شروع کنید.

گام بعدی شما

• اعتبارنامه‌های فعلی عامل‌های خود را بازبینی کنید و هر دسترسی مدیریتی غیرضروری را حذف کنید.
• برای تمام ابزارهای دارای قابلیت HTTP، یک لیست سفید خروجی (Egress Allowlist) سخت‌گیرانه پیاده‌سازی کنید.
• برای اقدامات حساس (مانند حذف داده یا ارسال ایمیل خارجی)، لایه تأیید انسانی را اجباری کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.