چگونه عوامل هوش مصنوعی را در محدوده مجوزهای خود نگه داریم

نوشته شده توسط: Ido Shlomo یکی از بنیانگذاران و CTO امنیت توکن

عوامل هوش مصنوعی باید بیشتر به تنهایی انجام دهند. چه کسی زمان یا بازه توجه لازم برای تأیید هر فرمان را دارد؟ و تماشای ماموران در انجام کاری که از آنها خواسته شده است به طرز بی‌حسی خسته‌کننده‌ای است.

اما نمایندگان به خصوص در محیط های شرکتی به مرزها نیاز دارند. بدون محدودیت مشخص در مورد آنچه می توانند انجام دهند، جریان های عامل تمایل دارند از همه دسترسی های موجود استفاده کنند.

در اینجا یک مثال واقعی وجود دارد: یک توسعه‌دهنده از نماینده خود می‌خواهد تا دلیل شکست کار صادرات شبانه را دریابد. قانون تیم برای عوامل ساده است: آنها از طریق نقش های فقط خواندنی کار می کنند. اما توسعه‌دهنده برای کارهای حین تماس نیز ادمین دارد و هر دو نمایه در یک ~/.aws/config قرار می‌گیرند.

عامل هنگامی که می‌خواهد کار را دوباره اجرا کند، AccessDenied را می‌زند، بنابراین به نمایه مدیریت تغییر می‌کند، نقش را بر عهده می‌گیرد و aws s3 rm را در سطل تولید اجرا می‌کند تا ابتدا صادرات نیمه‌نوشته را پاک کند.

اعتبارنامه معتبر است. توسعه دهنده ممکن است امتیازات مدیر را در نظر بگیرد و مدیر می تواند اشیاء S3 را حذف کند. AWS امضا را بررسی می کند، نه اینکه چه کسی کلید را در دست دارد، بنابراین تا آنجا که AWS می داند، توسعه دهنده این کار را انجام داده است. نقض این است که یک عامل از نقشی استفاده کرده است که نمایندگان مجاز به استفاده از آن نیستند. برخلاف intent، می‌توانید آن را در هر درخواست بررسی کنید.

مقصر کیست؟ توسعه‌دهنده‌ای که نباید اعتبارنامه‌های خود را به نماینده می‌داد و اجازه نمی‌داد تا اقدامات را به‌طور خودکار تأیید کند؟ تسمه ساز؟ این سوال اشتباهی است باز هم، عوامل باید بیشتر به تنهایی انجام دهند، هم به عنوان یک توسعه دهنده و هم به عنوان مدیر توسعه دهندگانی که با هوش مصنوعی کار می کنند.

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

ابتدا باید مشکل را بررسی کنیم. فشار دائمی برای گسترش دسترسی نمایندگی وجود دارد و معمولا دلیل آن در انزوا منطقی است. به عنوان مثال یک کار گیر می کند. یا ادغام جدیدی برای سرویسی وجود دارد که برخی از زمینه های سازمانی را در خود جای داده است.

نتیجه همیشه یکسان است: کار بعدی با دسترسی بیشتری نسبت به قبلی شروع می شود.

منبع دوم فشار خود عامل است. ماموران بدون اینکه از مسئول انسانی بپرسند که آیا می توانند به آن دسترسی داشته باشند یا خیر، به دنبال اعتبارنامه های جدید می گردند.

این رفتار نسبت به منبع دستورالعمل ها ناشناس است. یک تزریق سریع مخرب می‌تواند باعث تلاش‌های بیش از حد شود، اما می‌تواند فرضیات اشتباه را در طول یک کار مجاز ایجاد کند.

AWS امضا را بررسی می کند، نه اینکه چه کسی کلید را در دست دارد. هنگامی که یک نماینده یک نمایه مدیر را می گیرد، به نظر می رسد درخواست از طرف توسعه دهنده است.

Token Security هر عاملی را به مالک، هویت و مجوزهای آن نگاشت می‌کند، بنابراین کنترل‌های شما اقدامات خارج از وظیفه تعیین‌شده را مسدود می‌کند و به بقیه اجازه می‌دهد اجرا شوند.

نماینده ها از فراخوانی ابزار برای بازیابی داده ها یا اقدامی استفاده می کنند، بنابراین این جایی است که اجرای آن مهم تر است. همانطور که گفته شد، "تماس های ابزار کنترل" یک قانون بسیار درشت است. اگر این ابزار پوسته ای باشد که بتواند یک SDK را اجرا کند چه؟ همچنین می تواند یک مرورگر با یک جلسه تأیید شده باشد. وقتی ابزار را مجاز می‌کنید، به آنچه پشت آن است نیز اجازه می‌دهید.

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

چیزهای زیادی برای تصمیم گیری مناسب در مورد اعتبار یک اقدام وجود دارد.

در اکثر مهارهای عامل، دستورات محلی، عملیات فایل، مهارت‌ها و تفویض اختیار نیز فراخوانی ابزار هستند. آنها به دلیل جایی که هدایت می کنند اهمیت دارند. به عنوان مثال، خواندن ~/.aws/config به این صورت است که عامل چگونه یک نمایه مدیریت را برای استفاده پیدا می کند.

بنابراین اجرا در فراخوانی ابزار بسیار مهم است، و تصمیم گیری در مورد اقدام داخل آن نیز حیاتی است.

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

محدود کردن ابزارها، مجوزها، حالت‌های تأیید و ادغام‌های مجاز نزدیک به عامل.

کدام مشتریان به تنظیمات احترام می گذارند؟ آیا یک کاربر، پروژه یا عامل می تواند آنها را لغو کند؟ تنظیمات مدل و تلاش می‌توانند تلاش کنند دسترسی را محدود کنند، اما طبیعتا انتخاب‌های رفتاری هستند.

گسترده زمانی که برنامه آن را اجرا می کند. کمی برای تنظیمات رفتاری

کم، به جز حالت های تایید، که بیشترین هزینه را دارند

بررسی یک عملیات پشتیبانی شده قبل از اجرا، با زمینه از جلسه عامل.

آیا کاربر یا عامل می تواند آن را تغییر یا غیرفعال کند؟ آیا ابزارهای جایگزین و عوامل فرعی را پوشش می دهد؟ آیا قبل از اجرا، از جمله در خطاها و وقفه ها، مسدود می شود؟

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

آنها واقعا کدام ترافیک را می بینند: درخواست های مدل، ابزارهای MCP، API های مستقیم یا ترافیک شبکه؟ آیا عامل می تواند از راه دیگری به همان سیستم برسد؟

محدود کردن فایل‌ها، فرآیندها، مسیرهای شبکه و اعتبارنامه‌های موجود برای یک نماینده.

نماینده هنوز در داخل آن محدودیت ها چه کاری می تواند انجام دهد؟ آیا خدمات قابل دسترسی محدود به حساب و عملیات مناسب است یا فقط یک دامنه مجاز؟

متوسط، به عنوان کارهایی که نیاز به دسترسی خارجی دارند شکسته می شوند

کنترل استفاده از عامل محلی از طریق نرم افزار نقطه پایانی یا EDR که قبلا مستقر شده است.

آیا می تواند یک عملیات خاص یا فقط یک فرآیند یا میزبان را متوقف کند؟ داخل کانتینرها یا ماشین های مجازی چه چیزی قابل مشاهده است؟ کدام عوامل میزبان خارج از دسترس آن نشسته اند؟

کاهش اختیارات اعطا شده به یک عامل و اعمال دسترسی به سیستمی که منبع را در اختیار دارد.

آیا اعتبارنامه ها مختص عامل و وظیفه است؟ آیا مدارک دیگری وجود دارد؟ آیا سرویس می تواند عامل را از شخص یا حساب مشترک پشت آن متمایز کند؟

متوسط، زیرا دسترسی محدود وظایف را متوقف می کند و نمایندگان را به دنبال کارهای بیشتر می فرستد

تغییر تنظیمات عامل، حذف مجوزها، لغو اعتبارنامه یا جلسات، و غیرفعال کردن دسترسی به جایی که پلتفرم‌ها آن اقدامات را نشان می‌دهند.

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

این روش ها همپوشانی دارند و مکمل یکدیگر هستند. قلابی که سرویس خط مشی نامیده می‌شود و دروازه‌ای که با نمودار هویت مشورت می‌کند، کار بهتری را انجام می‌دهند، زیرا نقاط اجرایی و تصمیم‌گیری در بهترین مکان‌ها برای آنها مناسب است.

این جدول کاملا کامل نیست و ملاحظات بیشتری برای برخی از این روش ها وجود دارد. برای مثال تنظیمات مدیریت شده را در نظر بگیرید. تنظیمات مدل و تلاش ماهیت رفتاری دارند، اما با برخی مهارها، مجوزها بسیار فراتر از یک گفتن سریع هستند که «لطفا از بین نروید».

به عنوان مثال، در Claude Code، قوانین مجوز توسط خود برنامه اجرا می شود و تنظیمات مدیریت شده می تواند نادیده گرفتن کاربر را محدود کند. در این صورت، کنترل در یک فایل تنظیمات زندگی می‌کند، اما این کار آن را کاهش نمی‌دهد.

با قلاب ها، فرض اصلی کاملا به قرارگیری آنها در زنجیره اجرا بستگی دارد. شما نمی توانید رویدادی را که قبلا اتفاق افتاده است متوقف کنید، و رفتار شکست بر اساس انواع و رویدادها متفاوت است.

دروازه ها پیچیدگی های خاص خود را دارند، زیرا باید تصمیمات مجوز خود را بر اساس آنچه می بینند استوار کنند. به AWS AgentCore نگاه کنید، که چک‌های سیاست را برای ابزارهای متصل نشان می‌دهد. توجه داشته باشید که کدام تماس را می بیند.

جعبه‌های ماسه‌بازی و اعتبارنامه‌های scoped مشکلات مختلفی را حل می‌کنند. جداسازی مناسب می‌تواند قابلیت‌های دسترسی را حذف کند، در حالی که یک اعتبار دامنه، اتفاقاتی را که پس از اعطای دسترسی اتفاق می‌افتد را محدود می‌کند. طراحی احراز هویت جعبه ایمنی Cloudflare را ببینید، که راهی برای افزودن اعتبارنامه‌ها در خارج از جعبه ایمنی نشان می‌دهد، بنابراین عامل نیازی به داشتن راز ندارد. با این حال، عملیات آن همچنان به مجوز نیاز دارد.

یک نماینده پشتیبانی را در نظر بگیرید که از او خواسته می شود موارد باز را خلاصه کند. رابط آن از یک حساب سرویس ساخته شده برای عواملی استفاده می کند که موارد را ویرایش و بسته می کنند. نماینده تصمیم می گیرد که برخی از پرونده ها حل شده به نظر می رسد و سعی می کند آنها را ببندد.

مجددا، این قابلیت همراه با اعتبار است و نماینده در حد اعطای آن است. مکانی که عمل غیرمجاز است، خط مشی فقط خواندنی تایید شده نماینده است.

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

اگر آن عامل در یک محیط میزبانی شده زندگی می کند، یک کنترل نقطه پایانی در لپ تاپ کارمند ممکن است فرصتی برای متوقف کردن عمل نداشته باشد، زیرا همه آن سمت سرور است.

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

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

اگر ترافیک AWS از آنها عبور می کند، تماس های سرپرست را دریافت کنید

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

مهمتر از همه، شما می خواهید که نماینده در چارچوب خط مشی تایید شده خود به کار خود ادامه دهد. فقط خواندنی کامل نیست. بسته به جایی که خروجی می رود، همچنان می تواند داده های حساس را در معرض دید قرار دهد. تجزیه و تحلیل مهار آنتروپیک دلیل آن را توضیح می دهد.

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

هیچ کدام از اینها رایگان نیست. کنترل‌ها معاوضه‌هایی را ایجاد می‌کنند، نیاز به تعمیر و نگهداری دارند و باید حجم فزاینده‌ای از کارهای مبتنی بر هوش مصنوعی را به حساب آورند.

مثال AWS را از ابتدای مقاله در نظر بگیرید. مسدود کردن دستور تحت اللفظی یک شروع است، اما اگر همان درخواست از طریق یک SDK ارسال شود چه؟ با اعتبار متفاوت؟ از طریق تفویض اختیار؟

الزامات امنیتی برای مسدود کردن حذف یکسان است، اما مسیرهای مختلفی برای آن وجود دارد.

سپس مسئله ارزش مطرح می شود، و شما باید آن را به اندازه قابلیت های کنترل در نظر بگیرید. کنترل ها چقدر تاخیر اضافه می کنند؟ هر چند وقت یک‌بار یک نفر نیاز به رفع انسداد مثبت کاذب دارد؟ آیا ریسک را کاهش می دهیم یا مشکلاتی را معرفی می کنیم؟

گزارش SACR ARISE بر مداخله در زمان اجرا، اختیارات تفویض شده و تصمیمات در سطح اقدام متمرکز است. این باید به یک درخواست ملموس، یک خط مشی، و شواهدی مبنی بر اینکه چه اتفاقی در زمانی که عامل آن را امتحان کرد، خلاصه شود.

یک راهنمای کوتاه، بر اساس مکان هایی که عوامل شما اجرا می شوند و آنچه را که در آنجا کنترل می کنید:

نقطه پایانی، تنظیمات عامل، فایل‌های اعتبار محلی

تنظیمات مدیریت شده، به علاوه قلاب هایی که مشتری از آنها پشتیبانی می کند

دروازه ای برای ترافیک Cloud API و اجرای نقطه پایانی برای مشتریانی که نمی توانید پیکربندی کنید

زمان اجرا، خروجی شبکه و هویت حجم کار

اعتبار رابط و تنظیمات سرپرست پلتفرم

پلتفرم از طریق API کنترل می‌کند و یک دروازه ابزار در جلوی کانکتورها، جایی که پلتفرم به آن اجازه می‌دهد

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

این کار را انجام دهید و در موقعیت شروع خوبی هستید.

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

چشم انداز گسترده تر، ایجاد یا اتصال به قابلیت اجرایی مورد نیاز مشتری است. لازم نیست همه چیز را خودمان بسازیم.

نمودار یک عامل را به صاحبش، هویت هایی که مصرف می کند، مجوزهای مرتبط با آن هویت ها و منابعی که می تواند به آن دسترسی داشته باشد، متصل می کند. این نوع زمینه‌ای است که موتورهای سیاست می‌توانند از آن برای تصمیم‌گیری در مورد اینکه یک عامل ممکن است انجام دهد، استفاده کنند، به‌جای اینکه فرض کنیم اعتبار کامل اعتبارنامه مناسب است.

در نسخه‌ی نمایشی گیت‌وی اخیر، ما دقیقا این ایده را نشان دادیم: همان توسعه‌دهنده، همان جلسه، و تماس نماینده توسط سرپرست رد شده و فقط خواندن مجاز است. سایر کنترل ها نیز می توانند دسترسی فقط خواندنی را اعمال کنند.

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

در مورد خطوط پایه چطور؟ به خاطر داشته باشید که رفتار گذشته تنها می تواند به عنوان ورودی استفاده شود، نه خود خط مشی. این واقعیت که یک عامل معمولا فقط داده ها را می خواند ثابت نمی کند که نوشتن ممنوع است. این وظیفه قاعده ای است که عوامل را فقط به خواندن پین می کند. متن از دست رفته یا کهنه نیز نیاز به یک تصمیم صریح دارد، مانند تایم اوت های قلاب.

من یک نماینده می خواهم که بررسی یا خلاصه پشتیبانی را بدون نیاز به تأیید برای هر مرحله تکمیل کند. همچنین می‌خواهم بدانم که یک عمل خارج از آن وظیفه دقیقا کجا متوقف می‌شود. این چیزی است که من از هر روش اجرایی، از جمله امنیت رمز، می خواهم.

اگر در حال حل این مشکلات امنیتی هوش مصنوعی در سازمان خود هستید، ما را بررسی کنید یا یک نسخه نمایشی رزرو کنید.