بینش‌های صنعت

لایه مجوز: ایمن‌سازی عامل‌های هوش مصنوعی ابزارمحور

تیم ژرف ای‌آی

•۲۷ اردیبهشت ۱۴۰۵•به‌روزرسانی ۸ مرداد ۱۴۰۵•۱۱ دقیقه مطالعه

لایه مجوز: ایمن‌سازی عامل‌های هوش مصنوعی ابزارمحور

هوش مصنوعی ابزارمحور پرسش امنیت را از «آیا مدل محتوای زیان‌آور می‌گوید؟» به «آیا این زنجیره هویت می‌تواند اقدام غیرمجاز انجام دهد؟» تغییر می‌دهد. لایه مجوز امن باید انسان، workload، نمونه عامل، سرویس ابزار، منبع هدف و اختیار واگذارشده را بشناسد؛ در لحظه اقدام سیاست را ارزیابی کند؛ باریک‌ترین credential لازم را صادر کند؛ و برای ابطال و تحقیق شاهد نگه دارد.

پرامپت کنترل دسترسی نیست. system message با مضمون «داده تولید را هرگز حذف نکن» شاید خطای تصادفی را کم کند، اما جای deny در ابزار یا منبع را نمی‌گیرد. حداقل دسترسی باید در برابر تزریق پرامپت، خطای مدل، replay، connector مخرب و سرویس پایین‌دستی آلوده باقی بماند.

زنجیره کامل هویت و اختیار را رسم کنید

یک فراخوانی ابزار چند principal دارد:

انسان یا فرایند کسب‌وکار درخواست‌کننده؛
برنامه میزبان و نشست احرازشده؛
نمونه عامل یا workflow؛
ارائه‌دهنده مدل که اقدام را پیشنهاد می‌دهد، اما نباید credential تولید را مالک باشد؛
دروازه ابزار یا سرور MCP؛
هویت سرویس پایین‌دستی؛
منبع و tenant هدف.

ثبت کنید کدام principal از طرف کدام principal دیگر عمل می‌کند. همه درخواست‌ها را پشت یک service account مدیر پنهان نکنید. credential مشترک، سیاست کاربرمحور، ابطال یک عامل و توضیح مسئولیت را ناممکن می‌کند.

مقاله NCCoE در فوریه ۲۰۲۶ درباره هویت و مجوز عامل نرم‌افزاری و هوش مصنوعی یک پیش‌نویس اولیه عمومی است، نه استاندارد نهایی NIST. این سند پرسش‌های جاری شناسایی، مجوز، audit، non-repudiation و تزریق پرامپت را مطرح می‌کند. از آن برای برنامه‌ریزی استفاده کنید، نه ادعای انطباق. راهنمای هویت و مجوز عامل الگوی پیاده‌سازی را بازتر شرح می‌دهد.

اقدام، منبع و زمینه را با هم مجاز کنید

نقش‌های کلی مانند agent-user یا admin کافی نیستند. تصمیم باید این عوامل را ترکیب کند:

caller، subject واگذارشده، tenant و workload؛
ابزار، operation و منبع دقیق؛
محدودیت مبلغ، ردیف، repository یا گیرنده؛
محیط، زمان، posture دستگاه یا workload و مسیر شبکه؛
طبقه داده و هدف استفاده؛
state گردش‌کار، شاهد، امتیاز ریسک و تأیید؛
نرخ، بودجه تجمعی و علامت anomaly.

RBAC برای eligibility پایه مفید است. قاعده attribute یا relationship آن را به مشتری، پروژه، رکورد یا منطقه واگذارشده محدود می‌کند. رابطه‌ای مثل «مدیر حساب مشتری ۴۲» باید از سامانه معتبر حل شود، نه استنباط مدل.

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

ابزار گسترده را به قابلیت باریک تقسیم کنید

طراحی ابزار کیفیت permission را تعیین می‌کند. manage_customer(action, payload) را با قابلیت‌های جدا مثل customer.read، customer.update_contact_draft، customer.commit_contact و customer.export جایگزین کنید. draft را از commit، تغییر داخلی را از پیام خارجی و update افزایشی را از حذف جدا کنید.

کنترل‌ها در خود ابزار باشند:

field و destination allowlist؛
فیلتر ردیف و tenant؛
سقف مبلغ و batch؛
محدودیت path و query؛
encoding امن خروجی؛
timeout، rate limit و concurrency؛
کلید idempotency برای تغییر؛
verification read پس از commit.

نام و توضیح ابزار metadata نامطمئن است. پیش از تأیید، مالک سرور، بسته، شِما، مقصد شبکه و رفتار مشاهده‌شده را بررسی کنید. با گسترش شِما، دامنه تازه یا تبدیل عملیات خواندنی به تغییردهنده، بازبینی دوباره لازم است.

credential کوتاه‌عمر، محدود و بسته به audience صادر کنید

secret ماندگار تولید را وارد context مدل نکنید. میزبان یا broker پس از تصمیم سیاست، credential کوتاه‌عمر بگیرد و فقط به executor بدهد. آن را به منبع، operation، tenant و زمان لازم محدود کند.

برای MCP دوردست، مشخصات مجوز MCP نسخه 2026-07-28 شناسایی resource و بررسی توکن در سرور را لازم می‌داند. RFC 8707 برای Resource Indicators توضیح می‌دهد چگونه اعلام مقصد به authorization server اجازه می‌دهد توکن را به audience محدود کند. توکن سرور CRM نباید در سرور مالی پذیرفته شود.

بهترین رویه امنیتی OAuth 2.0 در RFC 9700 محدودکردن privilege و دفاع قوی‌تر برابر replay را توصیه می‌کند. در ریسک مناسب، DPoP در RFC 9449 توکن OAuth را به کلید sender می‌بندد تا داشتن bearer لو‌رفته به‌تنهایی کافی نباشد. اگر client و کلید هر دو compromise شوند، DPoP درمان نیست؛ لایه دفاعی است.

عبور توکن و اختیار مبهم را ممنوع کنید

سرور MCP یا proxy ابزار نباید توکنی را که برای سرویس دیگری صادر شده بپذیرد و پایین‌دست بفرستد. راهنمای امنیت MCP token passthrough را anti-pattern می‌داند. این کار مرز audience را می‌شکند، کنترل محلی را دور می‌زند، لاگ را مبهم و سرور را confused deputy می‌کند.

دو رابطه مجوز بسازید:

کلاینت به سرور ابزار، با توکن مخصوص سرور؛
سرور ابزار به API مقصد، با توکن جدا مخصوص API.

سرور subject، audience، scope، expiry، issuer و سیاست توکن ورودی را بررسی کند. سپس credential پایین‌دستی مستقل بگیرد و در صورت پشتیبانی پروتکل، delegation را حفظ کند. گزارش باید انسان آغازکننده، سرور ابزار و principal پایین‌دستی را جدا نشان دهد.

در OAuth proxy با client ID مشترک بالادستی، برای هر client رضایت جدا لازم است. redirect URI دقیق تطبیق، state به درخواست بسته و consent cookie قبلی نباید client مهاجم را بی‌صدا تأیید کند.

تأیید را مشخص، آگاهانه و منقضی‌شونده کنید

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

به تأییدکننده نشان دهید:

کاربر آغازکننده و سازمان نمایندگی‌شده؛
ابزار، هدف و اقدام دقیق؛
آرگومان redactشده اما تصمیم‌ساز؛
شاهد منبع و عدم قطعیت؛
گیرنده بیرونی، مبلغ یا تعداد رکورد؛
برگشت‌پذیری و روش جبران؛
permission و مدت درخواست‌شده؛
علت escalation سیاست.

تصمیم را به digest درخواست canonical، approver، نسخه policy و expiry ببندید. تغییر مبلغ یا گیرنده تأیید را باطل می‌کند. اقدام پرریسک می‌تواند step-up authentication، separation of duties یا two-person control بخواهد. طراحی تأیید انسانی روش جلوگیری از fatigue و تأیید صوری را توضیح می‌دهد.

Zero Trust را به ابزار داخلی هم اعمال کنید

معماری Zero Trust در NIST SP 800-207 می‌گوید شبکه یا مالکیت نباید اعتماد ضمنی بسازد و حفاظت باید منبع‌محور باشد. عامل هنگام تماس با ابزار داخلی نیز باید احراز و مجاز شود و زمینه principal و resource دائماً ارزیابی گردد.

سرور MCP محلی حساس است، چون شاید با privilege فایل و فرایند کاربر میزبان اجرا شود. sandbox، grant صریح پوشه، egress policy، فیلتر متغیر محیطی، اعتبارسنجی بسته و صفحه رضایت با فرمان کامل لازم است. برای یک کلاینت محلی stdio بهتر است؛ endpoint HTTP محلی باید احراز شود و از دسترسی فرایندها و حمله مرورگر حفاظت گردد.

fetch URL در سرور نیز Zero Trust می‌خواهد. metadata OAuth و URL ابزار را با parser بالغ بررسی کنید؛ مقصد private، loopback، link-local و cloud metadata را جز در نیاز صریح ببندید؛ redirectها را اعتبارسنجی و خروجی شبکه را از policy عبور دهید.

هر ورودی را اعتبارسنجی و به هر خروجی بی‌اعتماد باشید

شِما لازم است، اما کافی نیست. invariant کسب‌وکار را بعد از parse اجرا کنید: مبلغ مثبت شاید بالاتر از سقف caller باشد؛ URL معتبر شاید به admin داخلی برود؛ SQL صحیح شاید جدول ممنوع را بخواند.

پیش از policy ورودی را normalize کنید تا encoding متفاوت rule را دور نزند. عمق object، طول رشته و آرایه، هزینه regex، زمان query، اندازه فایل، نسبت decompression و حجم پاسخ سقف داشته باشند. خروجی ابزار پیش از ورود به context مدل sanitize شود. داده برگشتی از instruction جدا و نتیجه ابزار هرگز اجازه تغییر system policy نداشته باشد.

ده ریسک برتر برنامه‌های Agentic در OWASP برای ۲۰۲۶ taxonomy جاری برای ربایش هدف، tool misuse، اختیار بیش‌ازحد، memory poisoning، اجرای کد، خرابی آبشاری و trace ناقص می‌دهد. این دسته‌ها را به آزمون خصمانه زنجیره تبدیل کنید؛ ارجاع به OWASP به‌تنهایی امنیت نیست.

تغییر را idempotent و بودجه را تجمعی کنید

permission در هر call ممکن است باریک باشد ولی در مجموع خطرناک شود. هزینه، تعداد رکورد، پیام، export و call را برای workflow، کاربر و بازه زمان محدود کنید. عامل‌های موازی باید از بودجه مرکزی مشترک مصرف کنند.

call تغییردهنده به کلید idempotency بسته به نیت کسب‌وکار و هش درخواست نیاز دارد. اگر پاسخ بعد از commit گم شد، executor نتیجه قبلی را query کند، نه اینکه اقدام را تکرار کند. همان کلید با آرگومان متفاوت رد شود. درخواست مدل برای retry نباید بودجه را دور بزند.

rate limit باید شکل رفتار را ببیند: گیرنده تازه، scan گسترده، شناسه پشت‌سرهم، حجم ناگهانی شب، رد مکرر و probe میان tenantها. با تغییر ریسک، policy بتواند از اجرای خودکار به approval یا deny تغییر کند.

برای ابطال، تحقیق و اثبات لاگ بسازید

رکورد audit باید نیت را به نتیجه وصل کند:

شناسه workflow و correlation؛
principal انسان، workload، agent instance، سرور ابزار و پایین‌دست؛
subject واگذارشده و tenant؛
نسخه ابزار و شِما؛
نسخه policy، تصمیم، دلیل و attribute؛
artifact تأیید و قدرت authentication؛
issuer، audience، scope و شناسه توکن، نه secret؛
هش درخواست و کلید idempotency؛
آرگومان redactشده، نتیجه، latency، retry و verification؛
compensation، correction و state نهایی.

لاگ از دستکاری و دسترسی گسترده محافظت شود. شناسه حساس tokenize، شاهد رمز و credential و متن کامل private prompt از telemetry عادی حذف شوند. retention بر اساس هدف باشد. trace غیرقابل جست‌وجو هنگام incident ارزش عملی ندارد.

برنامه استانداردهای عامل هوش مصنوعی NIST روی authentication و زیرساخت هویت عامل و evaluation امنیتی کار می‌کند. مدل تمیز هویت و شاهد، پذیرش کنترل interoperable آینده را آسان می‌کند.

ابطال و rollback را پیش از انتشار بسازید

ابطال چند سطح دارد:

پایان grant یک کاربر یا نمونه عامل؛
revoke توکن، client، certificate یا کلید امضا؛
غیرفعال‌سازی ابزار، operation، tenant یا مقصد؛
rollback نسخه شِما یا policy؛
جبران اقدام کسب‌وکار در سامانه مرجع.

عمر کوتاه توکن، introspection یا revocation در صورت پشتیبانی، چرخش کلید و deny list اضطراری داشته باشید. feature flag اثر تازه را متوقف کند، بدون پاک‌کردن شواهد یا checkpoint. اگر ابزار compromise شد، خروجی و حافظه مشتق از آن را نیز quarantine کنید.

سناریوی incident را تمرین کنید: توکن سرقت‌شده، کلید لو‌رفته، update مخرب ابزار، خروجی poison، تأیید اشتباه و تراکنش تکراری. زمان کشف تا توقف، ابطال، شناسایی پرونده، جبران و بازیابی امن سنجیده شود.

کیفیت مجوز را اندازه بگیرید

این شاخص‌ها مهم‌اند:

اقدام غیرمجاز موفق و exposure میان tenant؛
grant بیش‌ازحد و scope بدون استفاده؛
پوشش توکن کوتاه‌عمر، audience و sender constraint؛
deny درست در برابر false positive policy؛
نرخ، زمان، انصراف و تأیید دوباره؛
تلاش bypass با encoding، خروجی ابزار یا تزریق پرامپت؛
اثر تکراری و شکستن بودجه تجمعی؛
زمان میانه revoke و containment؛
درصد اقدام با زنجیره کامل هویت و شاهد؛
بهره‌وری، تکمیل و کاهش زمان چرخه.

deny زیاد می‌تواند دفاع خوب یا ابزار بد باشد. با مالک کسب‌وکار و امنیت نمونه‌ها را مرور کنید. قابلیت را کوچک، داده policy را بهتر و فقط حالت پایدار کم‌ریسک را خودکار کنید. برای بالا بردن completion، کنترل را کورکورانه شل نکنید.

مرحله‌ای منتشر و تأمین‌کننده را بررسی کنید

از ابزار خواندنی در tenant آزمایشی شروع کنید. سپس draft برگشت‌پذیر، بعد اقدام خارجی تأییدشده و در نهایت اجرای مستقیم بسیار محدود را اضافه کنید. تصمیم policy را پیش از enforcement shadow کنید تا attribute ناقص پیدا شود، اما کنترلی که نبودش داده واقعی را افشا می‌کند نباید shadow باشد.

ابزار و سرور MCP شخص ثالث را از نظر مالکیت، update، signing، پاسخ آسیب‌پذیری، پردازش داده، sub-processor، مقصد شبکه، نگهداری credential، tenancy، logging، deletion و emergency disable بررسی کنید. تغییر schema یا permission باید notification اجباری داشته باشد. راهنمای ریسک و خرید فروشنده هوش مصنوعی ساختار وسیع‌تری برای due diligence ارائه می‌کند.

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

یادداشت منابع

بازبینی محتوایی در ۲۰۲۶-۰۷-۳۰ انجام شد. راهنمای credential با مستندات جاری MCP و استانداردهای OAuth در IETF تطبیق داده شد. سند Zero Trust در NIST نهایی است. مقاله هویت عامل NCCoE در فوریه ۲۰۲۶ صریحاً پیش‌نویس اولیه عمومی با دوره نظرخواهی بسته‌شده است، نه استاندارد نهایی. فهرست OWASP چارچوب تهدید است، نه گواهی.