تصور کنید یک عامل هوش مصنوعی دسترسی به ایمیل‌های شما داشته باشد یا بتواند از حساب بانکی شما پول خرج کند؛ چنین ابزاری تنها به اندازهٔ مرزهای امنیتی و محدودیت‌هایی که اطرافش تعریف شده، قابل‌اعتماد است. طبق گزارش ۹ سپتامبر ۲۰۲۶ از تکنومتریا (Technometria)، صنعت فناوری در حالی که مشکل احراز هویت (Authentication) را تا حد زیادی حل کرده، اما در زمینهٔ مجوزدهی (Authorization) با مجموعه‌ای از کدهای بدساخت، تکه‌تکه و ارتجالی دست‌وپنجه نرم می‌کند.
برای دهه‌ها، تمرکز دنیای تکنولوژی روی این سؤال اول بود که «شما کیستید؟». ابزارهایی مثل Passkeys و FIDO به‌طور مؤثری شکاف‌های امنیتی را که در اوایل دهه ۲۰۰۰ رایج بود، بستند. اما سؤال دوم یعنی «شما اجازه دارید چه کاری انجام دهید؟» هنوز توسط تقریباً هر تیم مهندسی به شکلی ناقص و بد بازتعریف می‌شود.
همان‌طور که در تحلیل قبلی ما درباره‌ی اینکه چگونه عامل‌های هوش مصنوعی در حال شکستن کنترل‌های دسترسی سنتی هستند اشاره کردیم، تغییر تمرکز به سمت مجوزدهی دیگر یک انتخاب نیست، بلکه یک ضرورت است. در دنیای نرم‌افزارهای خودمختار، تنها راه حفظ امنیت این است که بتوانیم بدون واگذاری کنترل کامل، اختیار انجام کارهای خاصی را به ماشین بسپاریم (تفویض اختیار).
تکامل هویت
درک این موضوع که هویت چیزی فراتر از یک نام کاربری و رمز عبور ساده است، از دهه‌ها پیش آغاز شد. نویسندهٔ این گزارش در سال ۲۰۰۱، زمانی که به عنوان مدیر ارشد فناوری (CIO) برای ایالت یوتا خدمت می‌کرد، متوجه شد تقریباً هر مشکلی که به میز او می‌رسد، یک لایهٔ پنهان از هویت دارد. این مسائل شامل مواردی چون یکپارچه‌سازی دایرکتوری‌ها برای آدرس‌های utah.gov، انتقال وب‌سایت ایالتی به یک دامنه جدید و مدیریت دسترسی‌های سیستمی بود.
این تجربیات منجر به شکل‌گیری «کارگاه هویت اینترنتی» (Internet Identity Workshop یا IIW) شد که تاکنون ۴۲ جلسه برگزار کرده است. IIW به مرکزی برای جامعهٔ هویت تبدیل شد تا سخت‌ترین مشکلات این حوزه را حل کند. این مسیر طولانی در سه کتاب مستند شده است: کتاب Digital Identity که بر استراتژی‌های سازمانی تمرکز دارد، کتاب The Live Web که به داده‌های فردی و APIها می‌پردازد، و کتاب Learning Digital Identity که ثابت کرد هویت در اصل دربارهٔ «روابط» است، نه فقط شناسه‌های خشک و ثابت.
شکاف مجوزدهی
مجوزدهی (Authorization) — شبیه نگهبانی است که بعد از ورود شما به ساختمان، تعیین می‌کند به کدام اتاق‌ها دسترسی دارید و چه وسایلی را می‌توانید با خود ببرید — بسیار سخت‌تر از احراز هویت است. دلیل این دشواری آن است که مجوزدهی یک سؤال ساده نیست، بلکه چهار متغیر متمایز است که باید همزمان پاسخ داده شوند:
- قابلیت (Capability): این شخص یا عامل هوش مصنوعی واقعاً چه کارهایی را می‌تواند انجام دهد؟
- شرایط (Conditions): تحت چه شرایط خاصی این اقدام مجاز است؟
- تفویض (Delegation): این اقدام از طرف چه کسی و به نمایندگی از چه کسی انجام می‌شود؟
- زمینه (Context): درخواست در چه محیطی (کدام دستگاه، چه زمانی و در چه مکانی) ارسال شده است؟
اگر هر یک از این متغیرها نادیده گرفته شوند، مدل امنیتی عملاً بی‌فایده می‌شود. یک ورود موفق (Login) شما را از در عبور می‌دهد، اما هیچ چیز دربارهٔ این نمی‌گوید که به کدام اتاق‌ها می‌توانید وارد شوید یا چه چیزی را می‌توانید با خود بیرون ببرید. برای مثال، درخواستی که برای یک مدیر در ساعت ۱۲ ظهر از داخل دفتر معتبر است، اگر توسط یک پیمانکار در نیمه‌شب و از دستگاهی ناشناس ارسال شود، یک رخنهٔ امنیتی جدی است.
شکست لایهٔ معنایی
این مشکل تا لایه‌های عمیق داده‌ها نفوذ کرده است. به گزارش dev.to، در اکثر سازمان‌ها شکافی عمیق بین «ارائه‌دهندهٔ هویت» (Identity Provider) و «انبار داده» (Data Warehouse) وجود دارد. ارائه‌دهنده می‌داند کاربر کیست و انبار داده جداول را می‌شناسد، اما هیچ‌کدام نمی‌دانند که یک تحلیلگر خاص باید درآمد منطقه EMEA را ببیند اما نباید به حقوق کارکنان در همان جدول دسترسی داشته باشد.
برای حل این مشکل، بسیاری از تیم‌ها به راهکارهای خطرناکی مثل ایجاد نسخه‌های تکراری از مجموعه‌داده‌ها برای مخاطبان مختلف روی می‌آورند. این مجموعه‌داده‌ها به‌سرعت از هم فاصله می‌گیرند (Drift)، باعث می‌شوند تیم‌ها unsure شوند که کدام نسخه به‌روز است و در نهایت حفره‌های امنیتی عظیمی ایجاد می‌کنند. این چالش در مدیریت داده‌ها، مشابه پیچیدگی‌هایی است که در جایگزینی فایل‌های Markdown با پایگاه‌های دانش آنلاین برای عامل‌های AI مشاهده می‌کنیم، جایی که ساختار داده‌ها مستقیماً بر عملکرد مدل اثر می‌گذارد.
مقیاس‌پذیری با دسترسی مبتنی بر سیاست
همکاری با AWS Identity روی سرویس Amazon Verified Permissions و زبان سیاست‌گذاری Cedar یک بینش حیاتی را آشکار کرد: مجوزدهی دقیق (Fine-grained) در واقع باعث بهبود تجربه کاربری می‌شود. وقتی قوانین صریح باشند و خارج از کد برنامه قرار بگیرند، کاربران دقیقاً به همان دسترسی‌هایی دسترسی دارند که نیاز دارند.
این رویکرد از دو شکست رایج در نرم‌افزارهای سازمانی جلوگیری می‌کند:
۱. غرق کردن کاربر در درخواست‌های مداوم و آزاردهنده برای تایید دسترسی.
۲. دادن «کلید تمام درها» (دسترسی کامل) به کاربر فقط برای اینکه یک قابلیت ساده در نرم‌افزار کار کند.
درست انجام دادن مجوزدهی تضمین می‌کند که «امنیت» و «قابلیت استفاده» دیگر با هم نجنگند و سیستم بتواند همزمان هم امن و هم خوش‌ساخت باقی بماند.
بحران هوش مصنوعی عامل‌محور
ظهور عامل‌های هوش مصنوعی (AI Agents) — مثل دستیاران هوشمندی که می‌توانند به‌جای شما ایمیل بزنند، تقویم را بخوانند، خرید کنند یا پول خرج کنند — مجوزدهی را از یک دغدغهٔ پس‌زمینه به چالش اصلی این حوزه تبدیل کرده است. وقتی عامل‌ها شروع به اقدام از طرف انسان‌ها می‌کنند، سؤال این است که «این موجود اجازه چه کاری دارد و با اجازه چه کسی؟»
اگر نتوانیم دقیقاً تعریف کنیم یک عامل چه کاری می‌تواند از طرف ما انجام دهد، مجبوریم بین دو گزینه بد یکی را انتخاب کنیم: یا عامل‌هایی که به‌شدت محدود و عملاً بی‌فایده‌اند، یا عامل‌هایی که باید کورکورانه به آن‌ها اعتماد کنیم. این مسئله به همان اندازه که یک مشکل فنی است، یک مشکل انسانی است و می‌تواند به آسیب‌پذیری‌هایی منجر شود که حتی با فیلترهای لایهٔ پرامپت نیز قابل حل نیستند.
مجوزدهی به عنوان زیرساخت ضروری عمل می‌کند که نرم‌افزار را پاسخگو و قابل‌لغو (Revocable) می‌کند. این سیستم به ما اجازه می‌دهد اختیار واقعی را به ماشین‌ها تفویض کنیم بدون اینکه تسلیم آن‌ها شویم. بدون این زیرساخت، واگذاری اختیار واقعی به یک ماشین برای هر سازمان یک ریسک غیرقابل‌قبول است.
حرکت به سمت مدل‌های مبتنی بر سیاست
برای حل این بحران، معماران سیستم اکنون از کدهای درهم‌تنیدهٔ کنترل دسترسی به سمت «مجوزدهی مبتنی بر سیاست» (Policy-based Authorization) حرکت می‌کنند. این رویکرد شامل جداسازی «تصمیم» (آیا این کار مجاز است؟) از «اجرا» (مسدود کردن یا اجازه دادن به اقدام) است.
در کتاب جدید Authorization in Action از انتشارات Manning، این انتقال از طریق یک شرکت فرضی به نام ACME روایت شده است. داستان ACME را دنبال می‌کند که چگونه از کدهای ارتجالی به سمتی می‌رود که بتواند دربارهٔ سیستم خود استدلال کند. این کتاب روی مکانیسم‌های عینی تمرکز دارد، از جمله:
- روابط و نقش‌ها: تعریف دقیق اینکه کاربران چگونه به منابع متصل می‌شوند.
- ویژگی‌ها (Attributes): استفاده از خصوصیات خاص برای فعال کردن یا غیرفعال کردن دسترسی.
- زبان‌های سیاست‌گذاری: انتقال منطق از داخل کد برنامه به فرمت‌های خوانا و قابل مدیریت.
- معماری: جداسازی کامل فرآیند تصمیم‌گیری از نقطهٔ اجرا.
این همان چارچوب عملی است که توسعه‌دهندگان و معماران — مشابه چالش‌هایی که معماران سازمانی در BYU با آن روبرو بودند — برای اتخاذ تصمیمات امنیتی روزمره به آن نیاز دارند.
هویت به ما می‌گوید چه کسی درگیر است، اما مجوزدهی تعیین می‌کند چه اتفاقی می‌افتد. این سؤال دوم در سکوت، در حال تبدیل شدن به قلب امنیت، حاکمیت (Governance) و اعتماد در فضای آنلاین است.
گام بعدی شما
- اگر توسعه‌دهنده هستید، بررسی کنید که آیا منطق دسترسی‌ها را در کد برنامه (Hard-coded) نوشته‌اید یا از لایه‌های مجزا استفاده می‌کنید.
- زبان‌های سیاست‌گذاری مدرن مثل Cedar را برای مدیریت دسترسی‌های ریزدانه (Fine-grained) مطالعه کنید.
- در طراحی عامل‌های هوش مصنوعی، ابتدا «محدودهٔ تفویض اختیار» را تعریف کنید و سپس به سراغ قابلیت‌های مدل بروید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو