اگر امروز یک عامل هوش مصنوعی را به تمام ابزارهای سازمان خود متصل کرده‌اید، احتمالاً به‌جای یک دستیار مستقل، یک ریسک امنیتی متحرک ساخته‌اید. باید بدانید که دسترسی به ابزار با «عاملیت» متفاوت است و اشباع بازار از رابط‌های اتصال، خلأ عمیقی را در مدیریت مجوزها پنهان کرده است.
به نقل از تحلیل راهبردی منتشرشده در ۲۷ ژوئن ۲۰۲۶ در وب‌سایت dev.to، وسواس فعلی صنعت روی «رابط‌های اتصال» (Connectors) باعث شده است نیاز بنیادین به یک «قرارداد عملیاتی» (Action Contract) دارای مجوز نادیده گرفته شود. تصور کنید عاملی دارید که می‌تواند پیام‌های Slack را بخواند، ایمیل‌ها را جست‌وجو کند، داده‌های CRM را استخراج کند و در GitHub تیکت بزند. این عامل می‌تواند وضعیت صورت‌حساب‌ها را بررسی کند، مستندات را مرور نماید، جداول داده را ویرایش کند، پیش‌نویس پاسخ‌ها را بنویسد و APIهای داخلی را فراخوانی کند. همه این را «قدرتمند» می‌نامند، اما این نخستین اشتباه است؛ مسئله این نیست که عامل به چه چیزهایی «دسترسی» دارد، بلکه این است که اجازه دارد چه چیزی را «تغییر» دهد.
این وضعیت شبیه این است که به یک کارآموز تازه‌وارد کلید تمام اتاق‌های دفتر را بدهید، اما اجازه ندهید هیچ چکی را امضا کند. او به همه جا دسترسی دارد، اما هیچ «عاملیتی» ندارد. در دنیای هوش مصنوعی، یک رابط اتصال صرفاً یک در است؛ اما عاملیت، همان قراردادی است که تعیین می‌کند چه کسی اجازه عبور دارد، چه چیزی همراه خود می‌برد، چه کسی کیف او را بازرسی می‌کند و اگر مشکلی پیش آمد، چه کسی فیلم دوربین‌ها را بررسی می‌کند. این شکاف میان دسترسی ظاهری و توان عملیاتی واقعی، دقیقاً همان چیزی است که در تحلیل ما پیرامون دلیل شکست دموهای هوش مصنوعی در مقیاس واقعی به عنوان «شکاف هارنس» مورد بررسی قرار گرفت.
همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد کورکورانه به لایه‌های دسترسی، نقطه ضعف اصلی استقرار مدل‌ها در محیط عملیاتی است. طبق این گزارش، یک سامانهٔ مستحکم باید از مدل‌های ساده فاصله بگیرد و یک «پشتهٔ حقوقی» (Rights Stack) پنج‌لایه را پیاده کند. اگر می‌خواهید بدانید آیا یک عامل واقعاً دارای عاملیت است یا خیر، باید این پشته را بررسی کنید:
- رویت‌پذیری (Visibility): تعریف دقیق اینکه عامل چه داده‌ها، ابزارها، اسناد، گزارش‌ها و سیستم‌هایی را می‌تواند بازبینی و بازرسی کند. این شفافیت در رویت‌پذیری مستلزم آن است که مستندات به گونه‌ای برای ماشین‌ها طراحی شوند تا عامل بتواند به‌طور بهینه ابزارها را شناسایی کند.
- تغییر (Mutation): مشخص کردن اینکه کدام اشیاء قابل تغییر هستند. خواندن یک رکورد مشتری و تغییر دادن آن، دو قدرت کاملاً متفاوت است. نوشتن پیش‌نویس یک پاسخ و ارسال نهایی آن، دو سطح دسترسی متفاوت هستند.
- اثبات (Proof): الزام عامل به ارائه مدرک پیش از نهایی کردن تغییر. این می‌تواند یک اجرای آزمایشی (Test run)، یک Diff (مقایسه تغییرات)، یک ردپای عملیاتی (Trace)، بررسی خط‌مشی (Policy check)، تأیید انسانی یا یک بسته‌ی شواهد باشد.
- تصاعد (Escalation): تعیین شرایط دقیقی که باعث انتقال فوری کنترل به انسان می‌شود. این یک شعار مبهم نیست، بلکه شامل شرایط نام‌گذاری شده است: نبود زمینه (Context)، هزینه‌های بالای بازگشت‌پذیری، جابه‌جایی مبالغ مالی، تغییر در سطح привиلیج‌ها یا مواجهات حقوقی.
- ابطال (Revocation): تعیین اینکه پس از یک شکست، چه تغییری رخ می‌دهد. برخلاف انسان‌ها که پس از قضاوت نادرست اعتماد را از دست می‌دهند، اکثر عامل‌ها چیزی نمی‌بازند. آن‌ها شکست می‌خورند، وصله می‌شوند و دوباره با همان سطح دسترسی بازمی‌گردند؛ حالتی که به عنوان «فراموشی با کلید API» توصیف شده است. برای مقابله با این نقص، راهکارهایی مانند استفاده از حافظه‌ی مشترک در APIهای جدید می‌تواند به جلوگیری از تکرار اشتباهات پیشین کمک کند.
بر اساس بررسی منابع متعدد، این چارچوب پیشنهاد می‌کند که «سلطه» باید متناسب با «پیامد» باشد. حقوق عملیاتی خوب، یک دیوار واحد دور سیستم نیستند، بلکه مانند یک «شیب» عمل می‌کنند.
اقدامات با پیامد کم باید «ارزان» باشند. نمونه‌هایی از این دست شامل جست‌وجوهای فقط-خواندنی در Slack یا نوشتن پیش‌نویس پاسخ به مشتری است. همچنین، ویرایش‌های محلی بازگشت‌پذیر باید ارزان‌تر از تعهدات خارجی غیرقابل بازگشت باشند. در مقابل، اقدامات با پیامد بالا — مانند ارسال نهایی ایمیل، بازپرداخت وجه یک فاکتور یا ادغام یک Pull Request — باید از گیت‌های سخت‌گیرانه‌تر و لایه‌های تأیید قوی‌تری عبور کنند.
این ساختار دقیقاً شبیه سازمان‌های انسانی است: یک فارغ‌التحصیل سناریوها را مدل می‌کند، یک مدیر بودجه‌های کوچک را تأیید می‌کند، یک مدیر ارشد نیروی انسانی را بازتخصیص می‌دهد و هیئت‌مدیره خرید یک شرکت دیگر را تصویب می‌کند. عامل‌های هوش مصنوعی نیز به همین طیف از صلاحیت و سلسله‌مراتب نیاز دارند.
این چرخش، بازار را به دو دسته تقسیم می‌کند: گروهی که بر سر «برد» (Reach) رقابت می‌کنند و رابط‌های اتصال بیشتری (مانند Gmail, GitHub, Linear, Notion, Stripe)، حافظه بیشتر و محیط‌های متنوع‌تری ارائه می‌دهند؛ و گروهی که «عاملیت» (Agency) را از طریق عملیات مجوزدار، خودمختاری محدود، اثبات پیش از تعهد و تصاعد در زمان شکست زمینه می‌فروشند.
برد در دموها و نمایش‌های اولیه جذاب است، اما عاملیت در مواجهه با حوادث واقعی سازمان دوام می‌آورد و در بازرسی‌های پس از حادثه (Incident Review) پابرجا می‌ماند. برای متخصصان، گلوگاه دیگر هوش مدل نیست، بلکه «قضاوت مهندسی‌شده» پیرامون آن است.
گام بعدی شما
برای آزمایش پیاده‌سازی فعلی خود، در هفته جاری «تست حقوق عملیاتی عامل» را روی یک گردش‌کار (Workflow) واحد اجرا کنید. پاسخ‌های پنج‌گانه را مستند کنید:
- اگر نمی‌توانید پاسخ دهید «عامل چه چیزی را می‌بیند؟»، شما فاقد یک فهرست موجودی (Inventory) هستید.
- اگر نمی‌توانید پاسخ دهید «عامل چه چیزی را می‌تواند تغییر دهد؟»، شما فاقد یک مدل مجوز (Permission Model) هستید.
- اگر نمی‌توانید پاسخ دهید «عامل چه چیزی را باید اثبات کند؟»، شما فاقد سیستم تأیید (Verification) هستید.
- اگر نمی‌توانید پاسخ دهید «چه چیزی باعث تصاعد می‌شود؟»، شما فاقد نظارت (Oversight) هستید.
- اگر پاسخ پنجم — یعنی ابطال — خالی است، شما در لایه صلاحیت، فاقد مکانیزم یادگیری هستید.
عامل شما به ابزار جدید نیاز ندارد؛ بلکه نیاز دارد «حقِ اشتباه کردنش» کوچک‌تر شود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو