«جداسازی کنش‌گر از صاحب اختیار»؛ تنها راه حسابرسی در سامانه‌های سازمانی

تصور کنید یک عامل تمدید قرارداد در ساعت ۳ صبح، بدون حضور هیچ انسانی، حساب یکی از مشتریان استراتژیک را در CRM تغییر می‌دهد. اگر سیستم این تغییر را به نام «الکس» ثبت کند چون او مالک حساب است، یک ردپای جعلی ایجاد شده؛ اما اگر بنویسد «عامل تمدید»، مشخص نمی‌شود چه کسی اجازه این تغییر را داده است.

این بحران بنیادین هویت، اصلی‌ترین مانع برای استقرار عامل‌های هوش مصنوعی در مقیاس صنعتی است. وقتی به یک عامل می‌گویید «وضعیت شرکت Acme را به ریسکی تغییر بده و یک برنامه تمدید آماده کن»، او دقیقاً همین کار را می‌کند. اما CRM باید چه ثبت کند؟ نام شما که دستور دادید، یا نام عامل که اجرا کرد؟ پاسخ درست این است: «عامل تمدید، به نمایندگی از الکس». مشکل اینجاست که تقریباً هیچ نرم‌افزار سازمانی فعلی، جایی برای ثبت این حقیقت ندارد.

بیشتر نرم‌افزارهای شرکتی برای مدل «تک-اصالت» ساخته شده‌اند؛ یعنی یک کاربر انسانی احراز هویت می‌کند، نقش‌هایی می‌گیرد و عملیاتی را انجام می‌دهد. در این دنیا، کنش‌گر و صاحب اختیار یک نفر هستند. اما عامل‌های هوش مصنوعی (AI Agents) — مثل کارمندی که هم می‌تواند فکر کند و هم ابزارها را مدیریت کند — این منطق را می‌شکنند. آن‌ها به استدلال انسانی نیاز دارند اما باید با انضباط سخت‌گیرانهٔ یک حساب سیستمی عمل کنند. همان‌طور که در تحلیل قبلی ما درباره‌ی ابزارهایی مثل Riskified اشاره کردیم، صنعت اکنون دریافته است که تأیید هویت به تنهایی کافی نیست، اگر مدل دسترسی‌های زیربنایی معیوب باشد.

شکاف میان کنش‌گر و صاحب اختیار

به نقل از گزارشی که در ۱۶ اکتبر ۲۰۲۶ در dev.to منتشر شد، مشکل اصلی در هم‌MIX شدن دو پرسش متمایز است: چه کسی عملیات را انجام داد (کنش‌گر) و اجازهٔ چه کسی این کار را ممکن کرد (صاحب اختیار).

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

در مفاهیم امنیتی، «اصالت» (Principal) هر موجودیتی است که سیستم بتواند او را شناسایی کرده و به او حق دسترسی بدهد. برای انسان، کنش‌گر و صاحب اختیار یکسان هستند. اما یک عامل این زنجیره را تغییر می‌دهد. دو سناریوی زیر را در نظر بگیرید که هر دو از طریق پروتکل زمینهٔ مدل (MCP) منجر به یک تغییر در پایگاه‌داده می‌شوند:

• زنجیره ۱: الکس $\rightarrow$ عامل تمدید $\rightarrow$ MCP $\rightarrow$ HubSpot
• زنجیره ۲: سیاست تمدید $\rightarrow$ عامل تمدید $\rightarrow$ MCP $\rightarrow$ HubSpot (اجرا در ساعت ۰۳:۱۴ بدون حضور انسان)

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

وقتی یک عامل از توکن OAuth کاربر استفاده می‌کند، مشکل اختیار را حل می‌کند اما هویت کنش‌گر را می‌کشد. عامل نامرئی می‌شود و کارهای او با کارهای انسان یکی می‌شود. این برای خلاصه‌سازی یک گزارش پذیرفتنی است، اما وقتی عامل در ساعات غیرکاری تصمیمی خودکار می‌گیرد، خطرناک است. مکانیزم‌های فنی برای حفظ هر دو حقیقت وجود دارد؛ مثلاً جریان on-behalf-of در OAuth اجازه می‌دهد یک موجودیت با اختیار دیگری عمل کند اما همچنان متمایز بماند.

طبق اعلام مایکروسافت، هر مدل هویت عامل باید به این پرسش پاسخ دهد: آیا اقدام به نمایندگی از کاربر انجام شده یا توسط خودِ اپلیکیشن؟ این همان تفکیکی است که فیلد «آخرین تغییر توسط» در CRMهای فعلی ساختاراً قادر به پاسخ به آن نیست.

مقیاس هویت‌های غیرانسانی

چرخش به سمت اقدامات ماشین‌محور بسیار گسترده است. یک نظرسنجی در سال ۲۰۲۶ توسط Palo Alto Networks از ۲۹۰۰ تصمیم‌گیرنده امنیت سایبری نشان داد که تعداد هویت‌های ماشینی اکنون ۱۰۹ برابر هویت‌های انسانی است. این عدد نشان‌دهنده یک نگرانی عملیاتی بزرگ است: گسترش بی‌رویه (Sprawl). یعنی هزاران اعتبارنامه‌ی طولانی‌مدت که هیچ‌کس مالک آن‌ها نیست و هرگز تغییر نمی‌کنند.

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

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

پنج مدل خودمختاری عامل

صنعت برای مدیریت این وضعیت به سمت پنج سطح خودمختاری حرکت می‌کند:

• دستیار نامرئی: عامل با مجوزهای کاربر جست‌وجو یا پیش‌نویس می‌زند. از نظر سیستم، انسان هنوز کنش‌گر است.
• قابلیت نام‌دار: سازمان یک «عامل تمدید» می‌سازد. مردم آن را فرا می‌خوانند و عامل با اختیار کاربر اجرا می‌شود. عامل هویت محصول دارد اما کارمند مستقل نیست.
• عامل تفویض‌شده: عامل هویت خودش را دارد و تحت اختیار تفویض‌شده کسی عمل می‌کند. سیستم ثبت می‌کند: صاحب اختیار: الکس، کنش‌گر: عامل تمدید. این اولین سطحی است که از حسابرسی (Audit) سرباز نمی‌زند.
• عامل خودمختار: هویت مستقل و مجوزهای محدود دارد. بر اساس سیاست سازمانی تصمیم می‌گیرد و عمل می‌کند، نه منتظر دستور انسان.
• همکار دیجیتال: عامل به یک شرکت‌کننده سازمانی با حساب و حضور مستقل تبدیل می‌شود. هویت در اینجا اختیاری نیست چون دیگران با او تعامل می‌کنند و به او کار می‌سپارند.

پاسخ پلتفرم‌های بزرگ

شش پلتفرم اصلی در حال پیاده‌سازی این تفکیک‌ها هستند:

• Microsoft Entra Agent ID: هر دو اصالت را ارسال می‌کند و دو حالت «دسترسی خودمختار» و «دسترسی تفویض‌شده» را ارائه می‌دهد.
• Google Cloud Agent Identity: بر اساس استاندارد SPIFFE، یک هویت رمزنگاری‌شده قوی به هر عامل می‌دهد که قابل جعل نیست.
• GitHub Copilot: کامیت‌ها را به نام Copilot ثبت می‌کند و انسانی که تسک را شروع کرده به عنوان هم‌نویس (Co-author) درج می‌شود.
• Salesforce Agentforce: روی اختیار تمرکز کرده نه انتساب. هر عامل به یک کاربر در حال اجرا متصل است تا دسترسی‌هایش تعیین شود.
• ServiceNow: با مدل «کاربر پویا»، مجوزهای عامل را به زیرمجموعه‌ای از نقش‌های کاربر فراخواننده محدود می‌کند.
• Model Context Protocol (MCP): هر دو اصالت را نام می‌برد اما هنوز ناقص است. این پروتکل ارسال توکن‌های کاربر را ممنوع کرده و خواستار هویت مستقل برای عامل‌هاست.

مدل مجوزهای اشتراکی (Intersection)

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

مدل ذهنی باید «اشتراک» (Intersection) باشد: مجوز نهایی = اختیار کاربر $\cap$ مجوزهای عامل $\cap$ سیاست گردش‌کار.

این یک اشتراک است، نه ارث‌بری. یعنی سه قید باید هم‌زمان اجازه دهند، نه اینکه یک اجازه از بالا به پایین جاری شود. این یک چرخش در کنترل دسترسی است. سیستم‌های عامل‌محور باید بپرسند: «این عامل، تحت اختیار این کاربر، از طریق این ابزار، روی این منبع، در این بستر و همین حالا چه کاری می‌تواند انجام دهد؟» این قوانین نباید به شکل پرامپت در داخل عامل باشند، چون پرامپت‌ها فقط پیشنهاد هستند و با تزریق پرامپت دور زده می‌شوند. قوانین باید در لایه‌ای باشند که عامل برای استعلام به آن مراجعه می‌کند. این رویکرد دقیقاً همان چیزی است که در بررسی لایه‌های مجوز برای جلوگیری از اجرای غیرمجاز APIها به آن پرداختیم تا از دسترسی‌های بیش از حد عامل‌ها جلوگیری شود.

چرا MCP اکنون به یک مسئله هویت تبدیل شده است؟

پروتکل MCP در حال تبدیل شدن به رابط مشترک بین عامل‌ها و ابزارهای سازمانی است. یک پیاده‌سازی ساده، توکن کاربر را در کل زنجیره (عامل $\rightarrow$ سرور MCP $\rightarrow$ CRM) منتقل می‌کند.

مشخصات MCP این کار را صراحتاً ممنوع کرده است. توکن‌ها باید دقیقاً برای سرور مقصد صادر شده باشند. اگرچه این کار مشکل «نماینده گیج» (Confused Deputy) را حل می‌کند، اما مشکل هویت را نه. نقشه راه MCP اشاره می‌کند که فراخواننده به جای انسان، هر روز بیشتر یک عامل یا یک بار کاری ابری است.

بدون حل این مسئله، امنیت در سطح ردیف (Row-level security) از کار می‌افتد چون سرور هرگز هویت کاربر فراخواننده را دریافت نمی‌کند و در نتیجه هر کسی هر چیزی را می‌بیند.

از لاگ‌های خطی به گراف‌های اقدام

لاگ‌های سنتی (کاربر X فیلد Y را تغییر داد) نمی‌توانند کار عامل‌محور را ثبت کنند. برای یک اقدام خودمختار، زنجیره‌ای از پرسش‌ها مهم است: چه کسی تحریک کرد؟ کدام عامل تصمیم گرفت؟ از چه بستری استفاده کرد؟ کدام سیاست اجازه داد؟ آیا تایید انسانی لازم بود؟ کدام ابزار فراخوانده شد؟

پاسخ به این‌ها، دیگر یک لاگ نیست؛ بلکه یک «گراف» است که گره‌های آن اصالت‌ها، عامل‌ها، سیاست‌ها و ابزارها هستند. اینجاست که مشاهده‌پذیری (Observability) به رکورد پاسخگویی تبدیل می‌شود.

ردپای کامیت‌های GitHub نزدیک‌ترین اجرای فعلی است. Copilot نویسنده است، انسان هم‌نویس است، کامیت‌ها امضا شده‌اند و هر پیام به لاگ‌های جلسه عامل لینک شده است. این مدل، کنش‌گر، اختیار، یکپارچگی و منشأ را در یک شیء جمع می‌کند.

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

گام بعدی شما

• در معماری عامل‌های خود، فیلد actor_id را از authority_id جدا کنید تا در زمان حسابرسی دچار تضاد نشوید.
• اگر از MCP استفاده می‌کنید، بررسی کنید که آیا توکن‌های کاربر را به طور خام پاس می‌دهید یا از مدل‌های تفویض اختیار استفاده می‌کنید.
• برای عامل‌های حساس، مدل «مجوز اشتراکی» (Intersection) را پیاده کنید تا عامل حتی با اختیار مدیر ارشد، دسترسی‌های مخرب نداشته باشد.

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