تصور کنید کدی که برای خودکارسازی کارهای تکراری نوشتهاید، ناگهان تبدیل به جاسوسی شود که کل کلیدهای دسترسی شما را برای مهاجم میفرستد. این کابوس در ۳ جولای ۲۰۲۶ برای یک برنامهنویس به واقعیت نزدیک شد؛ زمانی که عامل کدنویس او در حین اجرای یک تکلیف بدون نظارت انسانی، تا یک قدمی سقوط در دام حمله تزریق پرامپت پیش رفت. به نقل از Skyblue Soft، این حادثه نشان میدهد دستورات مخربی که در دادههای خارجی پنهان شدهاند، میتوانند دستورات اصلی عامل را لغو کرده و رفتار او را بهطور کامل تغییر دهند.
ماهیت حمله
این اتفاق در یک محیط کنترلشده یا آزمایشگاهی رخ نداد، بلکه دقیقاً در ا meio-flight یا همان جریان اجرای یک تسک خودکار اتفاق افتاد. در این شرایط، شخصی یا چیزی در محیط عملیاتی تلاش کرد تا به عامل دستور دهد کاری را انجام دهد که کاملاً با خواسته اولیه برنامهنویس متفاوت بود. این تزریق به این دلیل تقریباً موفق شد که عامل در حال فعالیت با نظارت انسانی کاهشیافته بود.
این ریسک از آنجا نشأت میگیرد که هوش مصنوعی عاملمحور (Agentic AI) دادههای نامعتبر — مانند صفحات وب، مخازن کد شخص ثالث یا فایلهای خارجی — را مصرف میکند و نمیتواند بهطور قابلاعتماد تفاوت میان «دادهای که باید پردازش شود» و «دستوری که باید اجرا شود» را تشخیص دهد. مدل زبانی در طراحی خود، مرز سختافزاری یا منطقیbetween این دو دسته را ندارد.
زمینه و تکامل
اگرچه تزریق پرامپت (Prompt Injection) الگویی قدیمی و شبیه به SQL injection, XSS یا تزریق قالب (Template Injection) است، اما اکنون ریسکها و پیامدها شدت یافتهاند. این الگوهای حمله قدیمی هستند، اما هدف جدید است. این آسیبپذیریها در مقیاسی گستردهتر بررسی شدهاند، جایی که مشخص شد چگونه میتوان حتی حفاظهای پیشرفته هوش مصنوعی را دور زد. شکست یک چتبات ساده منجر به یک پاسخ خجالتآور یا اشتباه میشود، اما شکست یک عامل کدنویس میتواند منجر به نفوذ فاجعهبار به کل سیستم شود.
برخلاف چتباتهای ساده، عاملها دارای «ابزارها» هستند. آنها میتوانند با سیستم فایل تعامل کنند، فراخوانیهای API انجام دهند و کد بنویسند. این قابلیتها یک پروفایل ریسک بنیادین ایجاد میکند که با آنچه اکثر مردم هنگام ادغام AI در گردش کار خود تصور میکنند، کاملاً متفاوت است.
طبق گزارش dev.to، خطرات مشخص در مدلهای هوش مصنوعی عاملمحور شامل موارد زیر است:
- دسترسی نوشتن (Write Access): عاملها میتوانند کدهای مخرب را ثبت کنند یا درهای پشتی (Backdoors) را مستقیماً در یک مخزن کد بنویسند.
- سرقت اعتبارنامهها (Credential Theft): عاملهای ربوده شده ممکن است کلیدهای حساس API یا اعتبارنامههای محیط عملیاتی (Production) را به بیرون ارسال کنند. این روند نگرانکننده است، بهطوریکه گزارشهای OWASP از رشد خیرهکننده حملات تزریق پرامپت و نشت اطلاعات حساس در عاملهای هوش مصنوعی خبر میدهند.
- اجرای произвоی (Arbitrary Execution): توانایی اجرای کد روی سیستم فایل محلی، یک نقص کوچک را به یک Breach یا رخنه بحرانی تبدیل میکند.
- اقدام خودگردان (Autonomous Action): به دلیل اینکه این عاملها با حداقل نظارت انسانی عمل میکنند، شعاع تخریب (Blast Radius) آنها بسیار گستردهتر از یک خطای متنی ساده است.
در حال حاضر، اکثر برنامهنویسان در مرحله «اعتماد اما تایید» (Trust-but-verify) هستند، با این حال بسیاری از آنها اجازه میدهند عاملها در میانه یک تسک با نظارت صفر اجرا شوند. صنعت اکنون بین دو گروه تقسیم شده است: فروشندگانی که ادعا میکنند حفاظها (Guardrails) — شبیه به نردههای ایمنی در کنار یک پل عابر — مشکل را حل کردهاند، و نظریهپردازان «جمعیت فناپذیری» (Doom Crowd) که معتقدند این نقص یک خطای وجودی و غیرقابل حل در معماری LLM است.
واقعیت اما در یک نقطه میانی خطرناک است؛ جایی که مدل اعتماد برای عاملهایی که در محیطهای نامعتبر کار میکنند، بهطور بنیادی شکسته شده است. اکثر تیمهای توسعه هنوز با این سطح از حمله (Attack Surface) دست و پنجه نرم نمیکنند و از ابعاد آن بیخبرند.
این تغییر، نقش برنامهنویس را از یک کاربر ساده به یک دروازبان امنیتی (Security Gatekeeper) تبدیل میکند. اگر یک عامل اجازه تغییر کد عملیاتی را دارد، هر ورودی خارجی که میخواند، یک بردار حمله بالقوه است. برنامههای امنیت اپلیکیشن (Appsec) هنوز چارچوبی برای ارزیابی این استقرارها توسعه ندادهاند و این شکاف احتمالاً در ۱۲ تا ۱۸ ماه آینده باعث حوادث بزرگی خواهد شد.
شما باید با ورودیهای عامل با همان تردیدی برخورد کنید که با ورودی کاربر در یک وباپلیکیشن برخورد میکنید. پیادهسازی اصل «حداقل دسترسی» (Principle of Minimal Privilege) دیگر یک انتخاب نیست، بلکه تنها راه برای محدود کردن شعاع تخریب یک تزریق موفق است.
اکنون صنعت با یک پرسش حقوقی و اخلاقی روبروست: وقتی یک عامل ربوده میشود، مسئولیت با کیست؟ متهمان احتمالی شامل برنامهنویسی است که عامل را مستقر کرده، ارائهدهنده پلتفرم یا سازنده مدل؛ هرچند امروز هیچ پاسخ روشنی برای این موضوع وجود ندارد.
گام بعدی شما
- فراخوانیهای ابزاری (Tool Calls) عامل خود را بهصورت لحظهای پایش کنید.
- پیش از اعطای مجوز نوشتن، منابع دادهای که عامل مصرف میکند را ممیزی کنید.
- دسترسیهای عامل را به محیطهای ایزوله (Sandbox) محدود کنید.
اما داستان سختافزاریِ کنترل این دسترسیها حتی پیچیدهتر است؛ به تحلیل ما درباره لایههای امنیتی در تراشههای جدید مراجعه کنید.
گفتگو