یک دستور تزریق پرامپت (Prompt Injection) می‌تواند کل وزن‌های مدل یا دستورالعمل‌های سیستمی یک شرکت را لو بدهد. اگر امروز عامل‌های هوش مصنوعی را در محیط عملیاتی خود مستقر کرده‌اید، باید بدانید که این ابزارها حفره‌های امنیتی منحصربه‌فردی ایجاد می‌کنند که در چت‌بات‌های سنتی وجود نداشت. این حفره‌ها به‌طور خاص در زمینه سرقت مصنوعات مدل (Model Artifacts) و اعتبارنامه‌های سرویس‌ها ظاهر می‌شوند.
به گزارش dev.to در ۲۳ اوت ۲۰۲۶، خطر اصلی در عامل‌ها به دلیل توانایی آن‌ها در فراخوانی پویا ابزارها، بازیابی داده‌های خصوصی، تغییر فایل‌ها و ارتباط با سرویس‌های خارجی است. همان‌طور که در تحلیل قبلی ما درباره‌ی اینکه چرا امنیت باید از تست پرامپت به مرزهای ابزاری تغییر کند اشاره کردیم، فیلتر کردن ورودی‌ها دیگر دفاع کافی نیست. یک عامل (Agent) — شبیه به کارمندی دیجیتال که کلید دفتر را دارد — اگر بتواند بدون نظارت تمام کشوهای قفل‌شده را باز کند، داشتن کلید برای او خطرناک است.
ماهیت ریسک‌های عامل‌محور
استقرار سامانه‌های عامل‌محور (Agentic) با دو هدف اصلی برای مهاجمان روبروست: دارایی‌های مدل و اعتبارنامه‌های سرویس. استخراج مدل (Model Exfiltration) شامل بیرون کشیدن غیرمجاز وزن‌ها (Weights)، داده‌های آموزشی، بافت بازیابی (Retrieval Context) یا دانش رفتاری است. مهاجمان ممکن است از طریق پرس‌وجوهای مکرر، فراخوانی‌های مخرب ابزارها یا درخواست‌های خروجی کدگذاری‌شده، این دارایی‌ها را بدزدند.
نشت کلیدهای API نیز به همان اندازه خطرناک است. این اعتبارنامه‌ها اغلب از طریق ردپای خطاها (Error Traces)، لاگ‌ها، کدهای تولید شده توسط مدل یا آرگومان‌هایی که به ابزارهای غیرقابل اعتماد پاس داده می‌شوند، لو می‌روند. از آنجا که عامل‌ها تصمیمات را به‌صورت پویا می‌گیرند، کنترل‌های دسترسی سنتی پاسخگو نیستند. این چالش‌ها نشان می‌دهد که چرا لیست‌های ابزارهای تأییدشده به‌تنهایی در برابر نشت داده‌های سازمانی شکست می‌خورند و نیاز به لایه‌های نظارتی عمیق‌تر است. تیم‌های امنیتی اکنون باید بررسی کنند کدام عامل در حال اجراست، چه طبقه‌بندی داده‌ای اعمال می‌شود و آیا این اقدام با سیاست‌های تاییدشده مطابقت دارد یا خیر.
برای حل این مشکل، چارچوب امنیتی متن‌باز TrustGraph از شرکت HONEYPOTZ-AI زیربنایی برای ارزیابی اعتماد در میان هویت‌ها و جریان‌های کاری فراهم می‌کند. این چارچوب تأکید دارد که اجرا و نظارت باید در «نقطه اقدام» رخ دهد، نه فقط در «نقطه ورود».
خطوط قرمز دفاع در زمان اجرا
بر اساس مستندات dev.to، تیم‌های توسعه باید این کنترل‌های حداقلی را پیاده کنند:
- جداسازی دارایی‌ها: ذخیره وزن‌ها، آداپتورها (Adapters) و پرامپت‌های سیستمی خارج از فضای کاری قابل‌نوشتنِ عامل. فرآیند سرویس‌دهی باید فقط استنتاج (Inference) را ارائه دهد، نه دسترسی مستقیم به مصنوعات خام.
- لیست‌های مجاز خروجی: مسدود کردن تمام ترافیک خروجی به‌جز مقاصد و پروتکل‌های تاییدشده. دسترسی مستقیم شبکه از طریق ابزارهای اجرای کد باید مسدود شود، مگر اینکه صراحتاً مورد نیاز باشد.
- محدودیت قابلیت‌ها: تفکیک مجوزهای خواندن، نوشتن، اجرا و صادر کردن (Export)؛ برای مثال، یک عامل خلاصه‌ساز نباید به‌طور خودکار دسترسی به Shell یا آپلود فایل پیدا کند. این نوع ضعف در مدیریت دسترسی‌ها در پروتکل‌های ارتباطی رایج است، به‌طوری که بسیاری از استقرارهای پروتکل MCP با حفره‌های امنیتی شدید روبرو هستند.
- بازرسی خروجی‌ها: اسکن داده‌های خروجی برای شناسایی رمزها، نشانگرهای اختصاصی شرکت یا حجم‌های غیرعادی از داده‌های کدگذاری‌شده پیش از خروج از سیستم.
- حسابرسی ضد-دستکاری: ثبت هویت عامل، تصمیمات سیاستی، آرگومان‌های ابزار و هش‌های دارایی برای تمام اقدامات پرریسک.
علاوه بر این، توسعه‌دهندگان می‌توانند از «رشته‌های قناری» (Canary Strings) که در پرامپت‌های محافظت‌شده جاسازی شده‌اند استفاده کنند. تطابق یک رشته قناری باید منجر به قرنطینه فوری و چرخش اعتبارنامه‌ها شود، نه فقط یک هشدار ساده.
مدیریت رمزها و اسرار
برای برنامه‌های حساس به حریم خصوصی مانند DeepBody و برنامه‌های امنیتی توسعه‌یافته توسط HONEYPOTZ INC، استفاده از یک واسط رمز (Secret Broker) توصیه می‌شود. عامل‌ها هرگز نباید کلیدهای خام API را ببینند؛ در عوض، توکن‌های کوتاه‌مدت و محدود (Scoped Tokens) باید پس از تایید سیاست‌ها، درون یک درگاه ابزار مورد اعتماد تزریق شوند.
این توکن‌ها باید به یک هویت خاص عامل، یک عملیات مجاز، یک حداکثر زمان اجرا و یک نشست (Session) قابل ردیابی گره بخورند. چرخش خودکار و قطع فوری نشست‌ها در صورت ابطال، برای کاهش اثر تخریبی (Blast Radius) یک عاملِ هک‌شده ضروری است. این راهنما اشاره می‌کند که رمزهای خام باید از لاگ‌ها، هدرهای احراز هویت و آرگومان‌های ابزار حذف (Redact) شوند تا نشت تصادفی رخ ندهد.
این رویکرد، فرض بنیادی امنیت AI را از «آیا می‌توانیم جلوی پرامپت بد را بگیریم؟» به «آیا می‌توانیم جلوی اقدام بد را بگیریم؟» تغییر می‌دهد. با تمرکز بر مقصد داده‌ها به‌جای نیت پرامپت، توسعه‌دهندگان می‌توانند عامل‌های قدرتمندتری را بدون ریسک از دست دادن مالکیت معنوی مستقر کنند.
برای متخصصان، این یعنی اولویت از اصلاح پرامپت سیستمی به سمت زیرساخت — به‌ویژه مدیریت خروجی شبکه و مدیریت هویت — تغییر می‌کند. هدف، ساخت یک گراف اعتماد قابل‌تأیید است که در آن هر اقدام توسط سیاست‌ها محدود و حسابرسی شود.
توسعه‌دهندگان اکنون می‌توانند پروژه TrustGraph را بررسی کرده و در آن مشارکت کنند تا این دفاع‌های ضد-استخراج را پیش از انتقال عامل‌ها به محیط‌های عملیاتی پیاده‌سازی نمایند.
گام بعدی شما
- بررسی مخزن TrustGraph برای پیاده‌سازی لایه‌های کنترل خروجی در محیط‌های تست.
- جایگزینی کلیدهای API ثابت با توکن‌های موقت و محدود (Scoped Tokens) در ابزارهای عامل.
- تعریف لیست‌های سفید (Allowlists) برای تمام درخواست‌های شبکه که توسط عامل‌ها ارسال می‌شود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو