مدیریت دسترسی در برابر تزریق پرامپت در امنیت عامل‌های هوش مصنوعی

یک کلید دسترسی مدیریتی که به یک عامل هوش مصنوعی داده شود، می‌تواند کوچک‌ترین خطای منطقی را به یک فاجعهٔ نشت داده تبدیل کند. ساگار جین (Sagar Jain)، هم‌بنیان‌گذار فنی Shanti Infosoft، هشدار می‌دهد که در حالی که «تزریق پرامپت» (Prompt Injection) تیتر خبرها را می‌گیرد، خطر واقعی در دسترسی‌های «حالت خدا» (God-mode) است که توسعه‌دهندگان برای راحتی در دموها استفاده می‌کنند.

این شکاف امنیتی اغلب از کدنویسی حسی (Vibe Coding) — شبیه به ساختن خانه‌ای بدون نقشه که در آن هر جا لازم بود یک دیوار اضافه می‌شود — ریشه می‌گیرد. در این رویکرد، سرعت توسعه با استقراض از «بدهی فنی» (Technical Debt) به دست می‌آید، اما هرگز برنامه‌ای برای بازپرداخت این بدهی‌ها پیش‌بینی نمی‌شود. طبق گزارش‌های فنی، توسعه‌دهندگان برای اینکه دموی روز جمعه به‌درستی کار کند، از توکن‌های سطح بالای خود یا حساب‌های خدماتی موجود استفاده می‌کنند. این دسترسی‌ها به‌دلیل اولویت یافتن ویژگی‌های جدید بر اصلاحات امنیتی در هر اسپرینت، به‌طور تصادفی به محیط عملیاتی منتقل می‌شوند؛ زیرا عبارت «بعداً دسترسی‌ها را محدود می‌کنیم» به تیکتی تبدیل می‌شود که در هر چرخه توسعه، بازندهٔ ویژگی‌های جدید است.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد به رفتار مدل بدون داشتن حفاظ‌های سخت‌افزاری یک ریسک است. به همین دلیل Shanti Infosoft چارچوب سخت‌گیرانه‌ی «حداقل امتیاز» (Least Privilege) را اجرا می‌کند. در این شرکت، امنیت عامل‌ها یک دروازهٔ سخت است و پیش از دریافت هویت عملیاتی، باید توسط شخصی خارج از تیم تایید شود. این فرآیند بررسی و تایید، در همان استانداردهای CMMI Level 5 ادغام شده است که برای تمامی تحویل‌های دیگر تیم استفاده می‌شود. این رویکرد در راستای ۱۵ قانون مهندسی برای تبدیل عامل‌های هوش مصنوعی به ابزارهای قابل‌اعتماد است که بر ساختاریافته بودن توسعه تأکید دارد.

ابزارهای محدودسازی و توکن‌ها

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

• تفکیک خواندن/نوشتن: ابزارهای مجزا برای خواندن و نوشتن تا یک عاملِ «فقط-خواندنی» به‌طور فیزیکی نتواند داده‌ای را تغییر دهد.
• اعتبارسنجی پارامترها: بررسی کدهای ورودی در سطح کد پیش از اجرا، مانند اجبار به فرمت‌های سخت‌گیرانه برای IDها و تعریف لیست سفید (Allow-listing) برای جداول و میزبان‌ها.
• نقاط انتهایی محدود: استفاده از توابعی مثل get_order(order_id) و list_orders(customer_id, limit) به‌جای نقاط انتهایی باز برای پرس‌وجو.
• بازگشت داده‌های حداقلی: اگر عامل فقط وضعیت سفارش را می‌خواهد، سیستم تنها همان را فراهم می‌کند، نه کل رکورد مشتری را.
• حالت اجرای آزمایشی (Dry-Run): ابزارهای نوشتاری دارای حالتی هستند که به‌طور خاص در مراحل ارزیابی و فازهای سایه (Shadow Phases)، بدون تغییر واقعی در داده، خروجی را شبیه‌سازی می‌کنند.

مدیریت توکن (Token) — تکه‌های کوچکی از متن یا کلیدهای دسترسی، شبیه به بلیط‌های تک‌سفره که فقط برای یک مسیر خاص معتبرند — از منطق محدودیت شدید پیروی می‌کند. به‌جای حساب‌های خدماتی مشترک — که تا زمانی که کسی به یاد آورد آن‌ها را تغییر دهد (Rotate) عمر می‌کنند و شعاع تخریب آن‌ها تمام مستاجران (Tenants) را در بر می‌گیرد — هر وظیفه یک توکن اختصاصی دریافت می‌کند که به یک مشتری و یک اقدام خاص (مثلاً orders:read) متصل است و عمر آن تنها ۱۰ دقیقه است.

این ساختار تضمین می‌کند که اگر عاملی فریب بخورد، شعاع تخریب (Blast Radius) به تاریخچه سفارشات فقط-خواندنی یک مشتری برای ۱۰ دقیقه محدود شود. این مکانیسم برای جلوگیری از خروج غیرمجاز داده‌ها حیاتی است، مشابه آنچه در سازوکار TrustGraph برای مقابله با Exfiltration بررسی کردیم. علاوه بر این، اسرار امنیتی هرگز در پرامپت یا پنجرهٔ زمینه (Context Window) — میزان متنی که مدل هم‌زمان در ذهن نگه می‌دارد، شبیه به میز کاری که جا برای چند ورق دارد — قرار نمی‌گیرند تا مدل نتواند با متقاعد شدن، یک کلید را تکرار یا افشا کند. هر فراخوانی ابزار با یک شناسه عامل نام‌گذاری شده (Named Agent ID) ثبت می‌شود تا ردپایی دقیق از اقدامات عامل باقی بماند که مانند گزارش اقدامات یک انسان قابل خواندن است.

ایمن‌سازی لایه داده

تولید بازیابی‌افزا (RAG) — مثل دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — ریسک خاصی ایجاد می‌کند: عامل ممکن است اسنادی را نمایش دهد که کاربر انسانی اجازه دسترسی به آن‌ها را ندارد. اگر ایندکس RAG توسط یک خزنده (Crawler) که با دسترسی ادمین اجرا می‌شود ساخته شده باشد، عامل اسنادی را می‌یابد که کاربر هرگز نمی‌توانست باز کند؛ و اغلب این نشت داده با یک ارجاع (Citation) همراه است که باعث می‌شود نشت اطلاعات، معتبر و رسمی به نظر برسد. این چالش‌ها به‌ویژه زمانی تشدید می‌شوند که پروتکل‌های جدیدی مانند MCP دسترسی عامل‌ها به داده‌های حساس را تسهیل کنند اما لایه‌های کنترلی را نادیده بگیرند.

جین از یک اجرای آزمایشی داخلی می‌گوید که در آن یک ربات پایگاه دانش، درایوهای مشترک را با استفاده از یک حساب خدماتی با دسترسی خواندن گسترده ایندکس کرده بود که پوشه‌های منابع انسانی (HR) را هم شامل می‌شد. در طول تست، وقتی همکاری درباره حقوق یک نقش خاص پرسید، ربات با ذکر رقم دقیق و نام فایل پاسخ داد.

برای رفع این مشکل، Shanti Infosoft اکنون امنیت در سطح ردیف (Row-level security) را در ذخیره‌سازهای برداری اجباری کرده است. لیست‌های کنترل دسترسی (ACL) در سطح سند، در کنار بردار معنایی (Embedding) — کارت معرفی عددی برای هر واژه که همسایگی معنایی آن را مشخص می‌کند — ذخیره شده و در زمان پرس‌وجو بر اساس هویت فراخوان فیلتر می‌شوند. همچنین هر زمان که مجوزهای منبع تغییر کند، همگام‌سازی مجدد (Re-sync) فعال می‌شود.

چک‌لیست عملیاتی

پیش از آنکه هر عاملی به محیط عملیاتی (Production) دسترسی پیدا کند، تیم یک بررسی یک‌ساعته انجام می‌دهد. این بررسی درباره امنیت پیچیده نیست، بلکه لیستی از سوالات با پاسخ‌های نام‌گذاری شده است که یک بازبین خارجی می‌تواند آن‌ها را تایید کند:

• برای هر ابزار: محدودترین دامنه دسترسی آن چیست، آیا می‌خواند یا می‌نویسد، چه چیزی آرگومان‌ها را اعتبارسنجی می‌کند و فرآیند Dry-run آن چگونه است.
• برای هر توکن: چه کسی آن را صادر (Mint) می‌کند، به چه چیزی متصل است، طول عمرش چقدر است و فراخوانی آن کجا ثبت می‌شود.
• برای داده‌ها: بازیابی اطلاعات از مجوزهای چه کسی ارث می‌برد و این مجوزها چگونه به‌روز نگه داشته می‌شوند.

این رویکرد، بار امنیتی را از «رفتار مدل LLM» به «محدودیت‌های زیرساختی» منتقل می‌کند. با برخورد سخت‌گیرانه با مجوزهای عامل‌ها (مشابه فرآیندهای CMMI Level 5)، سیستم تضمین می‌کند که تصمیم کد درباره پذیرفتنی بودن یک اقدام، همیشه بر انتخاب ابزار توسط مدل اولویت داشته باشد.

برای کسانی که در حال استقرار عامل‌ها هستند، تست حیاتی ساده است: اگر عامل شما فریب بخورد تا بدترین کاری را که مجوزهای فعلی‌اش اجازه می‌دهد انجام دهد، دقیقاً چه اتفاقی خواهد افتاد؟

گام بعدی شما

• دسترسی‌های عامل‌های خود را بازبینی کنید و هر کلید «مدیریتی» را با توکن‌های کوتاه‌مدت و محدود جایگزین کنید.
• برای هر ابزار (Tool) در سیستم خود، یک لایه اعتبارسنجی ورودی (Input Validation) سخت‌گیرانه تعریف کنید.
• در سیستم‌های RAG، فیلترهای دسترسی را در زمان کوئری (Query-time) اعمال کنید، نه فقط در زمان ایندکس‌گذاری.

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