چرا IAM سنتی از پس ایجنتهای هوش مصنوعی برنمیاد
خلاصهٔ کاملتر
تو این مقاله از SC Media اومده که مدل قدیمی IAM (مدیریت هویت و دسترسی، یعنی اینکه کی به چی دسترسی داره) ساده بود: یه آدم مشخص لاگین میکنه، یه کاری انجام میده و یه لاگ ثبتش میکنه. ولی وقتی کارمند از یه ایجنت هوش مصنوعی کمک میگیره که از چند سیستم داده میکشه و API صدا میزنه، این زنجیره خیلی پیچیدهتر میشه. نویسنده تأکید میکنه که AI خودبهخود تخلف قانونی نمیسازه، ولی جواب دادن به سؤالهای حسابرسها رو سختتر میکنه.
مشکل اول ردیابی هویت هست. یه درخواست ممکنه از کارمند شروع بشه و از اپلیکیشن، ایجنت، مدل، یه پلاگین و یه API پاییندستی رد بشه تا به داده برسه. IAM فعلی شاید دو سر این زنجیره رو خوب کنترل کنه، ولی وسطش لابهلای service accountها و credentialهای مشترک گم میشه. یعنی سازمان میتونه بگه یه کاری انجام شده، ولی نمیتونه بگه کی شروعش کرده و تو هر مرحله چه مجوزی در کار بوده.
مشکل دوم اختیار واگذارشده هست. اینکه کاربر اجازهی استفاده از یه ایجنت رو داره، معنیش این نیست که ایجنت اجازه داره تو همهی سیستمهایی که بهشون دسترسی داره از طرف کاربر کار کنه. مثلاً ایجنتی که برای تنظیم جلسه به تقویم، ایمیل و فایلها دسترسی داره، ممکنه اسناد بیربط رو بخونه یا اطلاعات رو به بیرون بفرسته. نویسنده میگه ایجنتها باید مثل یه هویت مستقل با محدودهی مشخص دیده بشن، نه ابزاری که دسترسی حساب کاربر رو به ارث میبره.
مشکل سوم و چهارم به داده و گذر زمان مربوطه. ایجنت میتونه دادهی چند منبع جدا، مثل دیتابیس مشتری، ایمیل و سوابق مالی، رو با هم ترکیب کنه، در حالی که هر کدوم جدا کنترل میشن و هیچ کنترلی برای این ترکیب طراحی نشده. از طرف دیگه مدل آپدیت میشه، ابزار جدید بهش وصل میشه و system prompt عوض میشه، بدون اینکه کسی دوباره مجوزها رو بررسی کنه. یعنی ایجنتی که شش ماه پیش تأیید شده، شاید الان کار دیگهای بکنه.
مشکل پنجم شواهد هست. لاگ API فقط میگه کلید 7F3C ساعت 14:15:32 مدل رو صدا زد و 847 توکن پردازش شد. ولی حسابرس لازم داره بدونه کدوم کارمند prompt داده، مدل کدوم سوابق مشتری رو خونده، چه پیشنهادی داده، کی تأییدش کرده و نتیجه وارد کدوم سیستم شده. به گفتهی نویسنده این اتصال رو نمیشه بعداً از لاگهایی که براش طراحی نشدن بازسازی کرد.
جمعبندی مقاله اینه که لازم نیست IAM رو کنار بذاریم؛ باید همون قواعد رو به AI هم گسترش بدیم. credentialهای ایجنت باید مثل یه هویت قابل بازبینی و لغو باشن، محدودهی مجوزشون صریح تعریف بشه، سیاست داده ترکیب منابع رو هم پوشش بده و لاگگیری کل زنجیرهی تصمیم رو ثبت کنه. نویسنده میگه سازمانهایی که این کارو نکنن، این خلأها رو وقتی میبینن که یه بازرس ازشون توضیح بخواد.
نکات کلیدی:
- یه درخواست AI ممکنه از کارمند، اپ، ایجنت، مدل، پلاگین و API پاییندستی رد بشه.
- مجوز استفاده از ایجنت با مجوز ایجنت برای کار کردن از طرف کاربر فرق داره.
- ترکیب داده از چند منبع جدا خلأییه که کنترلهای جداگانه نمیبیننش.
- آپدیت مدل، اضافه شدن ابزار یا تغییر system prompt میتونه محدودهی ایجنت رو بدون بازبینی عوض کنه.
- لاگ API بهتنهایی کارمند، داده و تصمیم تجاری رو به هم وصل نمیکنه.




