اگر اکنون در حال استقرار عامل‌های هوش مصنوعی در محیط تولید هستید، احتمالاً یک بمب ساعتی امنیتی در کد خود دارید. استفاده از کلیدهای API سخت‌افزاری (Hardcoded) و حساب‌های سرویس مشترک، ریسک فاجعه‌باری را برای زیرساخت‌های شما ایجاد می‌کند. این نگرانیات به ویژه در محیط‌های حساس مالی شدت می‌یابد؛ چنان‌که پیش‌تر بررسی کردیم که چگونه دسترسی مستقیم عامل‌ها به APIهای مالی می‌تواند منجر به نشت کلیدهای امنیتی شود.
به نقل از یک راهنمای فنی در dev.to که در ۲ آگوست ۲۰۲۶ منتشر شد، بسیاری از تیم‌ها احراز هویت را به‌عنوان یک اولویت ثانویه می‌بینند و چارچوب‌های امنیتی را که IT سازمانی ۱۵ سال پیش به کمال رساند، نادیده می‌گیرند. در واقع، جریان‌های کاری عامل‌محور (Agentic) — شبیه به کارمندی که بدون نظارت، به جای شما نامه‌های رسمی می‌نویسد و ایمیل‌ها را پاسخ می‌دهد — اغلب فاقد ردپای حسابرسی (Audit Trail) هستند؛ زیرا چندین عامل از یک هویت واحد استفاده می‌کنند.
این وضعیت یادآور دوران ابتدایی شبکه‌های شرکتی است، پیش از آنکه مدیریت هویت و دسترسی (IAM) — که مثل یک نگهبان سخت‌گیر در ورودی ساختمان است و فقط اجازه ورود به اتاق‌های مجاز را می‌دهد — به استاندارد طلایی تبدیل شود. تصور کنید ۱۰ کارمند مختلف از یک رمز عبور مشترک استفاده کنند؛ در این صورت هرگز نخواهید دانست چه کسی یک پایگاه داده حیاتی را پاک کرده است. همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، مدیریت دسترسی در مقیاس بزرگ، پیچیدگی‌های پیش‌بینی‌نشده‌ای ایجاد می‌کند. برای مدیریت این پیچیدگی‌ها، برخی رویکردها بر استفاده از امتیازدهی در سطح عامل برای تقویت حاکمیت سازمانی در AI تأکید دارند.
برای رفع این مشکل، طبق گزارش‌های تخصصی، توسعه‌دهندگان باید ۵ تغییر معماری زیر را پیاده کنند:
- هویت‌های ماشینی منحصربه‌فرد: هر عامل باید اعتبارنامه (Credential) مجزای خود را داشته باشد تا مسئولیت‌پذیری و ردیابی تضمین شود.
- توکن‌های کوتاه‌مدت: کلیدهای ایستا در فایل‌های محیطی خطرناک هستند. عامل‌ها باید توکن‌های موقتی درخواست کنند که بلافاصله پس از اتمام کار منقضی شوند؛ شبیه به جریان‌های کاری OAuth2 یا SAML.
- حداقل دسترسی (Least Privilege): اجرای کنترل دسترسی مبتنی بر نقش (RBAC) ضروری است. عاملی که فقط تقویم را می‌خواند، نباید اجازه تغییر در کل حساب ایمیل را داشته باشد.
- تفویض صریح: استفاده از مدل تفویض OAuth؛ عامل باید مدرکی ارائه دهد که برای چه کسی عمل می‌کند تا رفتار «عامل سرکش» از اقدامات مجاز کاربر تشخیص داده شود.
- تأیید مستمر: عبور از ورود یک‌باره به مدل اعتماد صفر (Zero Trust). چون عامل‌ها غیرقابل‌پیش‌بینی‌تر از انسان‌ها هستند، هر درخواست باید بر اساس زمینه (Context) تأیید شود.
پذیرش این الگوها مانع از آن می‌شود که تیم‌ها چرخ احراز هویت را از ابتدا اختراع کنند. اگرچه عامل‌ها سریع‌تر از انسان عمل می‌کنند، اما خطرات امنیتی — یعنی سرقت اعتبارنامه و افزایش غیرمجاز دسترسی — دقیقاً مشابه هستند.
برای کسانی که زیرساخت‌های تولیدی می‌سازند، هزینه نادیده گرفتن این استانداردها، یک نشت اعتبارنامه در سطح جهانی است. ادغام ابزارهایی مانند Okta یا منطق Azure AD در ارکستراسیون عامل‌ها، شکاف بین نمونه‌های اولیه آزمایشی و نرم‌افزارهای امن سازمانی را پر می‌کند.
گام بعدی شما
- مدیریت نشست‌های (Session) فعلی عامل‌های خود را ممیزی کنید.
- تمام کلیدهای ایستای طولانی‌مدت را با سیستم‌های بازخوانی پویا (Dynamic Token Refresh) جایگزین کنید.
- نقش‌های دسترسی هر عامل را به کوچک‌ترین واحد ممکن محدود کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو