مدیران رمز عبور سازمانی به‌آرامی به واسط‌های هویتی برای عامل‌های هوش مصنوعی تبدیل می‌شوند
شرکت 1Password در تاریخ ۲۲ آوریل ۲۰۲۵ قابلیت Agentic AI Security را در پلتفرم Extended Access Management خود عرضه کرد؛ قابلیتی که به‌طور خاص برای مدیریت هویت، اعتبارنامه و دسترسی عامل‌های هوش مصنوعی خودکار طراحی شده است، نه برای کارکنان انسانی. تنها سه هفته بعد، مایکروسافت نیز با معرفی نسخه‌ی پیش‌نمایش عمومی Entra Agent ID برای عامل‌هایی که در Azure AI Foundry و Copilot Studio ساخته می‌شوند، هوش مصنوعی را به زیرساخت هویتی خود وارد کرد و به هر عامل یک شناسه‌ی یکتا در Tenant اختصاص داد. هیچ‌کدام از این دو شرکت در واکنش به یک فرضیه عمل نکردند. گزارش Identity Security Landscape سال ۲۰۲۵ شرکت CyberArk که در همان ماه آوریل منتشر شد، نشان داد که به‌طور میانگین در هر سازمان، به ازای هر هویت انسانی، ۸۲ هویت ماشینی وجود دارد؛ و بخش بزرگی از جدیدترین این هویت‌ها، عامل‌های هوش مصنوعی با دسترسی دائمی به ابزارهای داخلی هستند.
این تحول اهمیت دارد زیرا ابزارهای هویت و مدیریت اعتبارنامه هرگز بر اساس نیازهای واقعی عامل‌های هوش مصنوعی طراحی نشده بودند. یک مدیر رمز عبور فرض می‌کند یک انسان، یک نشست ورود، احراز هویت مجدد گاه‌به‌گاه و تعداد مشخصی حساب کاربری برای هر فرد وجود دارد. اما یک عامل هوش مصنوعی می‌تواند هر چند ثانیه یک نشست جدید ایجاد کند، در یک وظیفه‌ی واحد با ده‌ها API تماس بگیرد و خودش را به چند نمونه‌ی موازی تبدیل کند که همگی به‌طور هم‌زمان به اعتبارنامه نیاز دارند. بازسازی زیرساخت هویت انسانی برای این الگو، اکنون یک دسته‌ی محصولی واقعی است، نه یک موضوع تحقیقاتی.
چه چیزی واقعاً در حال عرضه است
رویکرد 1Password بر این اصل تمرکز دارد که به عامل‌ها هویت جداگانه‌ای بدهد تا دیگر حساب‌های انسانی را به اشتراک نگذارند یا از آن‌ها تقلید نکنند؛ مسئله‌ای که رایج‌تر از آن چیزی است که به نظر می‌رسد: در بسیاری از استقرارهای اولیه‌ی عامل‌ها، به‌سادگی یک نسخه از اطلاعات ورود یک کارمند در اختیار عامل قرار داده می‌شد. به‌جای این روش، 1Password یک کیت توسعه نرم‌افزار (SDK) عرضه کرده که به تیم‌های مهندسی اجازه می‌دهد به‌صورت برنامه‌نویسی‌شده کلیدهای API محدود را به یک عامل اختصاص دهند؛ به این ترتیب عامل فقط همان رمز مشخصی را که برای یک وظیفه‌ی خاص نیاز دارد دریافت می‌کند، نه کل خزانه‌ی یک انسان. ویژگی دیگری با نام Secure Agentic Autofill که از ۸ اکتبر ۲۰۲۵ در دسترسی زودهنگام و از طریق یکپارچه‌سازی با Browserbase قرار گرفته، به یک عامل اجازه می‌دهد بدون آنکه اعتبارنامه هرگز در اختیار زمینه‌ی (context) خود عامل قرار گیرد، به یک سرویس وب وارد شود؛ این تکمیل خودکار در لایه‌ی مرورگر انجام می‌شود و برای مدل قابل‌مشاهده نیست.
رویکرد مایکروسافت در Entra Agent ID نقطه‌ی ورود متفاوتی داشت: به‌جای ساخت یک سیستم موازی، هویت عامل و هویت انسانی را در یک کنسول مدیریتی واحد یکپارچه کرد. از زمان عرضه‌ی پیش‌نمایش در ماه مه ۲۰۲۵، مایکروسافت لایه‌هایی از محافظت‌های خاص عامل را افزوده است که معادلی در هویت انسانی ندارند؛ از جمله دفاع در برابر تزریق دستور (prompt injection)، مسدودسازی دسترسی غیرمجاز به اتصالات Model Context Protocol (MCP) و شناسایی هوش مصنوعی پنهان (shadow AI) برای یافتن عامل‌هایی که خارج از دید تیم فناوری اطلاعات فعالیت می‌کنند. این پیش‌نمایش همچنین اکنون به Agent 365، داشبورد گسترده‌تر مدیریت عامل در مایکروسافت، متصل شده و هویت عامل را به‌جای یک ویژگی مستقل خزانه، به یک ورودی در یک صفحه‌ی کنترل عملیاتی بزرگ‌تر تبدیل می‌کند.
چرا این موضوع با امن‌سازی ورود انسانی تفاوت دارد
امنیت هویت انسانی بر اساس چرخه‌های بازخورد نسبتاً آرام اجرا می‌شود: فرآیند پذیرش، بازبینی دوره‌ای دسترسی، و خروج از سیستم هنگام ترک کار. اما هویت عامل باید در چرخه‌هایی در حد چند ثانیه اجرا شود. عاملی که باید در یک وظیفه یک رکورد CRM را بخواند، در یک سیستم تیکتینگ چیزی بنویسد و با یک API صورت‌حساب تماس بگیرد، به هر سه اعتبارنامه‌ی محدود نیاز دارد که باید تخصیص یابند، استفاده شوند و ترجیحاً قبل از شروع وظیفه‌ی بعدی منقضی شوند؛ نه آنکه مانند اطلاعات ورود ذخیره‌شده‌ی یک انسان، بی‌پایان در خزانه باقی بمانند. این یک چرخه‌ی عمر اساساً متفاوت است، و به همین دلیل سازندگان این ابزارها، مسیرهای جداگانه‌ای برای صدور و لغو اعتبارنامه‌ی عامل‌ها می‌سازند، نه آنکه صرفاً یک گزینه‌ی «عامل» به یک نوع حساب انسانی موجود اضافه کنند.
نیاز به حسابرسی نیز از نظر نوع، نه فقط حجم، متفاوت است. وقتی یک کارمند انسانی کار غیرعادی‌ای با یک اعتبارنامه انجام دهد، شخصی وجود دارد که می‌توان از او پرسید. اما وقتی یک عامل چنین کاری انجام دهد، پرسش این می‌شود که آیا تعریف وظیفه‌ی عامل، محدوده‌ی اعتبارنامه‌ی آن، یا یک دستور تزریق‌شده باعث این رفتار شده است؛ و همین موضوع دلیل آن است که مایکروسافت دفاع در برابر تزریق دستور را مستقیماً در محصول هویتی خود قرار داده، نه آنکه آن را به یک لایه‌ی امنیتی جدا بسپارد.
این موضوع اکنون برای تیم‌های امنیتی و فناوری اطلاعات چه معنایی دارد
- بررسی کنید چه چیزی واقعاً به‌صورت ثابت در کد نوشته شده است. پیش از ارزیابی هر پیشنهاد فروشنده برای هویت عامل، مشخص کنید چند مورد از استقرارهای فعلی عامل شما از رمزهای ثابت یا اعتبارنامه‌های قرض‌گرفته‌شده‌ی انسانی استفاده می‌کنند؛ بازاریابی خود 1Password دقیقاً همین رویه را هدف قرار داده، زیرا هنوز هم بسیار رایج است، و این ساده‌ترین مسئله‌ای است که می‌توانید بدون توجه به انتخاب فروشنده، برطرف کنید.
- صدور محدود را بخواهید، نه فقط یک داشبورد. نمایش یکپارچه‌ی هویت‌های عامل (که Entra Agent ID و ابزارهای مشابه در صدر آن قرار دارند) برای دید کلی مفید است، اما قابلیتی که به‌سختی به دست می‌آید این است که آیا پلتفرم می‌تواند یک اعتبارنامه‌ی محدود به یک وظیفه صادر کند و آن را به‌طور خودکار منقضی کند. از فروشندگان بخواهید دقیقاً همین روند را نمایش دهند، نه فقط کنسول مدیریتی.
- نسبت ۸۲ به ۱ را یک کف در نظر بگیرید، نه یک سقف. رقم CyberArk در سطح وسیع هویت‌های ماشینی اندازه‌گیری شده، از جمله حساب‌های سرویس و کلیدهای API که پیش از موج کنونی عامل‌ها وجود داشتند. با گسترش استقرار عامل‌ها در سازمان شما، انتظار داشته باشید نسبت هویت‌های غیرانسانی به انسانی سریع‌تر از ظرفیت فرآیند بازبینی دسترسی فعلی شما رشد کند.
- بین «عامل می‌تواند وارد شود» و «عامل باید بدون نظارت وارد شود» تفاوت بگذارید. ویژگی‌هایی مانند Secure Agentic Autofill مسئله‌ی افشای اعتبارنامه را حل می‌کنند، اما به این پرسش حاکمیتی پاسخ نمی‌دهند که کدام وظایف باید بدون حضور انسان در فرآیند توسط عامل اجرا شوند. این تصمیم سیاستی بر عهده‌ی تیم شما است، نه فروشنده‌ی ابزار هویت.
نتیجه‌ی کاربردی این است که مدل خزانه‌داری، صرف‌نظر از آنکه آگاهانه یک محصول «هویت عامل هوش مصنوعی» را پذیرفته باشید یا نه، در حال بازسازی است. اگر سازمان شما امروز عامل‌هایی را روی سیستم‌های تولیدی اجرا می‌کند، فرض کنید مسیر اعتبارنامه‌ای که آن‌ها استفاده می‌کنند برای یک انسان طراحی شده و قبل از آنکه تیم حسابرسی شما، یا یک مهاجم، این خالی را پیدا کند، آن را به سمت دسترسی محدود، قابل‌حسابرسی و کوتاه‌مدت منتقل کنید.