تصور کنید به یک دستیار دیجیتال دسترسی کامل به ایمیل‌هایتان را می‌دهید تا فقط فاکتورها را جمع‌آوری کند، اما او به طور تصادفی تمام پیام‌های شما را پاک می‌کند. این فاجعه زمانی رخ می‌دهد که ما «توانایی فنی» را با «اختیار قانونی» اشتباه بگیریم.
آریدیو سیلوا (Aridio Silva)، پژوهشگر مستقل و خالق معماری SGAEIA (معماری هوش مصنوعی لبه‌ایِ مستقل، تحت نظارت و امن)، معتقد است رویکرد فعلی به امنیت عامل‌محور اساساً معیوب است زیرا قابلیت‌های فنی را با مجوزهای قانونی خلط می‌کند. در حال حاضر، اکثر توسعه‌دهندگان دسترسی‌های گسترده‌ای را به یک عامل (Agent) — مثل یک برنامه‌ای که می‌تواند به طور مستقل تصمیم بگیرد و عمل کند — می‌دهند؛ برای مثال دسترسی کامل به ایمیل‌ها را اعطا می‌کنند و سپس صرفاً بر پرامپت‌های سیستمی تکیه می‌کنند تا مدل را در چارچوب نگه دارند.
همان‌طور که در بحث‌های گذشته‌ی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تکیه بر دستورات متنی برای ایجاد مرزهای امنیتی، یک شکاف حاکمیتی عظیم ایجاد می‌کند. وقتی سامانه‌ها از چت‌بات‌های ساده به عامل‌هایی تبدیل می‌شوند که می‌توانند اهداف سطح بالا را تفسیر کنند، ابزارها را فراخوانی نمایند، داده‌ها را بین سرویس‌های مختلف جابه‌جا کنند و زیر-وظایف را با حداقل دخالت انسان تفویض کنند، امنیت باید بر «اختیار عمل» متمرکز شود، نه فقط «دسترسی به اطلاعات». وقتی یک سیستم قادر است تغییراتی در دنیای واقعی ایجاد کند، امنیت باید بررسی کند که آیا عامل اجازه انجام آن عمل را دارد یا خیر، نه اینکه صرفاً آیا به اطلاعات دسترسی دارد یا نه.
تکامل مشکل مجوزها
در نرم‌افزارهای سنتی، برنامه معمولاً منتظر می‌ماند تا یک انسان گام بعدی را انتخاب کند. اما هوش مصنوعی عامل‌محور این پویایی را تغییر می‌دهد. یک عامل مستقل ممکن است هدفی کلی را تفسیر کرده و سپس به طور مستقل ابزارهایی را فراخوانی کند یا داده‌ها را بین سرویس‌ها منتقل نماید. این تغییر به این معناست که احراز هویت (Authentication) — که صرفاً یک عامل را شناسایی می‌کند یا یک درخواست را تأیید می‌کند — دیگر کافی نیست.
احراز هویت ضروری است، اما پاسخ این سؤال را نمی‌دهد که آیا یک عامل «باید» عملیاتی خاص را روی منبعی خاص، برای وظیفه‌ای مشخص و تحت شرایط فعلی انجام دهد یا خیر، و یا اینکه این مجوز تا چه زمانی باید اعتبار داشته باشد. سؤال کلیدی در طراحی این می‌شود: این عامل چه کاری را، به نمایندگی از چه کسی، تحت چه شرایطی انجام می‌دهد و این اختیار چگونه می‌تواند بازپس گرفته شود؟
این چارچوب با تکیه بر اصول اعتماد صفر (Zero Trust) و استانداردهایی مانند NIST SP 800-207، پیشنهاد می‌کند که به سمت «اختیار محدود» حرکت کنیم. این بدان معناست که مجوزها باید صریح، قابل اجرا و از همه مهم‌تر، در لحظه قابل ابطال باشند. هدف این است که عامل‌ها کارهای مفید انجام دهند، اما مجوزهایشان صریح، محدود، قابل اجرا، قابل رصد و قابل بازپس‌گیری باشد.
تفاوت قابلیت و اختیار
سیلوا بین آنچه یک عامل «می‌تواند» انجام دهد و آنچه «باید» انجام دهد، تمایز قائل می‌شود. برای مثال، یک اتصال به ایمیل ممکن است از نظر فنی اجازه جست‌وجو، خواندن، ارسال، فوروارد کردن، برچسب‌گذاری و حذف پیام‌ها را بدهد. اگر وظیفه عامل صرفاً این باشد که «فاکتورهای این هفته را پیدا و خلاصه کن»، او از نظر فنی قابلیت حذف کل صندوق ورودی یا فوروارد کردن پیوست‌ها به یک آدرس خارجی را دارد، اما نباید اختیار انجام این کارها را داشته باشد.
قابلیت (Capability) توصیف‌کننده توان فنی است (آنچه عامل می‌تواند انجام دهد). اختیار (Authority) توصیف‌کننده اجازه قانونی است (آنچه عامل مجاز است انجام دهد). برای یک توسعه‌دهنده، پیام عملی این است که یک اتصال ابزاری گسترده نباید به یک مجوز گسترده تبدیل شود. برای حل این مشکل، توسعه‌دهندگان باید عملیات خواندن، نوشتن، حذف، خروجی گرفتن، تأیید و اجرا را به عنوان عملیات‌های کاملاً مجزا در نظر بگیرند.
به جای اعطای دسترسی کلی، سیستم باید «کمترین اختیار کاربردی» مورد نیاز برای هدف فعلی را اعطا کند. این رویکرد با دستورالعمل‌های امنیت عامل‌ها همسو است که بر هویت‌های اختصاصی، محدود کردن دامنه اقدام و منبع، و دسترسی کنترل‌شده به ابزارها تأکید دارد. این روش تضمین می‌کند که یک وظیفه «خواند و خلاصه کن»، به طور ضمنی اجازه ارسال پیوست‌ها به بیرون یا حذف پیام‌ها را ندهد. در همین راستا، بررسی تله‌های مجوزدهی در پروتکل MCP نشان می‌دهد که چگونه تسهیل دسترسی به داده‌های حساس می‌تواند منجر به دور زدن مرزهای امنیتی شود.
کالبدشکافی اختیار محدود
بر اساس پژوهش‌های SGAEIA، یک طراحی امن باید از جملات ساده‌ای مثل «عامل A به سیستم X دسترسی دارد» فاصله بگیرد، زیرا چنین جملاتی سؤالات حیاتی را بی‌پاسخ می‌گذارند. در عوض، برای هر اقدام باید چندین بعد مفهومی تعریف شود تا اطمینان حاصل شود که اختیار محدود شده است:
- کنش‌گر و هدف: کدام عامل دقیقاً در حال فعالیت است و برای چه وظیفه تعریف‌شده‌ای؟ (مثلاً یک عامل زیرساختی که در حال رفع یک حادثه خاص در یک سرویس است).
- منبع و عملیات: کدام منبع خاص تحت تأثیر می‌گیرد و کدام اقدام مجاز است؟ (مثلاً دسترسی نوشتن به یک سرویس خاص، به جای دسترسی به تمام سرویس‌ها).
- شرایط و مدت‌زمان: مجوز چه زمانی معتبر است و دقیقاً چه زمانی منقضی می‌شود؟ (مثلاً یک مجوز محدود زمانی که به محض رفع حادثه منقضی می‌شود).
- قوانین تفویض: آیا این اختیار می‌تواند به عامل دیگری منتقل شود و اگر بله، آیا مجوز جدید محدودتر از نسخه اصلی است؟
این ابعاد به جای اینکه یک طرح پیاده‌سازی سخت‌گیرانه باشند، ابزارهای مفهومی برای استدلال درباره اختیار هستند. برای مثال، آماده کردن یک تراکنش مالی یک وظیفه مجزا است و به طور خودکار اجازه تأیید یا اجرای همان تراکنش را به عامل نمی‌دهد. کمترین امتیاز برای یک سیستم مستقل، یعنی کمترین اختیار کاربردی برای هدف فعلی، همراه با یک محدودیت زمانی سخت‌گیرانه است.
خطرات تفویض اختیار
در گردش‌کارهای چندعاملی، وظایف اغلب از انسان به یک عامل، سپس به یک زیر-عامل، یک ابزار و در نهایت به یک سرویس خارجی منتقل می‌شوند. سیلوا هشدار می‌دهد که هر انتقال (Handoff)، یک ریسک پاسخ‌گویی ایجاد می‌کند: مجوز از کجا آمده است، چه بخشی از آن تفویض شده و آیا گیرنده اختیارات بیشتری نسبت به فرستنده به دست آورده است؟
پژوهش‌ها در مورد تفویض احراز شده، بر اهمیت حیاتی پاسخ‌گویی و روابط تفویض ردیابی‌پذیر تأکید می‌کنند. یک قاعده محوری در SGAEIA این است که اختیار تفویض‌شده باید برابر یا محدودتر از اختیار منبع باشد. این امر یک رابطه تفویض ردیابی‌پذیر را تضمین می‌کند:
- محدودیت دامنه: اگر عامل A اجازه خواندن رکورد مشتری را دارد، انتقال یک زیر-وظیفه به عامل B نباید به او اجازه تغییر آن رکورد را بدهد.
- محدودیت زمانی: اگر مجوز عامل A بعد از ۱۰ دقیقه منقضی می‌شود، مجوز مشتق‌شده برای عامل B نباید یک روز اعتبار داشته باشد.
- عدم ارتقای خودکار: یک عامل پایین‌دستی هرگز نباید صرفاً به دلیل اینکه مؤلفه‌ای دیگر وظیفه‌ای را به او سپرده است، اختیار بیشتری کسب کند.
مسیرهای عملیاتی ترکیبی
علاوه بر تفویض فردی، سیلوا به «قابلیت‌های ترکیبی» (Composed Capabilities) هشدار می‌دهد. این اتفاق زمانی می‌افتد که یک عامل چندین مجوز دارد که هر کدام به تنهایی امن به نظر می‌رسند، اما ترکیب آن‌ها مسیری پرخطر می‌سازد.
مثلاً عاملی که دسترسی به اسناد داخلی، یک ابزار تغییر فرمت (Transformation Tool) و یک سرویس پیام‌رسان خارجی دارد، ممکن است بتواند اطلاعات حساس را استخراج کرده، برای دور زدن فیلترها آن‌ها را تغییر شکل دهد و سپس به بیرون سازمان بفرستد. هر یک از این دسترسی‌ها به تنهایی ممکن است قابل قبول به نظر برسند، اما «مسیر اقدام ترکیبی» پروفایل ریسک متفاوتی ایجاد می‌کند. توسعه‌دهندگان باید بررسی کنند که عامل در کل گردش‌کار چه کارهایی می‌تواند انجام دهد، نه اینکه فقط لیست مجوزهای هر ابزار را به صورت جداگانه بررسی کنند.
مدیریت چرخه حیات اختیار
مجوزها نباید دائمی باشند. دسترسی‌ای که در شروع یک وظیفه مناسب بود، اگر وظیفه لغو شود، زمینه تغییر کند، مشکوک شویم که اعتبارنامه‌ها لو رفته‌اند یا کار به پایان برسد، به یک تهدید تبدیل می‌شود. کارهای موقت نباید به طور بی‌صدا امتیازات «شبحی» و دائمی به جای بگذارند.
معماری‌های امنیتی باید مکانیزمی برای انقضا یا بازپس‌گیری اختیار در حین عملیات داشته باشند، به طوری که سیستم‌های پایین‌دستی مدام بررسی کنند که آیا مجوز همچنان معتبر است یا خیر. این امر یک زنجیره ابطال پیچیده ایجاد می‌کند: اگر مجوز عامل اصلی لغو شود، سیستم باید بتواند تمام مجوزهای وابسته صادر شده برای زیر-عامل‌ها را ردیابی و ابطال کند.
یک طراحی تحت نظارت باید منشأ (Provenance) این مجوزها را قابل بررسی کند تا مشخص شود آیا یک مجوز مجزا و مستقل باید فعال بماند یا خیر. کلید کار این است که فرآیند تصمیم‌گیری در مورد ابطال، شفاف و قابل حسابرسی باشد.
اجرای مسیر اقدام
سیلوا تأکید می‌کند که پرامپتی مثل «فایل‌ها را پاک نکن» یک کنترل امنیتی نیست، بلکه یک پیشنهاد است. مرزهای امنیتی واقعی باید توسط سیستم‌هایی که فایل‌ها و ابزارها را ارائه می‌دهند اجرا شوند، نه توسط تصمیم عامل برای اطاعت کردن. اجرای مستقل و کنترل‌های زمان اجرا (Runtime Controls) مانع از آن می‌شود که یک برنامه اشتباه یا دستکاری‌شده به یک اقدام خارجی مجاز تبدیل شود.
برای مدیریت این موضوع، یک چرخه حیات کاربردی باید در نظر گرفته شود: درخواست اقدام $ \rightarrow $ ارزیابی مجوز $ \rightarrow $ اعطای اجازه محدود $ \rightarrow $ اجرای تصمیم $ \rightarrow $ رصد اجرا $ \rightarrow $ ارزیابی مجدد در صورت تغییر شرایط $ \rightarrow $ ابطال یا انقضای مجوز. این مدل مفهومی SGAEIA، استقلال عملیاتی را از اختیار نامحدود جدا می‌کند. در این راستا، جایگزینی مدل‌های ایستا با سیستم‌های امتیازدهی پویا در مدیریت ریسک می‌تواند لایه‌ای از امنیت فعال را به این چرخه اضافه کند.
در لبه (Edge) — جایی که اتصال به شبکه متناوب است — عامل‌ها ممکن است نیاز داشته باشند با زمینه محلی ناقص کار کنند. در حالی که تاب‌آوری ممکن است ایجاب کند که عامل در چارچوب اختیارات قبلاً اعطا شده به کار خود ادامه دهد، اما قطع شبکه هرگز نباید به عنوان مجوزی برای گسترش آن اختیارات تفسیر شود. این تضمین می‌کند که عامل حتی در زمان قطع اتصال از حاکمیت مرکزی، محدود باقی بماند.
چک‌لیست طراحی کاربردی
برای مهندسانی که این سیستم‌ها را پیاده می‌کنند، سیلوا یک فرآیند بررسی سخت‌گیرانه را پیشنهاد می‌دهد. برای هر اقدام حساس که یک عامل هوش مصنوعی می‌تواند انجام دهد، باید به سؤالات زیر پاسخ داده شود:
- کنش‌گر و هدف: چه عاملی در حال اقدام است و برای چه وظیفه‌ای؟
- منبع و عملیات: چه منبع خاصی تحت تأثیر می‌گیرد و چه اقداماتی مجاز است؟
- شرایط و مدت: مجوز چه زمانی معتبر است و چه زمانی منقضی می‌شود؟
- تفویض: آیا این اختیار قابل انتقال است و آیا عامل بعدی می‌تواند چیزی گسترده‌تر دریافت کند؟
- ابطال: اگر وظیفه به پایان برسد یا ریسک تغییر کند، مجوز چگونه می‌تواند تعلیق یا ابطال شود؟
- شواهد: یک اپراتور یا بازرس بعداً چه چیزی را می‌تواند بررسی کند؟
- ترکیب: عامل با ترکیب ابزارها و مجوزهایش چه کارهایی می‌تواند به سرانجام برساند؟
بازرسان باید بتوانند لاگ‌ها را بررسی کنند تا تعیین کنند چه کسی، به نمایندگی از چه کسی، روی چه منبع و عملیاتی، با چه مجوزی عمل کرده، آیا تفویض رخ داده است و چه شواهدی از این تصمیم حمایت کرده است. قابلیت حسابرسی (Auditability) یک فکر بعدی نیست، بلکه بخشی از هسته معماری است که به تیم‌ها کمک می‌کند نتایج را بررسی کرده و ارزیابی کنند که آیا سیستم در مرزهای تعیین‌شده باقی مانده است یا خیر. ذکر این نکته ضروری است که لاگ‌ها یا تست‌ها به تنهایی یک استقرار را تأیید نمی‌کنند؛ آن‌ها شواهدی از رفتار هستند، نه تضمینی برای امنیت. برای حل این شکاف حاکمیتی، رویکردهایی مانند TrustGraph برای جایگزینی تأییدیه‌های ایستا در حال توسعه هستند تا اعتماد را بر اساس گراف‌های پویا مدیریت کنند.
نتیجه‌گیری
این تغییر در تفکر، امنیت هوش مصنوعی را از رویکرد «به مدل اعتماد کن» به رویکرد «به شواهد اعتماد کن» منتقل می‌کند. با صریح، محدود و قابل ابطال کردن مجوزها، سازمان‌ها می‌توانند عامل‌های مستقل را بدون اینکه کلیدهای گاوصندوق را تحویل دهند، مستقر کنند.
این چارچوب پیش‌فرض‌های این حوزه را تغییر می‌دهد؛ به جای اینکه با عامل‌های هوش مصنوعی به عنوان کاربرانی با حساب کاربری برخورد کند، آن‌ها را به عنوان فرآیندهای گذرا با مأموریت‌های محدود و زمانی می‌بیند. این امر باعث حرکت از دسترسی مبتنی بر هویت به سمت مجوزدهی مبتنی بر وظیفه می‌شود. با افزایش مدیریت وظایف مالی و زیرساختی توسط عامل‌ها، صنعت احتمالاً به سمت پروتکل‌های استاندارد «کنترل عامل» حرکت خواهد کرد، مانند استاندارد کنترل عامل (ACS) که توسط پروژه امنیت GenAI در OWASP در حال بررسی است.
همان‌طور که اصل SGAEIA بیان می‌کند: هوش مصنوعی مستقل. تحت نظارت در طراحی. مورد اعتماد بر اساس شواهد.
گام بعدی شما
- در طراحی عامل‌های خود، دسترسی‌های API را از حالت «دائمی» به «مبتنی بر نشست» (Session-based) تغییر دهید.
- برای هر ابزار، عملیات خواندن (Read) و نوشتن (Write) را به دو مجوز کاملاً مجزا تبدیل کنید.
- یک مکانیزم برای ابطال سریع (Kill-switch) تمام مجوزهای تفویض‌شده به زیر-عامل‌ها طراحی کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو