شهریور
آموزش هوش مصنوعی
جداسازی ابزارها و کمترین دسترسی برای ایجنت
وقتی به یک ایجنت هوش مصنوعی ابزاری میدهید — دسترسی به دیتابیس، ارسال ایمیل، اجرای کد، تماس با یک API پرداخت — در واقع دارید به یک سیستمی که تصمیماتش کاملاً قطعی و قابلپیشبینی نیست، اختیار عمل روی دنیای واقعی میدهید. اصل کمترین دسترسی (principle of least privilege) که سالها در امنیت سیستمعامل و شبکه شناختهشده بوده، برای ایجنتها حتی مهمتر است، چون تصمیمگیرندهٔ نهایی یک مدل زبانی است، نه یک قطعه کد قطعی. این مقاله بهصورت عملی توضیح میدهد چطور دسترسی ابزارها را طراحی و محدود کنید.
لیست مطالب
چرا «یک کلید API با همهکارهبودن» ریسک بزرگی است
الگوی رایج و ناامن این است: یک کلید API واحد با دسترسی کامل (خواندن، نوشتن، حذف) ساخته میشود و در اختیار ایجنت قرار میگیرد، چون «راحتتر است». مشکل اینجاست که اگر ایجنت به هر دلیلی — تفسیر نادرست یک دستور، یا رفتار غیرمنتظره در یک سناریوی لبهای — تصمیم اشتباهی بگیرد، دامنهٔ آسیب برابر با کل دسترسی آن کلید است، نه فقط کاری که ایجنت واقعاً باید انجام دهد. کمترین دسترسی یعنی دامنهٔ آسیب هر تصمیم اشتباه را از قبل محدود کردن.
جداسازی ابزارها بر اساس نوع عملیات
اولین گام، تفکیک ابزارها بر اساس اینکه «خواندن» هستند یا «نوشتن»، و «قابلبرگشت» هستند یا «برگشتناپذیر». یک ایجنت گزارشگیری فقط باید به ابزارهای خواندن دسترسی داشته باشد؛ یک ایجنت که وظیفهاش پاسخ به تیکت پشتیبانی است، شاید نیاز به نوشتن در یک جدول محدود (پاسخ تیکت) داشته باشد، اما نه دسترسی حذف کاربر یا تغییر قیمت محصول.
| نوع عملیات | مثال | سطح ریسک | راهکار |
|---|---|---|---|
| خواندن محدود | SELECT روی جدول گزارش | پایین | دسترسی پیشفرض برای اکثر ایجنتها |
| نوشتن قابلبرگشت | ثبت یادداشت، تغییر وضعیت تیکت | متوسط | لاگ کامل تغییرات + امکان rollback |
| نوشتن برگشتناپذیر | ارسال ایمیل، پرداخت، حذف رکورد | بالا | تأیید انسانی پیش از اجرا (human-in-the-loop) |
| عملیات سیستمی | اجرای کد دلخواه، دسترسی فایلسیستم | بسیار بالا | sandbox ایزوله؛ بدون دسترسی مستقیم به سیستم اصلی |
محدود کردن دامنهٔ هر ابزار، نه فقط تعدادشان
کمترین دسترسی فقط بهمعنای «تعداد کمتر ابزار» نیست؛ دامنهٔ هر ابزار هم باید محدود باشد. برای مثال، اگر ایجنت نیاز به خواندن اطلاعات مشتری دارد، بهتر است ابزار مربوطه فقط فیلدهای لازم (نام، وضعیت سفارش) را برگرداند، نه کل رکورد شامل اطلاعات پرداخت یا رمز عبور هششده. این کار را میتوان در لایهٔ API یا view دیتابیس پیاده کرد، نه با اتکا به اینکه «ایجنت خودش فیلدهای اضافه را نادیده میگیرد».
همین اصل دربارهٔ کلید API هم صادق است: برای هر نقش ایجنت، یک کلید جداگانه با scope مشخص بسازید، نه یک کلید مشترک برای همهٔ کارها. این کار همچنین به شما اجازه میدهد در صورت بروز رفتار غیرمنتظره، فقط دسترسی همان کلید خاص را غیرفعال کنید، بدون توقف کل سیستم.
تفکیک شبکه و محیط اجرا
اگر ایجنت قابلیت اجرای کد یا واکشی محتوای بیرونی دارد، این عملیات باید در یک محیط ایزوله (sandbox) با دسترسی شبکهٔ محدود اجرا شود — نه در همان محیطی که به دیتابیس اصلی یا سرویسهای داخلی دسترسی دارد. کنترل egress شبکه (اینکه sandbox فقط به دامنههای مشخصی اجازهٔ خروج داشته باشد) یک لایهٔ دفاعی مهم است که مستقل از رفتار خودِ مدل عمل میکند.
تأیید انسانی برای اقدامات برگشتناپذیر
برای هر عملیاتی که اثر آن قابل بازگشت نیست — ارسال پیام به مشتری، پرداخت، حذف داده — یک گام تأیید انسانی (human-in-the-loop) پیش از اجرای نهایی قرار دهید. این تأیید لازم نیست برای هر عملیات کوچک باشد؛ میتوان آستانه تعریف کرد (مثلاً پرداختهای زیر مبلغ مشخص خودکار، بالاتر از آن نیازمند تأیید) اما اصل کلی این است: هرچه پیامد یک اقدام غیرقابلبرگشتتر باشد، فاصلهٔ بین تصمیم مدل و اجرای واقعی باید بیشتر باشد.
لاگگیری کامل، پیشنیاز هر بررسی بعدی
بدون لاگ کامل از اینکه کدام ابزار، با کدام پارامتر، توسط کدام اجرای ایجنت فراخوانی شده، هیچ بررسی پس از حادثه ممکن نیست. حداقل باید ثبت شود: زمان، ابزار فراخوانیشده، پارامترهای ورودی، و نتیجهٔ خروجی. این لاگها باید جدا از دادهٔ عملیاتی نگه داشته شوند تا حتی در صورت خرابی سیستم اصلی، قابل بازیابی باشند.
برای تکمیل این موضوع با اصول مدلسازی تهدید، به مقالهٔ «مدل تهدید برای یک ایجنت» و نقشهٔ راه امنیت هوش مصنوعی مراجعه کنید؛ راهنمای ایجنتهای هوش مصنوعی هم دید کلیتری از معماری ایجنت ارائه میدهد.
مدیریت و چرخش اعتبارنامهها
کمترین دسترسی بهتنهایی کافی نیست اگر خودِ اعتبارنامهها (کلید API، توکن دسترسی) بهدرستی مدیریت نشوند. کلیدهایی که ایجنت با آنها به ابزارها متصل میشود، باید در یک مخزن راز (secrets manager) نگهداری شوند، نه در کد یا فایل پیکربندی ساده. چرخش دورهای این کلیدها — حتی وقتی نشانهای از افشا وجود ندارد — دامنهٔ زمانی هر کلید احتمالاً درزکرده را محدود میکند. هر کلید باید بهوضوح به یک نقش یا ایجنت مشخص متصل باشد تا در صورت نیاز به لغو، فقط همان مسیر خاص قطع شود، نه کل سیستم.
تست دسترسی بهعنوان بخشی از استقرار
پیش از اینکه یک ایجنت با ابزارهای جدید به تولید برود، باید بهصورت عملی تأیید شود که scope واقعی هر کلید و هر نقش، دقیقاً همان چیزی است که در طراحی مشخص شده — نه بیشتر. یک تست ساده اما مؤثر، تلاش برای اجرای عملیاتی خارج از دامنهٔ مجاز (مثلاً تلاش برای خواندن جدولی که نباید در دسترس باشد) با همان اعتبارنامهٔ ایجنت است؛ اگر این تلاش موفق شود، یعنی scope بهدرستی محدود نشده و باید پیش از استقرار اصلاح شود.
جمعبندی
- هرگز یک کلید یا نقش با دسترسی کامل به همهٔ ایجنتها ندهید؛ برای هر نقش، scope جداگانه بسازید.
- ابزارها را بر اساس خواندن/نوشتن و قابلبرگشت/برگشتناپذیر دستهبندی و محدود کنید.
- دامنهٔ هر ابزار (نه فقط تعدادشان) را در لایهٔ API یا دیتابیس محدود کنید، نه با اتکا به رفتار مدل.
- اجرای کد یا واکشی محتوای بیرونی را در sandbox ایزوله با کنترل شبکه انجام دهید.
- برای اقدامات برگشتناپذیر، تأیید انسانی بگذارید و همیشه لاگ کامل از فراخوانی ابزارها نگه دارید.
