پرش به محتوای اصلی
رامین خاورزاده DATA · ANALYSIS · PERSPECTIVE
تحلیل ·داده و هوش مصنوعی · 1405/06/26 · زمان مطالعه: 16 دقیقه

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

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

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

    وقتی یک دستیار هوش مصنوعی فقط پیشنهاد می‌دهد، خطای مدل یعنی یک پاسخ نادرست. اما وقتی همین سیستم بتواند ایمیل بفرستد یا رکورد حذف کند، پرسش اصلی این است که با چه مجوزی کار می‌کند. پروژه امنیت GenAI در OWASP در دسامبر ۲۰۲۵ فهرست ده ریسک اصلی برنامه‌های عامل‌محور را منتشر کرد و به گفته این پروژه، این فهرست حاصل مشارکت بیش از ۱۰۰ پژوهشگر و فعال صنعت است[۱]. سوءاستفاده از هویت و امتیاز، در کنار ربایش رفتار عامل و سوءاستفاده از ابزار، از تهدیدهای برجسته این فهرست است[۱]. برداشت ما این است که کیفیت مدل شرط لازم است، اما مرز خسارت را ساختار دسترسی تعیین می‌کند.

    واقعیت‌های کلیدی

    • OWASP در دسامبر ۲۰۲۵ فهرست ده ریسک اصلی برنامه‌های عامل‌محور را با مشارکت بیش از ۱۰۰ پژوهشگر و فعال صنعت منتشر کرد.[۱]
    • به گفته OWASP، ریشه عاملیت بیش از حد معمولاً کارکرد، مجوز یا خودمختاری بیش از حد است.[۲]
    • AWS برای عامل‌ها اعتبارنامه موقت با عمر ۱۵ تا ۶۰ دقیقه و بازبینی فصلی انحراف مجوزها را توصیه می‌کند.[۶]
    • به گفته مایکروسافت، یک عامل ممکن است فقط چند دقیقه وجود داشته باشد یا روزانه هزاران بار ساخته و حذف شود.[۵]
    • به گفته OWASP، ثبت و پایش جلوی عاملیت بیش از حد را نمی‌گیرد و فقط خسارت را محدود می‌کند.[۲]
    • به گفته AWS، سرورهای MCP مدیریت‌شده این شرکت با افزودن کلیدهای زمینه، اقدام عامل را از اقدام انسان قابل تشخیص می‌کنند.[۷]

    مدل بهتر، دامنه خسارت را کوچک نمی‌کند

    به گفته راهنمای مرجع OWASP درباره عاملیت بیش از حد، اقدام آسیب‌زا فارغ از علت خطای مدل ممکن است رخ دهد و دو محرک رایج آن توهم مدل و تزریق مستقیم یا غیرمستقیم پرامپت است[۲]. به گفته همین راهنما، ریشه مشکل معمولاً کارکرد بیش از حد، مجوز بیش از حد یا خودمختاری بیش از حد است[۲]. برگه راهنمای OWASP برای پیشگیری از تزریق پرامپت توضیح می‌دهد که مدل‌های زبانی دستور و داده را بدون جداسازی روشن پردازش می‌کنند و دستور مخرب ممکن است در ایمیل، سند یا صفحه وب پنهان شود[۳]. برداشت ما این است که هر سه ریشه تصمیم طراحی‌اند، نه ویژگی خود مدل.

    در مثال OWASP، دستیاری که فقط باید ایمیل‌ها را خلاصه کند افزونه‌ای با امکان ارسال پیام دارد و یک ایمیل دست‌کاری‌شده مدل را وادار می‌کند اطلاعات حساس صندوق نامه را برای مهاجم بفرستد[۲]. به گفته OWASP، افزونه‌ای که فقط توان خواندن دارد یا دسترسی فقط‌خواندنی از طریق OAuth می‌توانست جلوی این آسیب را بگیرد[۲]. AWS هم توصیه می‌کند فرض شود عامل هر کاری را که مجوزهایش اجازه می‌دهد انجام خواهد داد[۷]. به گفته AWS، توسعه‌دهندگان اغلب اعتبارنامه‌های مدیریتی خود یا حتی نقش‌های محیط عملیاتی را به عامل می‌دهند، در حالی که این مجوزها برای کار تعاملی با قضاوت انسان طراحی شده‌اند[۷].

    نمودار پنج مرحله‌ای: ورود دستور مخرب در محتوای بیرونی، پذیرش آن به دست مدل، اجرای ابزار با مجوز موجود، مهار با هویت و مجوز محدود، و ثبت اقدام برای کشف
    بر پایه راهنماهای OWASP درباره تزریق پرامپت و عاملیت بیش از حد و مستندات مایکروسافت و AWS[۳][۲][۴][۶]

    چهار تصمیم پیش از اجازه اجرا: هویت، دامنه، زمان و ثبت اقدام

    مستندات Microsoft Entra دو الگوی هویت را جدا می‌کند: عامل تعاملی با مجوز واگذارشده و جریان on-behalf-of از طرف کاربر کار می‌کند و عامل خودمختار با هویت خودش و جریان client credentials احراز هویت می‌شود[۴]. به گفته مایکروسافت، هویت ویژه عامل از جمله برای جدا کردن عملیات عامل از عملیات کارکنان و مشتریان و دسترسی به‌اندازه نیاز طراحی شده است[۵]. همین منبع می‌گوید یک عامل ممکن است فقط چند دقیقه وجود داشته باشد یا روزانه هزاران بار ساخته و حذف شود[۵].

    AWS صدور اعتبارنامه موقت با سیاست نشست و عمر ۱۵ تا ۶۰ دقیقه، تعیین سقف مجوز برای جلوگیری از افزایش امتیاز به دست خود عامل و بازبینی فصلی انحراف مجوزها را توصیه می‌کند[۶]. به گفته AWS، یکی از الگوهای نادرست این است که پس از هر خطای دسترسی، بدون بررسی مشروع بودن درخواست، مجوز تازه اضافه شود و هرگز پس گرفته نشود[۶].

    OWASP توصیه می‌کند تصمیم مجوز در سیستم مقصد گرفته شود، نه اینکه به مدل زبانی سپرده شود، و اقدام‌های پرتأثیر پیش از اجرا تأیید انسانی بگیرند[۲]. در مثال این منبع، برنامه‌ای که از طرف کاربر محتوای شبکه اجتماعی منتشر می‌کند باید مرحله تأیید کاربر را درون خود عملیات انتشار داشته باشد[۲].

    به گفته AWS، سرورهای MCP مدیریت‌شده این شرکت کلیدهای زمینه‌ای به فراخوانی‌ها اضافه می‌کنند تا اقدام عامل از اقدام انسان تشخیص‌پذیر باشد، اما اگر عامل از طریق shell مستقیماً به API سرویس‌ها برسد، این سازوکار تفکیک اعمال نمی‌شود[۷]. OWASP تأکید می‌کند ثبت و پایش جلوی عاملیت بیش از حد را نمی‌گیرند و فقط خسارت را محدود می‌کنند[۲].

    پراکندگی عامل‌ها و هزینه‌ای که به لایه هویت منتقل می‌شود

    مایکروسافت پراکندگی عامل‌ها را وضعیتی توصیف می‌کند که واحدهای کسب‌وکار بدون نظارت فناوری اطلاعات عامل بسازند، عامل‌های موقت در محیط عملیاتی باقی بمانند و مجوزهای بیش از نیاز هرگز بازبینی نشوند[۴]. به گفته همین منبع، نتیجه عامل‌هایی با امتیاز بیش از حد و مالک نامشخص است[۴]. در Copilot Studio، سازنده هر عامل به‌عنوان حامی آن ثبت می‌شود[۵]. به گفته مایکروسافت، Entra Agent ID در اختیار همه مشتریان Entra است، اما گسترش قابلیت‌های امنیتی Entra به عامل‌ها به Microsoft Agent 365 نیاز دارد[۵]. این الگو می‌تواند نشان دهد که حاکمیت هویت عامل‌ها به لایه‌ای قیمت‌گذاری‌شده در پلتفرم‌های سازمانی تبدیل می‌شود و بودجه پروژه عامل‌محور به هزینه مدل و توکن محدود نمی‌ماند.

    آیا تمرکز بر مجوز، مسئله را بیش از حد ساده می‌کند؟

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

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

    لایه‌های کنترل پیش از اجازه اقدام به عامل هوش مصنوعی، بر پایه راهنماهای OWASP، مایکروسافت و AWS[۲][۴][۵][۶]
    لایه کنترلچه کاری می‌کندمرجع
    هویت مستقل عاملاقدام عامل را از اقدام کاربر و برنامه جدا می‌کندMicrosoft Entra Agent ID
    حداقل کارکرد و مجوزابزارها، توابع و دسترسی‌ها را به حداقل لازم محدود می‌کندOWASP LLM06
    اعتبارنامه موقتنشست کوتاه ۱۵ تا ۶۰ دقیقه با سیاست نشستAWS
    سقف مجوزاز افزایش امتیاز به دست خود عامل جلوگیری می‌کندAWS
    مجوزدهی در سیستم مقصد و تأیید انسانیتصمیم مجوز بیرون از مدل گرفته می‌شود و اقدام پرتأثیر تأیید می‌خواهدOWASP LLM06
    ثبت و پایشاقدام ناخواسته را کشف می‌کند اما جلوی آن را نمی‌گیردOWASP و مایکروسافت
    بازبینی انحراف مجوزبازبینی فصلی و حذف دسترسی‌های بلااستفادهAWS

    خط زمانی

    1. 2025-12: انتشار فهرست ده ریسک اصلی برنامه‌های عامل‌محور از سوی پروژه امنیت GenAI در OWASP[۱]

    برای کسب‌وکارهای ایرانی

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

    چه چیزی را باید دنبال کرد

    • به‌روزرسانی‌های فهرست OWASP برای برنامه‌های عامل‌محور و راهنماهای همراه آن
    • اینکه تشخیص اقدام عامل از اقدام انسان در لاگ‌ها به قابلیت پیش‌فرض پلتفرم‌های ابری و هویت تبدیل می‌شود یا نه
    • هزینه مجوز لایه‌های امنیتی عامل در بسته‌های نرم‌افزاری سازمانی و اثر آن بر بودجه پروژه‌های عامل‌محور
    • مسیرهای دسترسی مستقیم عامل از طریق shell که کنترل‌های مسیر MCP را دور می‌زنند

    منابع

    1. OWASP GenAI Security Project Releases Top 10 Risks and Mitigations for Agentic AI Security — OWASP Top 10 for LLM & Generative AI Security، انتشار: 2025-12-09، شواهد تازه، دسترسی: 2026-09-17
    2. LLM06:2025 Excessive Agency — OWASP Top 10 for LLM & Generative AI Security، منبع مرجع، دسترسی: 2026-09-17
    3. LLM Prompt Injection Prevention Cheat Sheet¶ — cheatsheetseries.owasp.org، منبع مرجع، دسترسی: 2026-09-17
    4. Microsoft Entra security for AI overview - Microsoft Entra Agent ID — MicrosoftLearn، منبع مرجع، دسترسی: 2026-09-17
    5. What are agent identities? - Microsoft Entra Agent ID — MicrosoftLearn، منبع مرجع، دسترسی: 2026-09-17
    6. AGENTSEC03-BP03 Implement least privilege with dynamic boundaries — docs.aws.amazon.com، منبع مرجع، دسترسی: 2026-09-17
    7. Secure AI agent access patterns to AWS resources using Model Context Protocol | Amazon Web Services — Amazon Web Services، منبع مرجع، دسترسی: 2026-09-17

    روش تهیه: این تحلیل با سامانه پایش خودکار khavarzadeh.com و کمک مدل‌های زبانی از منابع بالا تهیه شده و پیش از انتشار، تطابق اعداد، تاریخ‌ها و ارجاع‌ها با منابع به‌صورت خودکار کنترل شده است. واقعیت‌ها با شماره منبع مشخص شده‌اند و بقیه متن برداشت تحلیلی است. تاریخ تهیه: 2026-09-17.

    اشتراک‌گذاری:

    نظرات

    هنوز نظری ثبت نشده است؛ اولین نفر باشید.

    افزودن نظر