تأمین سیستم های عامل با نمایندگی معتبر – قسمت اول

با پیشرفت عوامل هوش مصنوعی در استقلال و توانایی ، به ویژه با توسعه مدلهای بزرگ زبان (LLM) ، آنها چالش های جدیدی را در هویت و مدیریت دسترسی (IAM) معرفی می کنند. بر خلاف کاربردهای سنتی با رفتارهای قابل پیش بینی ، عوامل مدرن هوش مصنوعی می توانند از طرف کاربران با حداقل نظارت ، دلیل ، برنامه ریزی ، استفاده از ابزار و دسترسی به منابع را دلیل ، برنامه ریزی ، استفاده کنند. این تغییر در رفتار سؤالات امنیتی قابل توجهی را ایجاد می کند: چگونه اطمینان حاصل کنیم که این عوامل فقط در محدوده مورد نظر خود عمل می کنند؟ چگونه پاسخگویی مناسب را حفظ کنیم؟ چگونه می توانیم از نقض مرزهای اعتماد جلوگیری کنیم؟
این انتقال اساساً مدل های سنتی IAM را که در اطراف برنامه های قابل پیش بینی ساخته شده و کنترل مستقیم کاربر را مختل می کند ، مختل می کند. تکیه بر رویکردهای موجود مانند کلیدهای استاتیک API یا مجوزهای کاربردی ساده برای این عوامل خودمختار مشکل ساز است زیرا درها را به سمت حملات معاون و گیج کننده پیچیده ، افزایش امتیاز و اقدامات غیر قابل ردیابی با پیامدهای بالقوه شدید باز می کند. یک بنیاد جدید مبتنی بر هیئت قابل تأیید برای پیمایش ایمن در آینده در آینده ضروری و نه اختیاری خواهد بود.
مفهوم هیئت معتبر چارچوبی برای پرداختن به این موضوعات فراهم می کند. همانطور که در مقاله تحقیقاتی MIT “هیئت معتبر و عوامل مجاز هوش مصنوعی” بیان شده است ، این رویکرد به کاربران انسانی این امکان را می دهد تا ضمن حفظ زنجیره های واضح از پاسخگویی ، مجوزها و دامنه نمایندگان را به طور ایمن تفویض و محدود کنند. این بنیاد هنگام در نظر گرفتن منظره تهدید گسترده شرح داده شده در سند “AI عامل AI – تهدیدات و کاهش” OWASP بسیار مهم می شود ، که آسیب پذیری های متعدد IAM را در سیستم های عامل مشخص می کند.
در این مقاله ، اولین مورد از پنج مورد در مورد امنیت IAM برای سیستم های عامل ، به بررسی چگونگی اجرای هیئت معتبر با ایجاد زنجیره های قابل تأیید از اقتدار از اصول انسانی به نمایندگان ، ایجاد محدودیت های صریح دامنه و امکان پذیرش در سراسر عملیات خودمختار ، چالش های مهم امنیتی IAM را در استقرار نمایندگان هوش مصنوعی می پردازد.

درک نمایندگان معتبر برای نمایندگان هوش مصنوعی

هیئت معتبر از طریق سه ستون اساسی ، پایه و اساس امن برای آژانس AI ایجاد می کند:

1. احراز هویت هویت یک نهاد را تأیید می کند ، و هر دو کاربر انسانی را که این عمل را آغاز می کند تأیید می کند و اینکه موجودیت متقابل یک عامل خاص هوش مصنوعی با خصوصیات تعریف شده است.
2. صلاحیت اقدامات مجاز و دسترسی به منابع را تعیین می کند ، و اطمینان می دهد که عامل AI به نمایندگی از یک کاربر خاص و معتبر انسانی با مجوزهای صریح و صریح برای دامنه مشخص عمل می کند.
3. قابلیت حسابرسی همه طرفین را قادر می سازد تا بازرسی و تأیید کنند که ادعاها ، اعتبار و ویژگی ها (مربوط به کاربر ، نماینده و خود هیئت) بدون تغییر باقی می مانند و این اقدامات را می توان به منشأ آنها بازگرداند. این سه ستون با هم کار می کنند تا یک چارچوب امنیتی جامع ایجاد کنند که به طور خاص با چالش های منحصر به فرد سیستم های AI عامل سازگار است.

اجرای عملی

به جای ایجاد زیرساخت های کاملاً جدید ، هیئت معتبر پروتکل های مستقر – به ویژه OAuth 2.0 و OpenID Connect – گسترش می یابد تا به نیازهای منحصر به فرد عوامل AI بپردازد. در حالی که از جریانهای آشنا استفاده می کند ، ساختارهای مهم هویت و نمایندگی ویژه عامل را معرفی می کند. اجرای عملی از یک چارچوب مبتنی بر توکن استفاده می کند که اغلب از سه مؤلفه مفهومی تشکیل شده است:

1. شناسه کاربر: یک نشانه اتصال OpenID استاندارد که توسط یک ارائه دهنده OpenID (IDP) صادر شده است ، که نمایانگر ادعاهای هویت معتبر کاربر انسانی است. این از جریان OIDC استاندارد بدون تغییر است.

2. نشان دهنده ID: این نشانه حاوی اطلاعات مربوطه و قابل تأیید در مورد نمونه خاص عامل هوش مصنوعی ، مانند قابلیت ها ، محدودیت ها ، منشأ فروشنده ، پیوندهای مستندات و شناسه های منحصر به فرد است. از نظر مهم ، این یک هویت متمایز و قابل اثبات برای خود عامل ، جدا از کاربر است. این نشانه ممکن است توسط فروشنده نماینده صادر شود ، که در هنگام استقرار در سیستم IAM سازمان ثبت شده است ، یا از سایر اعتبارنامه های قابل اثبات گرفته شده است.
   شرط اصلی این است که به خدمات اجازه می دهد تا با اطمینان از این نماینده و مطالبات اعتماد در مورد خصوصیات آن را شناسایی کنند. مدیریت چرخه حیات و ثبت این هویت های عامل یک جنبه عملیاتی مهم است و چالش هایی مشابه با مدیریت مشتری برنامه سنتی را ارائه می دهد. ایجاد منابع قابل اعتماد برای ID های عامل ، اطمینان از صدور امن آنها ، و رسیدگی به به روزرسانی ها یا احیاء ، ملاحظات اساسی برای اجرای قوی است.

   نیاز مدیریت چرخه عمر پیچیدگی عملیاتی را معرفی می کند. سازمانی که از این نشانه پشتیبانی می کند باید فرآیندهای قوی را برای صدور ، به روزرسانی ، ابطال و چرخش نشانه های عامل Agent-ID ، مشابه اسرار مشتری برنامه ، اما با ابرداده های غنی تر و طول عمر کوتاه تر طراحی کند. سیاست ها باید آنچه را که یک “نماینده قابل اعتماد” را تشکیل می دهد ، تعریف کند ، کدام فروشندگان مجاز هستند و در صورت تغییر وضعیت اعتماد یک عامل یا به خطر انداختن چه اتفاقی می افتد. ادغام با سیستم های هویت بار کاری موجود و زیرساخت های PKI می تواند کمک کند ، اما فرآیندهای اختصاصی برای مدیریت اعتماد AI Agent به عنوان یک مسئولیت جدید IAM ظاهر می شوند.

3. نماینده نمایندگی: این پسوند اصلی است که صریحاً یک عامل خاص هوش مصنوعی (شناسایی شده توسط Agent-ID) را مجاز به عمل به نمایندگی از کاربر خاص (شناسایی شده توسط شناسه کاربر) می کند ، اما فقط برای یک دامنه و مدت زمان خاص ، تأیید شده است. این توکن به عنوان یک پل رمزنگاری اساسی عمل می کند ، حاوی مراجع قابل اثبات (به عنوان مثال ، هش یا شناسه) به ادعاهای شناسه کاربر و ادعاهای توکن عامل ، در کنار دامنه تعریف شده (به عنوان مثال “خوانده شده: تقویم” ، “ارسال: ایمیل”) ، شرایط اعتبار و URL های ممیزی بالقوه. بر خلاف یک نشانه استاندارد دسترسی OAUTH ، که در درجه اول نشانگر اجازه کاربر به برنامه مشتری است که به آن اجازه می دهد به منابع دسترسی پیدا کند ، نشانه نمایندگی صریحاً کاربر ، عامل و دامنه را به یک مصنوع واحد و قابل اثبات متصل می کند. این هیئت صریح و صریح برای کاهش حملات معاون سردرگم و اطمینان از پاسخگویی واضح اساسی است ، زیرا خود نشان می دهد که اثبات قانون ویژه هیئت مدیره است.

این معماری سه گانه مفهومی (مفید برای جدا کردن واضح و واضح هویت و عناصر مجوز متمایز درگیر ، حتی اگر اجرای ممکن است ادعاها را در نشانه های فیزیکی کمتری برای کارآیی ترکیب کند) یک زنجیره اعتماد به نفس و قابل اثبات را از اصل انسانی به اقدامات عامل ایجاد می کند. هر خدمتی که با نماینده در تعامل باشد می تواند این زنجیره را تأیید کند – تأیید هویت کاربر ، هویت و خصوصیات نماینده و مجوزهای تفویض شده خاص تعریف شده در نشانه نمایندگی – قبل از دسترسی.

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

@startuml
title Authenticated Delegation Token Issuance Flow (Simplified View)

actor User as U
participant "AI Agent" as A
participant "Auth & Delegation Server\n(OAuth Provider + Extensions)" as ADS
participant "Resource Server" as RS

U -> A: Request Agent to perform task requiring specific permissions
A -> ADS: Initiate Delegation Flow (indicates required scope, presents Agent ID/Credentials)
ADS -> U: Redirect User for Authentication & Consent\n(Shows User who Agent is and what scope is requested)

U -> ADS: Authenticates (proves identity)
U -> ADS: Grants Consent (approves requested scope for this Agent)

ADS -> ADS: Verify User, Agent ID/Credentials, and Consent
ADS --> A: Issue **Delegation Token** (or derived Access Token representing the delegation)
note right of A: Agent now holds a specific, verifiable token\nrepresenting delegated authority from User.

' Optional: Subsequent Action Phase (Simplified)
A -> RS: Perform Action (Presents Token)
RS -> RS: Verify Token & Enforce Scope\n(Checks token validity, signature, and ensures\n action is within the approved scope for this User/Agent pair\n as defined *by the delegation*)
RS --> A: Action Result (Success/Failure)

@enduml

1. کاربر برای انجام یک کار از یک عامل AI دعوت می کند.
2. نماینده ، با شناسایی خود ، یک جریان شبیه به اوت را آغاز می کند که درخواست دسترسی خاص (به عنوان مثال “اسناد. خواندن”) را از سرور مجوز و نمایندگی درخواست می کند.
3. کاربر تأیید می کند و صریحاً این درخواست هیئت را تأیید می کند ، و به نماینده اجازه می دهد تا آن دامنه خاص را ارائه دهد.
4. نماینده یک نشانه هیئت (یا یک نشانه دسترسی حاصل از آن) دریافت می کند که نماینده این کمک هزینه خاص و متمایز است.
5. نماینده از این توکن برای دسترسی به منابع درخواست شده به نمایندگی از کاربر استفاده می کند ، با سرور منبع تأیید توکن و اجرای دامنه تعبیه شده آن.

توجه داشته باشید که چارچوب نمایندگی معتبر کامل ، به ویژه کاربر ، نماینده و نمایندگان مشخصات/ادعاهای مشخص ، لایه های امنیتی مهم عامل مهم را اضافه می کند که بعداً در این سری بحث خواهیم کرد. صرف نظر از این ، حتی این گسترش مفهومی OAuth چندین مزیت ارائه می دهد:

• امنیت مبتنی بر توکن: مأمورین نشانه های محدودی را دریافت می کنند که به طور خاص نمایندگی را نمایندگی می کنند و نه اینکه اعتبارنامه های کاربر خام را اداره کنند.
• رضایت صریح: کاربران به طور فعال هیئت مجوزهای خاص را به یک عامل خاص تأیید می کنند.
• کنترل ریز دانه: مجوزها را می توان به منابع و اقدامات خاص در کمک هزینه نمایندگی منتقل کرد.
• احیاء: دسترسی به تفویض شده را می توان با ابطال نشانه نمایندگی یا جلسه زیرین خاتمه داد. از آنجا که نمایندگی معتبر براساس اصل بر اساس استانداردهای تعیین شده ، یک مسیر عملی برای تأمین امنیت عوامل هوش مصنوعی در اکوسیستم های IAM موجود فراهم می کند.

منظره تهدید AI عامل از طریق لنز IAM

ابتکار امنیت عامل OWASP (ASI) تهدیدهای بی شماری را برای سیستم های هوش مصنوعی عامل که همه سازمان ها باید به آن بپردازند ، شناسایی کرده است. درک این تهدیدها برای اجرای اقدامات امنیتی مؤثر ضروری است.

آسیب پذیری های معاون سردرگمی: یک خطر اصلی IAM

مهمترین تهدید IAM در سیستم های عامل ، آسیب پذیری معاون سردرگم (مربوط به OWASP ASI T3 – به سازش امتیاز و T7 – ​​رفتارهای نادرست و فریبنده) است. این اتفاق می افتد “هنگامی که یک عامل AI (” معاون “) از کاربر امتیازات بالاتری دارد اما در انجام اقدامات غیرمجاز از طرف کاربران فریب می یابد”. این آسیب پذیری هنگامی تحقق می یابد که یک عامل فاقد انزوا از امتیاز مناسب باشد و نمی تواند بین درخواست های قانونی کاربر و دستورالعمل های تزریقی مخالف تمایز قائل شود.

به عنوان مثال ، اگر یک عامل هوش مصنوعی به عملیات پایگاه داده با امتیازات بالا دسترسی داشته باشد اما به درستی ورودی کاربر را تأیید نمی کند ، یک مهاجم می تواند آن را در اجرای نمایش داده های با ارزش بالا که خود مهاجم به طور مستقیم نمی تواند انجام دهد ، دستکاری کند. سند OWASP تأکید می کند که “برای کاهش این امر ، برای کاهش امتیازات عامل در هنگام کار به نمایندگی از کاربر ضروری است.”

مدیریت هویت غیر انسانی

مدیریت هویت های غیر انسانی (NHIS)-مانند حساب های ماشین ، هویت خدمات و کلیدهای API مبتنی بر عامل-یک چالش مهم دیگر را ارائه می دهد. بر خلاف جریان احراز هویت کاربر سنتی ، NHIS “ممکن است فاقد نظارت مبتنی بر جلسه باشد ، در صورت عدم مدیریت با دقت ، خطر سوء استفاده از امتیاز یا سوء استفاده از نشانه ها را افزایش می دهد” (به خطرات مانند T3 – Privilege Arcromise و T9 – جعل هویت کمک می کند).

نمایندگانی که تحت این هویت های غیر انسانی فعالیت می کنند خطرات امنیتی بی سابقه ای را ایجاد می کنند زیرا:

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

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

• ارائه دهنده هویت (IDP) یا زیرساخت های OAuth را برای صدور نشانه های نمایندگی که هم هویت کاربر و هم نماینده را به هم متصل می کنند ، گسترش دهید.
• ایجاد یا ادغام رجیستری هویت های نماینده AI معتبر ، گرفتن ابرداده مانند قابلیت ها ، استحکام ، سطح اعتماد و مالک.
• سیاست هایی را برای تأیید هویت و ابطال هویت عامل ایجاد کنید (به عنوان مثال ، هنگامی که یک فروشنده در خارج از کشور قرار دارد یا یک عامل به خطر می افتد).
• مکانیسم های امن برای تأیید اعتبار عامل (به عنوان مثال ، MTL ، ادعاهای امضا شده یا اعتبار قابل تأیید) را در طی جریان نمایندگی تعریف کنید.
• سرورهای منابع را برای تجزیه و اجرای اسکوپ های نمایندگی از نشانه ها به روز کنید – از جمله محدودیت هایی مانند هدف ، زمینه یا زمان.

ابزارها سوء استفاده و آژانس بیش از حد

یکی از ویژگی های تعیین کننده عوامل هوش مصنوعی مدرن ، توانایی آنها در استفاده از ابزارها و API ها برای انجام وظایف است. با این حال ، این توانایی خطرات امنیتی قابل توجهی ایجاد می کند وقتی که نمایندگان “استقلال نامشخص یا در استراتژی های برنامه ریزی پیشرفته یا معماری های چند عامل” (مربوط به OWASP ASI T2 – سوء استفاده از ابزار و LLM06 – آژانس بیش از حد).

سند OWASP خاطرنشان می کند که “سوء استفاده از ابزار مربوط به آژانس بیش از حد LLM Top 10 است اما پیچیدگی های جدیدی را معرفی می کند ،” به ویژه در زمینه تولید کد که در آن نمایندگان ممکن است کد با آسیب پذیری های امنیتی یا حتی قابلیت های مخرب ایجاد کنند.

مسمومیت با حافظه و نقض زمینه

یکی دیگر از تهدیدات منحصر به فرد در سیستم های عامل ، مسمومیت با حافظه است (OWASP ASI T1 – مسمومیت با حافظه) ، که در آن وضعیت داخلی یا حافظه خارجی عامل با اطلاعات گمراه کننده یا مخرب خراب می شود. این امر به ویژه در معماری های چند عامل “جایی که نمایندگان از مکالمات یکدیگر یاد می گیرند” نگران کننده است.

مسمومیت با حافظه می تواند منجر به نقض متن شود ، جایی که اطلاعات از یک زمینه (به عنوان مثال ، داده های سازمانی) به طور نامناسب بر اقدامات در یک زمینه دیگر تأثیر می گذارد (به عنوان مثال ، وظایف شخصی) ، که به طور بالقوه منجر به نشت داده ها یا دسترسی غیرمجاز می شود.

افزایش امتیاز

علاوه بر این ، پتانسیل تشدید امتیاز (OWASP ASI T3 – Privilege به خطر می افتد) یک آسیب پذیری بحرانی را نشان می دهد ، متمایز از سوء استفاده از ابزار ساده در مرزهای مجاز. این تهدید به طور خاص مربوط به نمایندگان به دست آوردن مجوز فراتر از نقش مورد نظر یا سطح مجوز اولیه است. همانطور که در مدل تهدید عامل OWASP برجسته شده است ، این می تواند از طریق بهره برداری از نقش های سوء مدیریت ، تنظیمات بیش از حد مجاز ، وراثت اجازه پویا یا دسترسی به ابزار زنجیره ای به روش های غیر منتظره رخ دهد. بر خلاف سیستم های سنتی که در آن مسیرهای تشدید ممکن است قابل پیش بینی تر باشد ، استقلال عامل و توانایی آنها در تعامل در چندین سرویس ، مسیرهای جدیدی را برای تشدید دسترسی اساسی (به عنوان مثال ، خواندن یک پرونده) در کنترل اداری یا عملیات بین سیستم های غیرمجاز ، سوء استفاده از مشکل در اجرای مرزهای سخت و پویا ایجاد می کند.

جعل هویت

با تکیه بر چالش های مدیریت NHI ، جعل هویت و جعل هویت (OWASP ASI T9 – جعل هویت و جعل هویت) به عنوان یکی دیگر از تهدیدات اساسی IAM در ابعاد منحصر به فرد ظاهر می شود. مهاجمان ممکن است از مکانیسم های احراز هویت یا اعتبارنامه به خطر بیفتند (انسانی یا غیر انسانی) برای جعل هویت نمایندگان قانونی هوش مصنوعی ، کاربران انسانی یا حتی خدمات خارجی. ASI OWASP این خطر را برجسته می کند ، و خاطرنشان می کند که مهاجمان می توانند اقدامات غیرمجاز را تحت هویت کاذب فعال کنند. این امر به ویژه در محیط های چند عامل که فرضیات اعتماد شیوع دارند ، خطرناک است. یک نهاد مخرب می تواند به عنوان یک عامل قابل اعتماد برای رهگیری ارتباطات ، دستکاری سایر عوامل ، داده های تبعید یا انجام اقدامات غیرمجاز ، با دور زدن کنترل های امنیتی با عملکرد تحت یک هویت دزدیده شده یا جعلی انجام شود.

چگونه هیئت معتبر امنیت عامل را بهبود می بخشد

نمایندگان معتبر به طور مستقیم به هر یک از تهدیدهای خاص IAM که در مدل تهدید AI ATASP ATIC شناسایی شده اند ، می پردازد. جداول زیر نشان می دهد که چگونه مکانیسم های خاص در چارچوب نمایندگی معتبر با این خطرات امنیتی مقابله می کنند.

مطالعه موردی اجرای: دستیار مالی

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

@startuml
title Financial Assistant Agent - Authenticated Delegation Flow (with Explicit Tokens)

actor User
participant "Financial AI Agent" as Agent
participant "Auth & Delegation Server\n(e.g., Bank's IDP)" as ADS
participant "Financial Service API\n(e.g., Bank's Resource API)" as FinAPI

autonumber "[0]"

== 1. Delegation Setup Phase ==

User -> ADS: Initiates Login / Task Requiring Delegation
ADS -> User: Authentication Prompt
User -> ADS: Authenticates (e.g., username/password, MFA)
ADS -> ADS: Validate User Credentials
ADS --> User: Authentication Success \n(Conceptually issues/validates **User ID Token**)
note right of ADS: User authenticated;\nUser ID Token claims available

User -> Agent: "Transfer $50 to savings"
Agent -> ADS: Initiate Delegation Request\n(Presents **Agent ID Token** or Client Credentials,\nRequests Scope: transfer.internal, accounts.read)
note left of Agent: Agent identifies itself using its\npre-established Agent ID Token\nor other verifiable credentials.

ADS -> User: Redirect/Prompt for Consent\n(Shows: User, Agent Identity [from Agent ID],\nRequested Scope)
User -> ADS: Grants Consent for Requested Scope

ADS -> ADS: **Create Delegation Token**\n(Binds User ID Ref, Agent ID Ref, Scope,\nConstraints [e.g., MaxTransfer=$1000], Validity)
note right of ADS: **Delegation Token** created, linking\nUser, Agent, and specific permissions.

ADS --> Agent: Issue **Delegation Token**
note right of Agent: Agent now holds the specific Delegation Token\nauthorizing it for the consented scope.

== 2. Delegated Action Phase ==

Agent -> FinAPI: POST /transfers (Amount: $50, From: Checking, To: Savings)\n**Authorization: Bearer [DelegationToken]**
note left of Agent: Agent uses the **Delegation Token**\nto authorize the API call.

FinAPI -> FinAPI: **Verify Delegation Token, Identity Linkage & Scope**
note right of FinAPI
  1. Check Delegation Token Signature & Validity
  2. Extract/Verify User & Agent References within Token
  3. **Confirm Action (POST /transfers) matches Scope ([transfer.internal])**
  4. **Confirm Amount ($50) <= Constraint ($1000) from Token**
end note

alt Verification Successful
    FinAPI -> FinAPI: Execute Internal Transfer
    FinAPI --> Agent: Success (Transfer ID: 123)
    Agent --> User: "Successfully transferred $50 to savings."
else Verification Failed (e.g., Scope Violation, Constraint Breach, Invalid Token)
    FinAPI --> Agent: Error 403: Forbidden / Insufficient Scope
    Agent --> User: "Sorry, I couldn't complete the transfer due to permission issues."
end

@enduml

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

فاز 1: مرحله تنظیم هیئت

1. (مراحل 0-1): احراز هویت کاربر: کاربر ورود به سیستم یا وظیفه ای را که به مجوزهای تفویض شده با سرور تأیید اعتبار و نمایندگی (ADS) نیاز دارد ، به طور معمول ارائه دهنده هویت بانک خود آغاز می کند. پس از احراز هویت موفقیت آمیز (به عنوان مثال ، رمز عبور ، MFA) ، تبلیغات از نظر مفهومی تأیید می شوند یا به ادعاهای موجود در آن دسترسی دارند شناسه کاربر، تأیید هویت کاربر.

2. (مراحل 2-3): شروع کار: کاربر به عامل AI دستور می دهد یک کار را انجام دهد (به عنوان مثال “انتقال 50 دلار”).

3. (مرحله 4): درخواست نمایندگی: عامل برای شروع جریان هیئت با تبلیغات تماس می گیرد. این خود را با استفاده از آن مشخص می کند نشان شناسه عامل (یا اعتبار قابل تأیید معادل آن) و دامنه (مجوزهایی مانند Transfer.internal ، Accounts.Read) مورد نیاز برای کار را مشخص می کند.

4. (مراحل 5-6): رضایت کاربر: ADS کاربر را برای رضایت صریح سوق می دهد ، به وضوح نشان می دهد که کدام نماینده درخواست دسترسی را می دهد و مجوزهای خاص (دامنه) درخواست می شود. بررسی کاربر و رضایت کمک های مالی.

5. (مرحله 7): ایجاد توکن نمایندگی: تبلیغات ، با تأیید کاربر (از طریق ادعاهای توکن شناسه کاربر) ، عامل (از طریق ID Agent ID) و رضایت کاربر دریافت کرده است ، نماینده نمایندگیبشر این نشانه مهم رمزنگاری به صورت رمزنگاری به هویت کاربر ، هویت نماینده ، دامنه تأیید شده و هرگونه محدودیت اضافی (مانند محدودیت های معامله یا دوره اعتبار) پیوند می زند.

6. (مرحله 8): صدور توکن: تبلیغات تازه ایجاد شده را صادر می کند نماینده نمایندگی به عامل هوش مصنوعی. نماینده اکنون دارای یک اعتبار خاص و قابل اثبات است که به آن اجازه می دهد از طرف کاربر در مرزهای رضایت یافته عمل کند.

فاز 2: مرحله عمل واگذار شده

1. (مرحله 9): تماس API با نشانه نمایندگی: نماینده تماس API مورد نیاز را به API خدمات مالی (به عنوان مثال ، شروع انتقال 50 دلار) انجام می دهد. این ارائه می دهد نماینده نمایندگی در عنوان مجوز.

2. (مرحله 10): تأیید توسط سرور منبع: API خدمات مالی درخواست را دریافت می کند و تأیید دقیق در مورد نماینده نمایندگی:

   • امضای و اعتبار توکن را بررسی می کند (به عنوان مثال ، انقضا).
   • استخراج و تأیید هویت کاربر و عامل مرتبط در درون نشانه.
   • از نظر مهم ، تأیید می کند که عمل درخواست شده (پست /نقل و انتقالات) توسط دامنه تعریف شده در توکن مجاز است (به عنوان مثال ، transfer.internal).
   • علاوه بر این ، تأیید می کند که پارامترهای درخواست (مبلغ: 50 دلار) به هرگونه محدودیت تعریف شده در نشانه (به عنوان مثال ، <= 1000 دلار) رعایت کنید.

3. (مراحل 11-15): اجرای عمل (مشروط):

   • اگر تأیید موفقیت داشته باشد: API خدمات مالی اقدام درخواست شده (انتقال) را اجرا می کند. این یک پاسخ موفقیت به نماینده را برمی گرداند ، که سپس به کاربر اطلاع می دهد.
   • در صورت عدم موفقیت تأیید (به دلیل نشانه نامعتبر ، دامنه کافی یا نقض محدودیت): API خدمات مالی درخواست را رد می کند (به عنوان مثال ، با یک خطای ممنوعه 403). این یک پاسخ خطا به نماینده را برمی گرداند ، که سپس به کاربر در مورد خرابی اطلاع می دهد.

این جریان نشان می دهد که چگونه نماینده نمایندگی به عنوان عنصر اصلی عمل می کند و به نماینده این امکان را می دهد تا اقدامات را بر اساس هویت کاربر تأیید شده و رضایت صریح انجام دهد ، در حالی که به سرور منبع (API مالی) اجازه می دهد تا مرزهای تفویض شده را به شدت اجرا کند.

در اینجا نحوه تفاوت وضعیت امنیتی با و بدون هیئت معتبر تفاوت دارد:

نتیجه گیری: ضرورت هیئت معتبر

عوامل هوش مصنوعی به طور فزاینده ای در سیستم های بحرانی ادغام می شوند. نمایندگان معتبر در حال ظهور یک بنیاد امنیتی اساسی است که به چالش های اصلی IAM مشخص شده در مدل تهدید عامل OWASP می پردازد-از جمله آسیب پذیری های معاونان سردرگم ، مدیریت هویت غیر انسانی ، سوء استفاده از ابزارها و مسمومیت با حافظه. این چارچوب سازمانها را قادر می سازد تا ضمن حفظ مرزهای امنیتی مناسب و پاسخگویی ، با خیال راحت عوامل هوش مصنوعی را مستقر کنند.

مفهوم نمایندگان معتبر با گسترش استانداردهای موجود مانند OAuth 2.0 و OpenID با مکانیسم های خاص عامل ، نیاز اساسی در امنیت عامل را برآورده می کند. این زنجیرهای قابل تأیید از اقتدار از مدیران انسانی به عوامل هوش مصنوعی ، با محدودیت های صریح دامنه و اقدامات پاسخگویی که مستقیماً با تهدیدهای امنیتی منحصر به فرد این سیستم ها روبرو هستند ، ایجاد می کند.

برای سازمانهایی که نمایندگان هوش مصنوعی را توسعه داده یا به کار می گیرند ، اجرای هیئت معتبر باید به جای یک تقویت اختیاری ، یک الزام امنیتی بنیادی در نظر گرفته شود. همانطور که OWASP ASI خاطرنشان می کند ، “چالش های امنیتی IAM” از جمله “نقض مرزهای اعتماد در نظر گرفته شده” برخی از مهمترین خطرات موجود در محیط های عامل را نشان می دهد. هیئت معتبر یک رویکرد جامع و مبتنی بر استانداردها برای پرداختن به این چالش ها ارائه می دهد. در حالی که هویت بار کاری قوی (بعداً در این سری تحت پوشش قرار می گیرد) برای ایجاد هویت قابل اثبات برای عامل ضروری است ، اما منتقل نمی شود سازمان بهداشت جهانی یک اقدام خاص مجاز ، چرا، یا تحت چه دامنهبشر هویت بار کار به تنهایی فاقد پیوند لازم بین یک کاربر خاص انسانی ، نماینده ای است که از طرف آنها عمل می کند ، و مجوزهای ریز و درشت و زمان که برای یک کار خاص اعمال می شود. نمایندگان معتبر این شکاف مهم را با اتصال رمزنگاری هر سه به یک زنجیره اعتماد قابل اثبات پر می کند. به طور مشابه ، در حالی که امنیت قوی API بسیار مهم است ، فاقد مکانیسم اتصال اقدامات عامل به کاربر اصلی نمایندگی و دامنه رضایت یافته آنها است. هیئت معتبر این پیوند مهم از دست رفته را فراهم می کند.

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

منابع

• هیئت معتبر South ، T. ، Marro ، S. ، Hardjono ، T. ، et al. “هیئت معتبر و نمایندگان مجاز AI”.

• OWASP ASI OWASP ابتکار امنیت عامل. “عامل AI – تهدیدها و کاهش” ، نسخه 1.0.