استاندارد SOC 2 برای بسیاری از سازمان‌ها تنها ابزاری برای کسب یک نشان (Badge) جهت جلب اعتماد مشتریان است، اما در واقعیت، این چارچوب روش پذیرفته شده‌ای برای اثبات قابلیت اعتماد در مدیریت داده‌هاست. با این حال، ظهور AI Agents (عوامل هوش مصنوعی) باعث شده است که مفروضات سنتی این استاندارد با چالش‌های جدی روبرو شوند.
شکاف بین کنترل‌های سنتی و واقعیت‌های AI
معیارهای SOC 2 به گونه‌ای طراحی شده‌اند که نسبت به تکنولوژی خنثی باشند، اما این موضوع باعث شده است که حسابرسان و سازمان‌ها، AI Agents را به عنوان یک کلاس شناسایی (Identity Class) مجزا در نظر نگیرند. این ابهام اجازه می‌دهد تا عوامل هوش مصنوعی بدون نقض هیچ‌یک از کنترل‌ها، ریسک‌های عملیاتی قابل توجهی را به محیط تولید (Production) اضافه کنند.
چهار مفروضه شکست‌خورده در مدیریت دسترسی (CC6.1–CC6.3)
- تایید حساب پیش از ایجاد: در SOC 2، کاربر باید پیش از دسترسی تایید شود. اما AI Agents اغلب از طریق یک کلیک روی OAuth، یک API Key در فایل تنظیمات یا یک MCP Server ایجاد می‌شوند و هیچ فرآیند تایید رسمیی برای خلق آن‌ها وجود ندارد.
- مالکیت مشخص: در بازبینی‌های دسترسی (Access Review)، یک انسان تایید می‌کند که حساب مورد نظر همچنان به دسترسی نیاز دارد. در مورد AI Agents، اغلب مالکی تعریف نشده است و شناسایی صاحب Agent تنها از طریق شواهد غیرمستقیم و حدس و گمان ممکن است.
- تطبیق نام در Log با عامل واقعی: بسیاری از AI Agents با استفاده از اعتبارنامه‌های قرض گرفته شده (Borrowed Credentials) مانند توکن‌های توسعه‌دهنده یا Service Accountها عمل می‌کنند. در نتیجه، در Logها نام یک انسان دیده می‌شود، در حالی که عملیات توسط یک Agent انجام شده است. طبق گزارش Cloud Security Alliance، بیش از دو-سوم سازمان‌ها نمی‌توانند اقدامات AI Agent را از اقدامات انسانی تشخیص دهند.
- تطبیق سطح دسترسی با وظیفه: اصل Least Privilege بر این اساس است که دسترسی‌های یک حساب، نشان‌دهنده وظیفه آن است. اما در AI Agents، دسترسی‌ها تنها شعاع تخریب (Blast Radius) را محدود می‌کنند و هیچ‌گونه اطلاعاتی درباره «قصد» یا «هدف» Agent در لحظه اجرا ارائه نمی‌دهند.
کنترل‌هایی که در عمل پوچ شده‌اند
خروج از سازمان (Offboarding – CC6.3): سیستم‌های HR برای خروج کارکنان انسانی عالی عمل می‌کنند، اما هیچ سیستم HRی برای AI Agents وجود ندارد. اگر کارمندی سازمان را ترک کند، Agentهایی که به نام او ایجاد شده‌اند ممکن است همچنان از طریق API Keyها فعال بمانند.
مدیریت تامین‌کنندگان (Vendor Management): سرورهای MCP در واقع تامین‌کنندگانی هستند که داده‌ها را دریافت کرده و کد اجرا می‌کنند، اما برخلاف تامین‌کنندگان سنتی، آن‌ها از طریق یک فایل Config وارد محیط می‌شوند و اغلب هیچ شرکت ثبت شده‌ای پشت آن‌ها نیست تا گزارش SOC 2 ارائه دهد.
تفکیک وظایف (Segregation of Duties – CC8.1): وقتی یک Agent تغییری ایجاد می‌کند و Agent دیگری آن را بررسی می‌کند، تفکیک وظایف تنها در ظاهر (Nominal) رعایت شده است، در حالی که هر دو تحت یک منطق یا Prompt مشابه عمل می‌کنند.
نتیجه‌گیری و رویکرد Intent-based Security
داشتن یک گزارش SOC 2 بدون نقص (Unqualified Type 2 Report) به معنای کامل بودن توصیفات امنیتی نیست. برای پر کردن این شکاف، سازمان‌ها باید به سمت Intent-based Security حرکت کنند؛ یعنی ابتدا تعریف کنند که هر Agent قرار است چه کاری انجام دهد و سپس دسترسی‌های آن را دقیقاً با آن هدف تطبیق دهند. هویت (Identity) تنها لایه‌ای است که می‌تواند این کنترل را در تمام سیستم‌هایی که Agent با آن‌ها در تعامل است، اعمال کند.
