اگر امروز یک عامل هوش مصنوعی را به پایگاه‌داده یا APIهای داخلی شرکتتان متصل کرده‌اید، احتمالاً حفره‌ای امنیتی ایجاد کرده‌اید که هیچ فیلتر متنی نمی‌تواند آن را ببندد. بحران فعلی دیگر در لایه‌ی وزن‌های مدل نیست، بلکه در لایه‌ی «دستورات مجاز» پس از استنتاج رخ می‌دهد. در واقع، خطرناک‌ترین شکست‌های امنیتی دیگر در داخل پارامترهای مدل اتفاق نمی‌افتند، بلکه در خط لوله‌ی پس از استنتاج (Post-inference pipeline) رخ می‌دهند؛ جایی که خروجی مدل به یک دستور مجاز تبدیل می‌شود.
این تغییر رویکرد در حالی اتفاق می‌افتد که صنعت از مرحله‌ی آزمایشگاهی (Sandbox) عبور کرده و با پیچیدگی‌های ادغام در دنیای واقعی دست و پنجه نرم می‌کند. برای سال‌ها، تمام تمرکز تیم‌های امنیتی روی تزریق پرامپت (Prompt Injection) و پاک‌سازی خروجی‌ها بود. اما اکنون که سازمان‌ها مدل‌های زبانی بزرگ (LLM) را به APIها و پایگاه‌داده‌های داخلی متصل می‌کنند، سطح حمله از تولید متن ساده به دستکاری فعال منابع تغییر یافته است. ریسک‌های مرتبط با «اقتدار» و «بهره‌برداری از منابع» به طور قابل توجهی دشوارتر از آن شده‌اند که بتوان آن‌ها را مهار کرد.
این تکامل دقیقاً مشابه تاریخچه امنیت نرم‌افزار است؛ جایی که با متصل‌تر شدن سیستم‌ها، تمرکز از اعتبارسنجی ورودی‌ها به مدیریت هویت و دسترسی (IAM) تغییر کرد. اکنون چالش اصلی این نیست که مدل چه می‌گوید یا چگونه ارزیابی شود، بلکه این است که مرزهای اتفاقاتی که پس از استنتاج رخ می‌دهد، چگونه تعریف شوند. معماری شما تعیین می‌کند که یک توهم (Hallucination) صرفاً یک اشتباه متنی باقی بماند یا به یک تغییر غیرمجاز در دیتابیس تبدیل شود. برای درک عمیق‌تر این فرآیند، می‌توان به مدل‌سازی تهدیدات AI اشاره کرد که نشان می‌دهد چگونه می‌توان ریسک‌های انتزاعی را به مسیرهای حمله قابل‌آزمون تبدیل کرد.
تغییر در رتبه‌بندی ریسک‌ها
به نقل از گزارش OWASP که بر اساس بررسی ۷۷۱۴ مورد حادثه و اجماع جامعه تخصصی تهیه شده، رتبه‌بندی آسیب‌پذیری‌ها به‌طور بنیادین تغییر کرده است. این پایگاه شواهد بر اساس ۷۵٪ اجماع جامعه و ۲۵٪ داده‌های تجربی حوادث شکل گرفته است:
- قدرت بیش از حد (Excessive Agency): از رتبه ششم به سوم صعود کرده است. این ریسک زمانی رخ می‌دهد که به یک عامل (Agent) دسترسی‌های بیشتری نسبت به نیاز واقعی‌اش داده شود و به او اجازه داده شود اقداماتی غیرمجاز انجام دهد. این صعود به این دلیل رخ داد که واقعیت‌های محیط‌های عملیاتی (Production) با تئوری‌های اولیه هم‌راستا شدند.
- مصرف نامحدود (Unbounded Consumption): به رتبه ششم رسیده است. این مورد به ریسک فراخوانی‌های بازگشتی ابزارها اشاره دارد که می‌تواند بودجه محاسباتی را به سرعت تخلیه کرده، هزینه‌ها را به شدت افزایش دهد یا کل سیستم را متوقف (Crash) کند.
- مدیریت نادرست خروجی: به رتبه دهم سقوط کرده است. اگرچه این مورد هنوز خطرناک است، اما تیم‌های DevOps در استفاده از اعتبارسنجی طرح‌ها (Schema Validation) و پرس‌وجوهای پارامتری (Parameterized Queries) برای ایمن‌سازی مقصدهای پایین‌دست خبره شده‌اند. این‌ها در واقع همان شیوه‌های تثبیت‌شده‌ی امنیت اپلیکیشن هستند.
خطر اقتدار عامل‌محور
در یک سیستم عامل‌محور (Agentic)، پاسخ مدل مقصد نهایی نیست، بلکه ورودی‌ای است که «اقتدار» به همراه دارد. اگر مدل دارای اعتبارنامه‌ی یک API باشد یا با یک سیستم تعامل کند، خروجی آن به برداری تبدیل می‌شود که می‌تواند عملیاتی را در سیستم‌های مختلف و مجزا فعال کند. اگر پاسخ LLM بدون اعتبارسنجی سخت‌گیرانه به یک Shell یا دیتابیس برسد، نقص‌های تزریق سنتی همچنان پابرجا هستند، اما پارادایم تغییر کرده است.
پاک‌سازی استاتیک (Static Sanitization) نمی‌تواند «قصد» یا نیت مدل را تشخیص دهد. یک فراخوانی ابزار ممکن است از نظر ساختاری کاملاً درست باشد، اما از نظر زمینه‌ای غیرقانونی باشد. برای مثال، یک عامل ممکن است یک تابع تایید شده را برای یک وظیفه نامناسب فراخوانی کند یا منبع اشتباهی را هدف قرار دهد. این وضعیت نیازمند مجوزدهی پیچیده و آگاه به زمینه (Context-aware) است که مدل هرگز نباید به تنهایی و در انزوا انجام دهد.
پیاده‌سازی اصل «حداقل دسترسی»
بسیاری از تیم‌ها به اشتباه تعریف ابزارها را صرفاً یک لوله‌کشی فنی یا ادغام ساده می‌بینند. این یک خطای استراتژیک و بنیادین است. هر ابزار، کانکتور یا نقطه انتهایی API، دایره نفوذ اپلیکیشن AI را گسترش می‌دهد. تصور کنید عاملی طراحی شده تا یک صندوق ورودی ایمیل را خلاصه‌سازی کند؛ اگر پیاده‌سازی از یک کانکتور گسترده استفاده کند که شامل قابلیت‌های نوشتن یا حذف باشد، شما پیش از آنکه اولین پرامپت پردازش شود، قابلیت‌های بیش از حد و خطرناکی را وارد سیستم کرده‌اید.
طبق اعلام OWASP و متخصصان امنیتی، برای کاهش این ریسک باید کنترل‌های سخت‌گیرانه‌ای اعمال شود:
- رابط‌های محدود: ارائه ابزارهای «فقط خواندنی» به جای کانکتورهای همه‌منظوره و کلی.
- زمینه محدود شده: اجرای درخواست‌ها در قالب هویت OAuth کاربر مربوطه، نه با استفاده از یک کلید ادمین سیستم (Global System Admin Key).
- نقاط اجرای سیاست (PEP): پیاده‌سازی منطق مجوزدهی به عنوان یک میان‌افزار (Middleware) اجباری بین مدل و سیستم‌های پایین‌دست. هر اقدام باید پیش از اجرا، در برابر سیاست‌های امنیتی اعتبارسنجی شود.
- حضور انسان در چرخه (HITL): الزام به تایید صریح انسانی برای عملیاتی که بازگشت‌ناپذیر هستند یا تاثیرات مادی و عملیاتی بالایی دارند.
این رویکرد مستلزم تغییر در خط لوله‌ی تحویل (Delivery Pipeline) است. فرآیندهای بازبینی باید فراتر از خود مدل گسترش یابند تا تغییرات در طرح‌های ابزار (Tool Schemas)، هویت‌های سرویس و محدوده‌های دسترسی را نیز شامل شوند. یک به‌روزرسانی مدل ممکن است بی‌خطر به نظر برسد، اما تغییر در زمینه مجوزدهی یک کانکتور می‌تواند یک آسیب‌پذیری فاجعه‌بار ایجاد کند.
دیده‌پذیری و حسابرسی
در محیط‌های عملیاتی، دیده‌پذیری غیرقابل مذاکره است. سازمان‌ها باید یک زنجیره مالکیت (Chain of Custody) سخت‌گیرانه برای هر اقدام انجام شده توسط یک عامل حفظ کنند. این امر مستلزم ثبت دقیق سه نقطه داده‌ای است:
- اجرای دقیق ابزار مورد استفاده.
- هویت تاییدکننده (Authorizing Identity).
- تغییر حاصل شده در سیستم هدف.
این سطح از جزئیات برای پاسخ به حوادث (Incident Response) ضروری است و به تیم‌های امنیتی اجازه می‌دهد تا یک فرآیند فعال را متوقف کرده و ردپای حسابرسی را پس از حادثه بازسازی کنند.
حل مسئله مصرف نامحدود
حجم درخواست‌ها معیار مناسبی برای سنجش ریسک منابع نیست. یک پرامپت کوتاه و موجز می‌تواند زنجیره‌ای بازگشتی و سنگین از فراخوانی ابزارها را فعال کند. شمارنده مصرف تا زمانی که عامل کارش را تمام نکند متوقف نمی‌شود و هشدار‌های ساده زمانی که سرعت اجرا از سرعت پاسخ انسانی بیشتر است، ناکافی هستند.
برای جلوگیری از این وضعیت، سیستم‌ها به «توقف‌های سخت» (Hard Stops) قطعی نیاز دارند که خارج از کنترل عامل باشد. این شامل سقف‌های سخت‌گیرانه برای موارد زیر است:
- میزان مصرف توکن (Token usage)
- زمان سپری شده (Elapsed time)
- عمق بازگشت (Recursion depth)
- هزینه عملیاتی تجمعی (Cumulative operational cost)
اگر یک اجرا از این پارامترها فراتر رفت، سیستم باید اجرای آن را متوقف یا محدود (Throttle) کند. محدوده عملیاتی نیز نیازمند همین دقت است. سازمان‌ها باید حداکثر تعداد رکوردهایی که یک عامل می‌تواند تغییر دهد را تعیین کرده و مرزهای انتشار وظایف را تعریف کنند. بدون یک مکانیسم «توقف» قطعی، شما در واقع اقتدار را بدون تعریف محیط و مرزهای آن واگذار کرده‌اید.
قانون تزریق پرامپت
مهندسی سیستم‌ها مدت‌هاست که برای ایمن‌سازی اجزای ذاتا غیرقابل اعتماد، به معماری‌های تاب‌آور تکیه کرده است. ما شکست اجزا و ناپایداری شبکه را پیش‌بینی می‌کنیم؛ امنیت از همین فرض حاصل می‌شود، نه از توهم کمال. مدل‌های زبانی نیز همین انضباط معماری را می‌طلبند.
استراتژی امنیتی خود را بر پایه فرض «همراستاسازی» (Alignment) کامل مدل نچینید. شکست را پیش‌بینی کنید، چه از طریق یک سوءتفاهم ساده و چه از طریق بهره‌برداری بدخواهانه. تحلیل OWASP پیشنهاد می‌کند تزریق پرامپت را نه به عنوان یک باگ که باید رفع شود، بلکه به عنوان یک «قانون فیزیک» ببینید که همیشه در کمین است.
در یک پروژه واقعی که در گزارش ذکر شده، از ۱۰۰ تست خودکار تیم قرمز (Red-team) برای اعتبارسنجی کنترل‌ها استفاده شد. نتایج یک شکاف بحرانی در قابلیت اطمینان مدل‌ها را نشان داد:
- قدیمی‌ترین و ضعیف‌ترین مدل تست شده در ۱۷٪ موارد شکست خورد.
- جدیدترین و بزرگ‌ترین مدل در ۲٪ موارد شکست خورد.
اگرچه دقت ۹۸٪ پیشرفت بزرگی به نظر می‌رسد، اما زمانی که هر شکست به معنای نشت داده‌های حساس باشد، کافی نیست. بنابراین، امنیت باید از تاب‌آوری معماری — یعنی ساخت کنترل‌های سخت در خارج از مدل — حاصل شود، نه از همراستاسازی مدل. عملیات‌های با تاثیر بالا باید قابل مشاهده، قابل حسابرسی و در حالت ایده‌آل، قابل بازگشت باشند.
سوءاستفاده از API و ریسک‌های زیرساختی
فراتر از مدل، لایه زیرساخت همچنان یک هدف اصلی است. داده‌های شرکت Stripe در سال ۲۰۲۵ نشان داد استارتاپ‌های AI که ثبت‌نام‌های خودکار و دسترسی مستقیم به API دارند، ۱۰ برابر بیشتر از راهکارهای سازمانی مورد تلاش برای سوءاستفاده قرار گرفته‌اند. این موضوع اغلب از «سوءاستفاده از API» ناشی می‌شود، جایی که بات‌ها حساب‌های دوره آزمایشی رایگان را برای تولید کلیدهای معتبر به کار می‌گیرند تا محدودیت‌های نرخ (Rate Limits) سنتی را دور بزنند.
سوءاستفاده خودکار از API با استفاده از هوش مصنوعی برای استخراج داده‌ها (Scraping)، تست اعتبارنامه‌های سرقتی و ایجاد حساب‌های جعلی، سریع‌تر و کارآمدتر شده است. این امر نشان می‌دهد که امنیت یک اپلیکیشن AI تنها به اندازه لایه هویتی که از نقاط انتهایی (Endpoints) آن محافظت می‌کند، قوی است.
در نهایت، رتبه‌بندی جدید OWASP ثابت می‌کند که مدل ممکن است اشتباه را آغاز کند، اما این معماری است که «شعاع انفجار» (Blast Radius) را تعیین می‌کند. برای هوش مصنوعی در محیط عملیاتی، حیاتی‌ترین کارهای امنیتی اکنون در خط لوله‌ی پس از استنتاج رخ می‌دهد.
گام بعدی شما
- بازبینی تمامی API Keyهای متصل به عامل‌های AI و تبدیل آن‌ها به دسترسی‌های محدود (Scoped).
- پیاده‌سازی یک لایه Middleware برای تایید نهایی دستورات حساس پیش از اجرا در دیتابیس.
- تعریف سقف توکن و زمان برای هر نشست (Session) جهت جلوگیری از حلقه‌های بازگشتی هزینه‌زا.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو