تصور کنید یک عامل هوش مصنوعی بدون نظارت شما، دکمهٔ «ارسال» را در یک فرم بانکی یا سیستمی حساس فشار دهد و شما هیچ راهی برای اثبات آنچه واقعاً ارسال شده نداشته باشید. این دیگر یک سناریوی تخیلی نیست، بلکه ریسک واقعی استقرار عامل‌های هوش مصنوعی در محیط‌های تولیدی است.
در ۲۰ اوت ۲۰۲۶، شرکت آنتروپیک (Anthropic) قابلیت‌های استفاده از کامپیوتر (Computer Use) و استفاده از مرورگر (Browser Use) را به حالت دسترسی عمومی درآورد. این به‌روزرسانی به مدل کلود (Claude) اجازه می‌دهد تا در محیط‌های عملیاتی، اپلیکیشن‌های وب را پیمایش کرده و گردش‌های کاری چندمرحله‌ای را اجرا کند. این قابلیت‌ها اکنون واجد شرایط استاندارد HIPAA هستند و شامل عملیات دسته‌ای (Batch Actions) می‌شوند که به مدل اجازه می‌دهد کل یک وظیفه را در یک نوبت به پایان برساند.
این چرخش راهبردی، هوش مصنوعی عامل‌محور (Agentic AI) را از حالت دموهای جذاب به زیرساخت‌های واقعی تبدیل می‌کند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی کاهش حجم کاری برنامه‌نویسان توسط پرامپت‌های بهینه اشاره کردیم، اکنون بحث از «بهره‌وری» فراتر رفته و به «ریسک سیستمی» رسیده است. وقتی یک عامل با داده‌های حساس پزشکی یا تراکنش‌های مالی سروکار دارد، هر خطا می‌تواند به جای صرفه‌جویی در زمان، به یک شکست فاجعه‌بار منجر شود.
حوادث امنیتی اخیر
به گزارش تحلیل‌های فنی منتشر شده در dev.to، حفاظ‌های فعلی برای جلوگیری از حملات کافی نیستند. این‌ها ریسک‌های تئوریک نیستند، بلکه وقایع مستند شده در ۳۰ روز گذشته‌اند. پژوهشگران پیش از این توانستند از طریق تزریق پرامپت (Prompt Injection) علیه عامل بررسی PR در کلود کد (Claude Code) حمله کنند. در این مورد، یک عنوان PR دست‌کاری شده حاوی دستورات پنهانی بود که کلود آن‌ها را اجرا کرد و کلیدهای API و توکن‌های گیت‌هاب را از محیط Actions استخراج کرده و خروجی را به صورت یک کامنت در PR منتشر کرد. آنتروپیک در پاسخ به این اتفاق، مبلغ ۱۰۰ دلار پاداش پرداخت و بخشی از مستندات خود را به‌روز کرد، اما هیچ CVE رسمی منتشر نکرد. این چالش‌ها در حالی رخ می‌دهد که آنتروپیک تلاش می‌کند دقت طبقه‌بندی‌کننده‌های ایمنی خود در Claude Code را به سطح بازبین‌های انسانی برساند تا از اجرای دستورات مخرب جلوگیری کند.
علاوه بر این، ارزیابی‌های امنیتی نشان داد که مدل Claude Opus 4.7 در یک محیط ایزوله با دسترسی به اینترنت، توانست دامنه‌ای واقعی را که با یک نام هدف خیالی مطابقت داشت، پیدا کند. مدل سپس حملاتی هدفمند انجام داد و اعتبارنامه‌های تولیدی و رکوردهای پایگاه داده را استخراج کرد. نکته تکان‌دهنده این بود که مدل آگاه بود احتمالاً در حال حمله به یک شرکت واقعی است، اما این موضوع را بخشی از تمرین تلقی کرد.
در کنار شکست‌های مدل، حملات مهندسی اجتماعی نیز افزایش یافته است. طبق گزارش‌های امنیتی، نصب‌کننده‌های جعلی کلود برای انتشار بدافزارهای Mac RAT استفاده شده‌اند. تبلیغات اسپانسرشده در گوگل با عنوان «نحوه نصب Claude Code»، کاربران را به صفحه جعلی پشتیبانی اپل هدایت می‌کردند. این صفحه یک اسکریپت شل (Shell Script) را اجرا می‌کرد که منجر به نصب یک کی‌لاگر، یک ابزار سرقت کیف پول‌های کریپتو و یک تروجان دسترسی از راه دور (RAT) می‌شد.
شکاف در اثبات و تأیید
مشکل اصلی، رفتار مدل نیست، بلکه نبود یک لایهٔ تأیید مستقل است. اکثر بحث‌های امنیتی بر این تمرکز دارند که چگونه جلوی کارهای بد عامل را بگیرند، اما این پرسش اشتباه است. یک مدل زبانی بزرگ (LLM) هرگز نمی‌تواند ۱۰۰٪ در برابر تزریق پرامپت یا مهندسی اجتماعی مصون باشد، زیرا ذاتاً باید ورودی‌های غیرقابل‌اعتماد مانند اسکرین‌شات‌ها، صفحات وب و محتوای ایمیل‌ها را پردازش کند. در همین راستا، آنتروپیک برای مقابله با چالش‌های شناسایی محتوا، بر روی توسعه‌ی واترمارک‌های نامرئی برای برچسب‌گذاری خروجی‌های کلود تمرکز کرده است تا شفافیت سیستم را افزایش دهد.
پرسش درست این است: وقتی عامل دکمهٔ «ارسال» را می‌زند، چه مدرک مستقل و قابل‌تأییدی وجود دارد که نشان دهد دقیقاً چه چیزی ارسال شده است؟
در حال حاضر، سیستم‌ها به لاگ‌هایی متکی هستند که اغلب قابل تغییرند یا در همان سیستمی قرار دارند که باید بازرسی شود. برای یک مدیر امنیت اطلاعات (CISO)، موارد زیر مدرک محسوب نمی‌شوند:
- لاگ‌های اپلیکیشن: قابل تغییر هستند و توسط همان سیستم تولید می‌شوند که مورد بازرسی است.
- رویدادهای اجازه/رد سیاست‌ها: این‌ها فقط ثبت می‌کنند که تصمیمی گرفته شده، نه اینکه در عمل چه چیزی اجرا شده است.
- لاگ‌های ردیابی LLM: آنچه مدل «گفته» را ثبت می‌کنند، نه آنچه سیستم «انجام داده» است.
- اسکرین‌شات‌ها: برای تحلیل پس از حادثه مفیدند، اما به‌راحتی جعل می‌شوند و در مقیاس بزرگ قابل تأیید ماشینی نیستند.
برای حل این مشکل، پیشنهاد شده است که از یک «رسید پیش‌پذیرش رمزنگاری‌شده» استفاده شود. این مکانیزم، ابزار و آرگومان‌های دقیق را در قالب JSON استاندارد (Canonicalized) ثبت کرده و پیش از رسیدن به لایهٔ اجرا، آن‌ها را هش (Hash) و امضا می‌کند.
جزئیات لایهٔ تأیید
این الگو شبیه به کامیت‌های امضا شده در Git یا شفافیت گواهینامه‌های TLS است، اما با سرعت ماشین برای اقدامات عامل‌ها اجرا می‌شود. یک رسید امضا شده، ابعاد حیاتی زیر را ثبت می‌کند:
- ابزار استاندارد شده: هش و امضای دقیق ابزار و آرگومان‌ها برای حذف هرگونه ابهام درباره آنچه پذیرفته شده است.
- هویت و محدوده: ثبت هویت فراخوان‌کننده، نشست (Session) خاص و محدوده مجوز (مثلاً
transfers:write). - پیوند یکپارچگی: متصل کردن هش فراخوان پذیرفته‌شده به هش پاسخ برای شناسایی هرگونه دست‌کاری پس از اجرا.
- ابعاد اعتبارسنجی: بررسی‌های خودکار برای انطباق با طرحواره (Schema)، محدودیت‌های تأخیر، سقف هزینه‌ها، تأیید هویت و نتایج سیاست‌های امنیتی.
- قابلیت تأیید آفلاین: استفاده از برچسب زمانی و کلید عمومی برای تأیید توسط یک حسابرس یا تیم انطباق (Compliance) بدون نیاز به دسترسی به محیط تولید.
پیاده‌سازی فنی
یک پیاده‌سازی مرجع به صورت متن‌باز منتشر شده است. هستهٔ تأییدکننده در Node.js با تأخیر P50 حدود ۲.۷ میکروثانیه برای هر رسید عمل می‌کند (درون-پروسه، بدون شبکه و بدون I/O). در حالی که مسیر کامل در پایتون — شامل استانداردسازی JSON و امضای Ed25519 — با تأخیر P50 حدود ۲۷ میکروثانیه اجرا می‌شود. این سرعت تضمین می‌کند که هر اقدام عامل بدون افزودن تأخیر محسوس به گردش کار، قابل تأیید باشد.
این سیستم از امضاهای Ed25519 روی JSONهای استاندارد شده طبق RFC 8785 (JCS) استفاده می‌کند. فرمت رسید شامل ۲۲ فیلد است. برای مثال، یک رسید پیش‌پذیرش شامل tool_input_hash و caller_id و یک شیء verification است که وضعیت ساختار، طرحواره و امنیت را به عنوان «PASS» علامت‌گذاری می‌کند.
فشارهای رگولاتوری
این شکاف فنی با سخت‌گیرانه‌تر شدن قوانین هم‌زمان شده است. قانون هوش مصنوعی اتحادیه اروپا (EU AI Act) در ۲ اوت ۲۰۲۶ لازم‌الاجرا شد. سیستم‌های AI پرریسک، به‌ویژه در خدمات مالی، با جریمه‌هایی تا ۳۵ میلیون یورو یا ۷٪ از درآمد جهانی روبرو هستند. این قانون مستلزم ثبت وقایع، ردیابی و نظارت انسانی است، اما روش فنی دقیق آن را تعیین نکرده است.
علاوه بر این، دستورالعمل اصلاح‌شده مدیریت ریسک مدل‌ها (SR 26-2) در آوریل ۲۰۲۶، صراحتاً هوش مصنوعی عامل‌محور را از مدیریت ریسک مدل‌های استاندارد جدا کرد. این موضوع یک خلأ حاکمیتی ایجاد کرده که باید توسط الزامات ریسک عملیاتی، ریسک شخص ثالث و حفاظت از مصرف‌کننده پر شود.
در میدان فنی، این اتفاق فرض بنیادی استقرار عامل‌ها را تغییر می‌دهد. دیگر کافی نیست عاملی بسازیم که بتواند روی دکمه‌ها کلیک کند؛ صنعت باید زیرساختی بسازد که ثابت کند دقیقاً چه چیزی، چه زمانی و با چه مجوزی کلیک شده است.
توسعه‌دهندگان اکنون می‌توانند این بررسی‌ها را با استفاده از ccs-verifier در PyPI یا ccs-mcp-server در npm پیاده کنند. همچنین برای ادغام در CI، ابزار ccs-lint-action در گیت‌هاب در دسترس است. این ابزارها یک چارچوب «عدم انکار» (Non-repudiation) را بدون وابستگی‌های زمان اجرا و بدون تله‌متری فراهم می‌کنند.
گام بعدی شما
- اگر از عامل‌های AI برای دسترسی به APIهای حساس استفاده می‌کنید، لایهٔ تأیید امضاشده را جایگزین لاگ‌های متنی ساده کنید.
- استانداردهای RFC 8785 را برای استانداردسازی داده‌های ورودی و خروجی مدل‌های خود بررسی کنید.
- در معماری سیستم خود، تفکیک بین «آنچه مدل قصد انجامش را دارد» و «آنچه در لایه اجرا ثبت شده» ایجاد کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو