امنیت و انطباق

حاکمیت، امنیت و ممیزی ایجنت هوش مصنوعی

در بیشتر سازمان‌ها، چیزی که پروژه‌ی هوش مصنوعی را متوقف می‌کند مدل نیست — تیم امنیت است. و معمولاً حق دارد. این صفحه دقیقاً همان سؤال‌هایی را جواب می‌دهد که در جلسه‌ی امنیت پرسیده می‌شود.

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

چرا حساب سرویس همه‌کاره خطرناک‌ترین تصمیم است

رایج‌ترین الگو در پروژه‌های ایجنت این است که ایجنت با یک حساب کاربری اختصاصی به سامانه‌ها وصل شود که به همه‌چیز دسترسی دارد. این ساده‌ترین راه راه‌اندازی است و چهار پیامد دارد که هر چهار تا بعداً ظاهر می‌شوند.

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

جایگزین: توکن موقت و محدود برای هر فراخوانی

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

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

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

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

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

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

سیاست داده — تصمیم سازمان، نه تصمیم ایجنت

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

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

🔴 قاعده‌ای که مذاکره‌پذیر نیست: اگر مدل محلی در دسترس نباشد، کار محرمانه «شکست می‌خورد» و به مدل بیرونی منتقل نمی‌شود. سیستمی که تحت فشار محرمانگی را رها می‌کند، بدتر از سیستمی است که اصلاً ادعای محرمانگی ندارد.

رکورد ممیزی — چه چیزی باید در آن باشد

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

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

فیلدهای حساس در رکورد فقط به شکل hash نگهداری می‌شوند، نه متن خام.

ایجنت بدون تغییر کد هم خراب می‌شود

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

در زمان پذیرش ایجنت
در هر انتشار نسخه‌ی جدید
به‌صورت دوره‌ای و خودکار
روی هر پروفایل مدلی که آن استقرار استفاده می‌کند

افت کیفیت، هشدار به ناشر می‌دهد و در کاتالوگ علامت می‌خورد.

پرسش‌های متداول

چطور به بازرس ثابت کنیم داده‌ی محرمانه بیرون نرفته؟

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

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

اگر ایجنت کار اشتباهی انجام دهد چه؟

کارهای اثرگذار قبل از اجرا به کاربر نشان داده می‌شوند و هیچ عمل نوشتنی بدون تأیید انسان اجرا نمی‌شود.

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

تأیید انسانی را می‌شود برای سرعت غیرفعال کرد؟

برای کارهای نوشتنی خیر — ناشر متن تأیید را می‌نویسد ولی نمی‌تواند خود مرحله را حذف کند.

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

با سامانه‌های قدیمی که استاندارد هویت مدرن ندارند چه می‌کنید؟

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

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

ادامه‌ی مطلب

جلسه‌ی امنیت را زودتر بگذارید

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

گفتگو با تیم فنی

آرتین‌مگ

بیشتر بخوانید

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

امنیت و ممیزی در AgentsHub — چهار اصل و ردپای ممیزی کامل هر اجرای ایجنت

چت بات

امنیت و ممیزی در AgentsHub: چطور هر اجرای ایجنت قابل ردیابی می‌ماند

چرا امنیت ایجنت‌های هوش مصنوعی با امنیت نرم‌افزار سنتی فرق دارد؟ چهار اصل امنیتی AgentsHub — هویت جعل‌نشدنی، تأیید انسانی، کنتور مستقل، و عدم امتیاز ویژه.

2026-08-19 · 4 دقیقه · artinmag.ir ↗