دسترسی‌های گستردهٔ عامل‌های هوش مصنوعی امنیت داده‌های سازمانی را به خطر انداخت

یک کلید API لو رفته اکنون می‌تواند به یک عامل خودگردان اجازه دهد تا در چند ثانیه بودجه یک شرکت را تخلیه یا پایگاه داده‌ای را پاک کند. رویکرد سنتی «بله یا خیر» برای مجوزها شکست خورده است، زیرا موجوداتی که درخواست دسترسی می‌دهند دیگر فقط انسان نیستند.

بسیاری از سامانه‌های امنیتی بر این فرض بنا شده‌اند که پشت هر درخواست، یک شخص قرار دارد. امروز، این درخواست به همان اندازه احتمال دارد که از یک عامل کدنویسی، یک شغل CI یا زنجیره‌ای از سه عامل مختلف بیاید که آخرین آن‌ها اصلاً نمی‌داند کدام انسان درخواست را شروع کرده است. این تغییر، شکافی عظیم در حکمرانی ایجاد کرده است؛ جایی که هویت‌های غیرانسانی، سطوح وسیع و خطرناکی از امتیازات استفاده‌نشده را در اختیار دارند.

طبق گزارش پژوهشی دسترسی ابری Sonrai که در مه ۲۰۲۶ منتشر شد، ۹۲٪ از هویت‌هایی که مجوزهای حساس داشتند، طی ۹۰ روز حتی یک بار از آن‌ها استفاده نکردند. نکته تکان‌دهنده‌تر این است که ۸۷٪ از این گروه، هویت‌های ماشینی بودند. اگرچه این یک اسکن تجاری بود و نه یک حسابرسی مستقل، اما روند واضح است: اعطای مجوزهای بیش از حد، یک ریسک تئوریک نیست، بلکه واقعیتی در محیط‌های عملیاتی است.

مکانیسم‌های کنترل دسترسی

در هستهٔ خود، هر سامانهٔ کنترل دسترسی فقط راهی برای ثبت و بررسی سه چیز است: یک سوژه (چه کسی درخواست می‌دهد)، یک اقدام (چه کاری می‌خواهد انجام دهد) و یک منبع (روی چه چیزی می‌خواهد این کار را بکند).

کنترل دسترسی دانه‌درشت (Coarse-grained) این سه بخش را کاملاً باز می‌گذارد. مجوزی مثل «مهندسان می‌توانند از پایگاه داده استفاده کنند» ممکن است ۴۰ نفر، ۶ فعل مختلف و تمام جداول شرکت را پوشش دهد. نوشتن این مجوز سریع است و به همین دلیل هنوز زنده مانده، اما بسیار خطرناک است.

کنترل دسترسی دانه‌ریز (Granular) این بخش‌ها را محدود می‌کند. به‌جای یک اجازه کلی، قانونی تعریف می‌کنید مثل: «سرویس گزارش‌دهی فقط می‌تواند دستور SELECT را روی جدول سفارشات اجرا کند و هیچ کار دیگری نتواند انجام دهد». این تفاوت شبیه تفاوت بین کلید خانه است که هر دری را برای همیشه باز می‌کند و کارت کلید هتل که فقط اتاق ۴۰۲ در طبقه چهارم را تا جمعه ساعت ۱۱ باز می‌کند. پذیرش هتل می‌تواند کارت را از لابی باطل کند بدون اینکه به خودِ در دست بزند.

پنج بعدِ دانه‌ریزی

کنترل دسترسی دانه‌ریز در واقع اجرای عملی «اصل کمترین امتیاز» است. به‌جای یک نقش کلی مثل «مهندس»، مجوزها در کوچک‌ترین واحد کاربردی تعریف می‌شوند. این کار با تغییر پنج محور خاص انجام می‌شود:

۱. چه کسی درخواست می‌دهد: حرکت از اعتبارنامه‌های مشترک تیمی به یک هویت منحصربه‌فرد برای هر فراخوان. این برای هویت‌های غیرانسانی مثل عامل‌ها حیاتی است. راه حل ساده اما خسته‌کننده است: یک هویت برای هر فراخوان، هرگز یک اعتبارنامه مشترک برای هر تیم.

۲. چه اقدامی می‌خواهند: تقسیم مجوزهای کلی «خواندن» به افعال خاص. سامانه‌های دانه‌درشت معمولاً فقط «خواندن» و «مدیریت» دارند. سامانه‌های دانه‌ریز افعال را بر اساس میزان آسیبی که می‌توانند بزنند تقسیم می‌کنند. برای مثال، دیدن یک خط لاگ با استخراج کل جدول لاگ‌ها سطح ریسک متفاوتی دارد، هرچند هر دو از نظر فنی «خواندن» هستند.

۳. دقیقاً کدام منبع: محدود کردن دسترسی به سطح سطر یا ابزار. یک پایگاه داده می‌تواند در سطح سرور، دیتابیس، جدول، ستون یا سطر محدود شود. در هوش مصنوعی، این یعنی تصمیم بگیرید آیا یک مدل می‌تواند یک ابزار خاص را فراخوانی کند یا به تمام ابزارهای موجود دسترسی داشته باشد. محدودسازی در سطح سطر بسیار حیاتی است؛ این تفاوت بین این است که یک عامل پشتیبانی فقط تیکت‌های خودش را ببیند یا تمام تیکت‌های سامانه را. این چالش‌ها در مدیریت دسترسی در برابر تزریق پرامپت نیز مورد بررسی قرار گرفته است تا از سوءاستفاده از مجوزها جلوگیری شود.

۴. میزان مصرف: این حیاتی‌ترین محور برای هوش مصنوعی است. چون یک حلقه (loop) می‌تواند هزاران فراخوانی ایجاد کند، مجوزی بدون سقف هزینه در واقع یک حساب باز و بی‌انتها است. کنترل دانه‌ریز، محدودیت‌های دلاری یا سهمیه توکن (Token) — تکه‌های کوچکی از متن که مدل تکه‌تکه می‌خورد — را به هر کلید می‌چسباند. توسعه‌دهندگان سال‌هاست این را درخواست کرده‌اند و انجمن توسعه‌دهندگان OpenAI پر است از درخواست‌های مشابه برای سقف هزینه در هر کلید.

۵. تحت چه شرایطی: افزودن زمینه‌هایی مثل IP منبع، ساعت روز، محیط، وضعیت دستگاه یا تاریخ انقضا. انقضا دست‌کم‌گرفته‌شده‌ترین ابزار است؛ مجوزی بدون تاریخ پایان، یک حفره امنیتی دائمی است و ریشه اکثر حوادثی است که می‌پرسیم «چطور این کلید قدیمی هنوز کار می‌کرد؟».

مقایسه RBAC، ABAC و ReBAC

بسیاری از تیم‌ها کنترل دسترسی مبتنی بر نقش (RBAC) را با دانه‌ریزی اشتباه می‌گیرند. RBAC مجوزها را در نقش‌ها (مثلاً «توسعه‌دهنده») گروه‌بندی می‌کند، اما اگر آن نقش بیش از حد گسترده باشد، باز هم دانه‌درشت است. وقتی تیم‌ها سعی می‌کنند دانه‌ریزی را به زور در RBAC جای دهند، با «انفجار نقش‌ها» مواجه می‌شوند. این اتفاق زمانی می‌افتد که هر شرط جدید نیاز به یک نقش جدید داشته باشد و نام‌هایی مثل developer-staging-eu-readonly ظاهر شوند تا جایی که هیچ‌کس نداند نقش‌ها واقعاً چه می‌کنند.

کنترل دسترسی مبتنی بر ویژگی (ABAC) این مشکل را با ارزیابی ویژگی‌ها — مثل دپارتمان، سطح دسترسی، طبقه‌بندی منبع یا مکان — در لحظه درخواست حل می‌کند. هزینه این کار این است که وقتی درخواستی رد می‌شود، باید ردیابی کنید کدام ویژگی خاص باعث شکست شده است، به‌جای اینکه فقط نام یک نقش را بخوانید.

کنترل دسترسی مبتنی بر رابطه (ReBAC) می‌پرسد سوژه چه رابطه‌ای با منبع دارد. مثلاً شما می‌توانید سندی را ویرایش کنید چون آن را ساخته‌اید، یا پروفایلی را ببینید چون مدیر آن شخص هستید. این مدلی است که گوگل درایو و اکثر اپلیکیشن‌هایی که مالکیت در آن‌ها قانون اصلی است، استفاده می‌کنند.

بیشتر سامانه‌های واقعی از RBAC برای خطوط کلی و لایه‌های ABAC یا ReBAC برای موارد خاص استفاده می‌کنند. دانه‌ریزی از قوانینی می‌آید که می‌نویسید، نه مدلی که انتخاب می‌کنید.

فاکتور ریسک عامل‌ها

عامل‌های هوش مصنوعی حجم و سرعتی از درخواست‌ها را ایجاد می‌کنند که انسان‌ها هرگز تولید نمی‌کردند. ابزارهایی مثل Claude Code و GPT Codex فایل‌ها را می‌خوانند، ابزارها را فراخوانی می‌کنند و چندین فراخوانی مدل را از یک دستور واحد به هم زنجیر می‌کنند. این موضوع این فرض را می‌شکند که هر درخواست چیزی است که یک انسان صریحاً خواسته است.

همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، مدیریت هویت‌ها در مقیاس بزرگ چالش‌برانگیز است. یک نظرسنجی از 1Password از ۱۰۰۰ نفر از کارکنان امنیتی و مهندسی در شرکت‌های بزرگ آمریکایی در اواسط ۲۰۲۶ نشان داد که عامل‌های در حال اجرا در محیط عملیاتی، تقریباً به دو برابر داده‌های مجاز دسترسی داشتند. علاوه بر این، ۳۳٪ از توسعه‌دهندگان گزارش دادند که حوادث امنیتی مرتبط با هویت‌های غیرانسانی با امتیازات بیش از حد داشته‌اند و ۴۰٪ اعتراف کردند که عامل‌ها را پس از پایان کار، با دسترسی دائمی به سامانه‌ها و اسرار (secrets) رها کرده‌اند.

چرا پیاده‌سازی شکست می‌خورد؟

با وجود اتفاق نظر بر سر «کمترین امتیاز»، اکثر شرکت‌ها به سه دلیل در پیاده‌سازی شکست می‌خورند:

• محدودیت کلیدهای ارائه‌دهنده: کلیدهای استاندارد OpenAI یا Anthropic اغلب «همه یا هیچ» هستند. شما نمی‌توانید به‌طور پیش‌فرض به یک کلید بگویید فقط GPT-4o را با سقف ۵۰ دلار و بدون فراخوانی ابزار اجازه دهد. این باعث می‌شود تیم‌ها یا یک کلید را به اشتراک بگذارند (از دست دادن ردیابی) یا چندین کلید بسازند (از دست دادن کنترل مرکزی).
• محل اشتباه اجرای مجوزها: وقتی بررسی مجوزها در کد اپلیکیشن دفن شده باشد، اغلب توسط اسکریپت‌های جدید، نوت‌بوک‌ها یا کرون‌جاب‌ها نادیده گرفته می‌شوند. شما نمی‌توانید چیزی را که نمی‌توانید ردیابی کنید، اجرا کنید.
• نبود ردیابی (Attribution): اگر نتوانید جهش هزینه را به یک فراخوان خاص برگردانید، نمی‌توانید مجوز را محدود کنید. در Zonko Labs، من ابزاری برای ثبت لاگ‌های داده‌های هوش مصنوعی ساختم؛ ارزش آن در این بود که هر خط لاگ به یک فراخوان خاص برمی‌گشت. بدون این، جهش هزینه فقط یک عدد است که بالا می‌رود.

نقش درگاه هوش مصنوعی (AI Gateway)

برای حل این مشکلات، بررسی مجوزها باید در مسیر ترافیک باشد. یک درگاه هوش مصنوعی مثل یک پروکسی عمل می‌کند که هر فراخوانی مدل باید از آن عبور کند. این به سامانه اجازه می‌دهد «کلیدهای مجازی» صادر کند در حالی که اعتبارنامه‌های واقعی ارائه‌دهنده را داخل درگاه مخفی نگه می‌دارد.

Bifrost، یک درگاه متن‌باز، این موضوع را با اجازه دادن به پیکربندی‌های حکمرانی نشان می‌دهد که مدل‌های مجاز، تاریخ انقضا و شناسه‌های تیمی را صریحاً تعریف می‌کند. برای مثال، پیکربندی یک بات پشتیبانی می‌تواند allow_all_providers: false باشد، مدل‌های مجاز را به ["gpt-4o"] محدود کند و تاریخ انقضا را روی ۲۰۲۷-۰۱-۰۱ قرار دهد. این رویکرد متمرکز می‌تواند جایگزین پیکربندی‌های پراکنده در محیط‌های سازمانی شود تا مدیریت دسترسی ساده‌تر گردد.

کنترل‌های پیشرفته درگاه

درگاه‌های مدرن کنترل‌های عمیق‌تری نسبت به لیست‌های مجاز ساده ارائه می‌دهند:

• سقف بودجه و نرخ: این‌ها روی خودِ کلید قرار دارند. بودجه‌ها از یک max_limit ترکیبی با reset_duration (۱ دقیقه تا ۱ سال) استفاده می‌کنند. محدودیت‌های نرخ از شمارنده‌های جداگانه برای توکن و درخواست استفاده می‌کنند.
• کدهای خطای دقیق: به‌جای شکست‌های کلی، درگاه‌های دانه‌ریز کدهای وضعیت خاص برمی‌گردانند: ۴۰۲ برای budget_exceeded (بودجه تمام شد)، ۴۲۹ برای token_limited و ۴۰۳ برای model_blocked.
• دسترسی به ابزار: دسترسی به‌صورت پیش‌فرض «رد شده» است. اگر یک کلید مجازی پیکربندی صریحی برای سرورهای پروتکل زمینهٔ مدل (MCP) نداشته باشد، هیچ ابزاری دریافت نمی‌کند. ابزارهای اعطا شده در tools_to_execute لیست می‌شوند. این حیاتی است چون یک ابزار سیستم فایل می‌تواند در یک حلقه عامل، آسیب عظیمی بزند. در واقع، تله‌های مجوز در پروتکل MCP نشان داده‌اند که چگونه دسترسی‌های تسهیل‌شده می‌توانند به نفوذ به داده‌های حساس منجر شوند.
• نقش‌های مدیریتی: Bifrost با سه نقش سیستمی عرضه می‌شود — مدیر (۴۲ مجوز)، توسعه‌دهنده (۲۷) و مشاهده‌گر (۱۴) — با قابلیت ساخت نقش‌های سفارشی.
• کنترل دسترسی به داده‌ها: این قابلیت، توانایی باز کردن صفحه لاگ‌ها را از توانایی دیدن داده‌ها جدا می‌کند. گزینه‌ها شامل own-data (داده‌های خود)، team-data یا all-data است.
• ابزارهای مقیاس‌پذیری: پروفایل‌های دسترسی اجازه می‌دهند یک سیاست، به‌طور خودکار کلیدهای مجازی کاربر-محور صادر کند. کلیدها می‌توانند در بازه‌های ۱ ساعت تا ۳۶۵ روز چرخش کنند تا از فروپاشی «کلید مشترک» در تیم‌های بزرگ جلوگیری شود.
• قابلیت حسابرسی: رویدادهای مدیریتی می‌توانند با HMAC امضا شوند و به‌صورت JSON یا syslog برای ابزارهای SIEM صادر شوند.

بنچمارک‌های Bifrost نشان می‌دهند که در ۵۰۰۰ درخواست در ثانیه، حدود ۲۰ میکروثانیه تأخیر اضافه می‌شود. نکته کلیدی این است که بررسی مجوز باید در مسیر ترافیک باشد، نه اینکه در ۱۵ کدبیس مختلف کپی-پیست شود.

تنظیم درجهٔ دسترسی

رسیدن به دانه‌ریزی کامل در سطح سطر اغلب هدفی غیرواقع‌بینانه است که منجر به پیچیدگی غیرقابل مدیریت می‌شود. هدف باید این باشد که دو پله از کلیدهای مشترک جلوتر بروید.

برای تیم‌هایی که امروز شروع می‌کنند، ترتیب پیشنهادی عملیات این است:
۱. ایجاد یک هویت برای هر فراخوان.
۲. تعیین سقف هزینه برای هر هویت.
۳. افزودن تاریخ انقضا.
۴. ایجاد لیست مجاز مدل/منبع.
۵. تعریف شرایط محیطی.

این توالی، بیشترین امنیت را با کمترین تلاش مدیریتی فراهم می‌کند. هدف یک مدل تئوریک کامل نیست، بلکه سامانه‌ای است که بتوانید به این سؤال پاسخ دهید: اگر همین لحظه یک اعتبارنامه لو برود، دقیقاً چه کسی چه کاری می‌تواند انجام دهد و چقدر می‌تواند هزینه کند پیش از آنکه کسی متوجه شود؟

گام بعدی شما

• بررسی کنید آیا در حال حاضر از کلیدهای API مشترک در تیم خود استفاده می‌کنید و آن‌ها را به هویت‌های مجزا تبدیل کنید.
• برای هر عامل یا سرویس هوش مصنوعی، یک سقف هزینه (Spending Cap) ماهانه تعریف کنید تا از حلقه‌های بی‌نهایت جلوگیری شود.
• تاریخ انقضا برای تمام کلیدهای دسترسی موقت تعریف کنید تا حفره‌های امنیتی دائمی ایجاد نشود.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.