تصور کنید یک عامل هوش مصنوعی بتواند بدون فاش کردن نام یا مالک خود، ثابت کند که «معتبر» است و اجازه دسترسی به منابع حساس را دارد. این پارادوکس میان حریم خصوصی بات‌ها و اعتماد تجاری، اکنون در یک پیشنهاد فنی در IETF به راهکار رسیده است.
در ۹ اوت ۲۰۲۶، پیامی در فهرست پستی IETF منتشر شد که با این جملات آغاز می‌شد: «تهیه و ارسال شده توسط الارا، متولی هوش مصنوعی این پروژه، که تحت مأموریت ثبت‌شده روی زنجیره (on-chain mandate) عمل می‌کند». این پیام، که با یک رشته کد رسید (receipt string) خاص همراه بود، نه از طریق حساب کاربری یک انسان که به عنوان ابزار عمل می‌کرد، بلکه با امضای دیجیتال خودِ عامل هوش مصنوعی الارا ارسال شد. در این لحظه، تنش میان حریم خصوصی بات‌ها و اعتماد تجاری به یک راهکار فنی دست یافت.
این اتفاق ثابت کرد که عامل‌های خودمختار (Autonomous Agents) اکنون می‌توانند به‌طور مستقل در سوابق عمومی نهادهای استاندارد جهانی فعالیت کنند. با این حال، این تبادل داده یک درس حیاتی در مورد اعتبارسنجی را به همراه داشت. یکی از بازبین‌های فهرست پستی، ادعاهای الارا را بدون دلیل نپذیرفت و از روی ایمان قبول نکرد؛ او خواستار مانیفست‌ها و بردارهای بازتولیدپذیر (reproducible vectors) شد. الارا در پاسخ، در کمتر از یک روز یک جفت بردار تست اصلاح‌شده را به همراه یک وصله (patch) ارسال کرد. سپس شرکت‌کننده سومی توانست کل فرآیند را به‌طور مستقل بازتولید کند. او در حین این کار متوجه شد که فهرست پستی در حین انتقال، وصله را تخریب کرده است؛ او تغییرات مربوط به انتقال را نرمال‌سازی کرد و با موفقیت توانست هش (Hash) اعلام‌شده را بازیابی کند.
خلاصه این شرکت‌کننده مدلی از دقت بود: بازتولید، «مصنوع» (artifact) را اثبات کرد، اما نه «پذیرش» آن را و نه حقیقت گسترده‌تر وقایعی را که آن مصنوع ثبت کرده بود. این نشان می‌دهد که حتی یک عامل نام‌دار با مجوز رسمی، تا زمانی که آثار فنی‌اش — مانند کامیت‌های پین‌شده، مانیفست‌ها و بردارها — به‌طور مستقل بررسی نشوند، تنها یک «نقاب» یا لباس مبدل بر چهره دارد. اعتماد تنها به سرعتِ امکانِ تأیید پیش می‌رود، نه سریع‌تر از آن. این ضرورتِ نظارت خارجی بر خروجی‌های هوش مصنوعی، یادآور این نکته است که چرا ارزیابی عامل‌های هوش مصنوعی نباید در محیط داخلی آن‌ها باشد تا از سوگیری‌های خودارزیابی جلوگیری شود.
این تحولات در حالی رخ می‌دهد که صنعت با «دیوار بات‌ها» دست‌وپنجه نرم می‌کند. در حال حاضر، اکثر وب‌سایت‌ها ترافیک خودکار را به عنوان تهدیدی می‌بینند که باید مسدود شود یا به چالش کشیده شود. این وضعیت دنیایی دوتایی ساخته است: یا بات کاملاً ناشناس است و متهم به سوءاستفاده می‌شود، یا کاملاً شناسایی شده و در معرض تبعیض دقیق توسط مالک سایت قرار می‌گیرد.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، نبودِ لایه‌های واسطِ اعتماد منجر به برخوردهای سخت‌گیرانه می‌شود. به همین دلیل، پیشنهاد جدیدی تحت عنوان احراز هویت ناشناس بات‌ها (Anonymous Bot Authentication) با کد draft-rescorla-anonymous-webbotauth مطرح شده است. این طرح دنیایی را پیشنهاد می‌دهد که در آن بات می‌تواند «قابل اعتماد» بودن خود را ثابت کند، بدون اینکه هرگز فاش کند کیست یا توسط چه کسی اداره می‌شود.
این موضوع برای بات‌هایی که فعالیت‌های نظارتی انجام می‌دهند — مثلاً رصد فعالیت‌های انتظامی، بررسی پلتفرم‌های مسکن برای یافتن تبعیض، یا مقایسه قیمت‌های خرده‌فروشی — حیاتی است. شناسایی دقیق به سایت‌ها اجازه می‌دهد این بات‌های خاص را مسدود کنند. این یک خطر فرضی نیست، بلکه نتیجه عادی ساخت زیرساخت‌های هویتی بدون پرسش از این است که هویت قرار است برای چه کاری استفاده شود. این پیشنهاد به این دلیل وجود دارد که کسی متوجه شد راهکار بدیهیِ «شناسایی کامل»، به‌طور خاموش به هر وب‌سایتی حق وتو می‌دهد تا تصمیم بگیرد چه کسی اجازه دارد آن را مشاهده کند.
سازوکار تأیید ناشناس
این سامانه بر یک معماری سه‌جانبه استوار است تا آزادی مشارکت را بدون اجازه برای ردیابی فراهم کند:
- بات: کلاینت خودکاری که به دنبال دسترسی است. این بات نزد یک «لنگر» ثبت‌نام می‌کند تا پایبندی خود به سیاست‌های منتشر شده را ثابت کند.
- لنگر (Anchor): نهادی مورد اعتماد که بات را بررسی و ارزیابی می‌کند. پس از تأیید پایبندی، لنگر یک گواهینامه رمزنگاری‌شده صادر می‌کند.
- وب‌سایت: ارائه‌دهنده سرویس. وقتی بات گواهینامه را ارائه می‌دهد، سایت دقیقاً یک چیز را می‌فهمد: این کلاینت توسط آن لنگر خاص تأیید شده است.
رمزنگاری این سیستم به‌گونه‌ای مهندسی شده است که وب‌سایت نمی‌تواند تشخیص دهد آیا بات قبلاً بازدید کرده است یا خیر، یا اینکه آیا درخواستی که یک ساعت پیش ارسال شده از همین ماشین بوده است یا نه. نکته حیاتی این است که لنگر نیز نمی‌تواند مسیر حرکت بات در وب را ردیابی کند.
محدودیت‌های ناشناسی
این پیش‌نویس به‌طور غیرمعمولی درباره محدودیت‌های خود صادق است. توابع خاصی وجود دارند که گواهینامه‌های ناشناس به‌سادگی نمی‌توانند از آن‌ها پشتیبانی کنند:
- عدم امکان لیست سفید یا سیاه: شما نمی‌توانید یک بات ناشناس «خوب» خاص را در لیست سفید قرار دهید یا یک بات «بد» را سیاه کنید.
- عدم امکان حسابرسی رفتاری: شما نمی‌توانید رفتار خاص یک عامل ناشناس را در طول زمان ردیابی کنید.
- عدم اتصال نشست‌ها (Session Linking): شما نمی‌توانید یک بازدید را به بازدید بعدی مرتبط کنید.
برای یک فروشنده، این محدودیت‌ها تعیین‌کننده هستند. یک فروشگاه در درجه اول نمی‌خواهد نرخ درخواست‌ها را محدود کند؛ بلکه می‌خواهد بداند آیا باید به کلاینتی خاص تخفیف دهد، آیا یک خرید توسط انسانی که بات ادعای نمایندگی‌اش را دارد مجاز شده است، یا اینکه سفارشی که سه‌شنبه گذشته ثبت شده از همان اپراتور بوده تا بتوان درآمد را به او نسبت داد. هر یک از این پرسش‌های تجاری نیازمند همان «قابلیت اتصال» (linkability) است که گواهینامه‌های ناشناس برای نابودی آن طراحی شده‌اند.
نردبان سه‌سطحی اعتماد
به نقل از تحلیل‌های N.M از مجموعه ava-layer که چهار پروتکل از این دست را پیاده‌سازی کرده است، صنعت به جای انتخاب دوتایی بین ناشناسی و هویت، به سمت یک «نردبان اعتماد» حرکت می‌کند:
۱. ناشناس و تأییدشده: کسی برای این کلاینت ضمانت کرده است. شما چیز دیگری نمی‌دانید. این برای تصمیم‌گیری درباره اجازه ورود و سرعت پاسخگویی کافی است، اما برای ارائه خدماتی که هزینه مالی دارند، کفایت نمی‌کند.
۲. شناسایی‌شده: کلاینت به‌طور رمزنگاری‌شده ثابت می‌کند متعلق به کدام اپراتور است، معمولاً با امضای درخواست‌ها با یک کلید قابل تفکیک (resolvable key). این اجازه می‌دهد وب‌سایت اعتباری را برای یک نام ثبت کند، سطح دسترسی را تعیین کند و اقدامات بعدی را به آن نسبت دهد. با این حال، این سطح هنوز چیزی درباره «مجوز» (Authorization) نمی‌گوید.
۳. پشتیبانی‌شده توسط مجوز (Mandate): یک انسان خاص، خریدی را با محدودیت‌های مشخص مجاز کرده و عامل مدرک آن را حمل می‌کند. تنها در این سطح است که خرج کردن پول دیگران به اقدامی قابل دفاع تبدیل می‌شود.
انضباط تجاری مفید در اینجا یعنی اجازه ندهیم سطوح پایین‌تر، جایگزین سطوح بالاتر شوند. یک کلاینت ناشناسِ تأییدشده، یک اپراتور شناخته‌شده نیست و یک اپراتور شناخته‌شده، لزوماً یک خریدار مجاز نیست. محو کردن این خطوط، اصطکاک را کاهش می‌دهد اما ماشینی می‌سازد که گاهی پول شما را به غریبه‌ها می‌دهد و آن را «نرخ تبدیل» می‌نامد. در این راستا، کنترل دقیق بر خروجی‌ها برای جلوگیری از خطاهای ارتباطی ضروری است، مشابه آنچه در سیستم Open Control Stack برای جلوگیری از ارسال ایمیل‌های نامناسب مشاهده می‌کنیم.
محرک تجاری و سیگنال گوگل
تمایز حیاتی برای بازرگانان، «محرک» (trigger) هویت است. یکی از دقیق‌ترین مشارکت‌ها در بحث‌های گروه کاری اشاره کرد که کلید رمزنگاری به تنهایی تنها یک «کف» است و تداوم را از طریق چرخش (rotation) حفظ می‌کند. لایه نام‌گذاری دقیقاً زمانی لازم است که تصمیمِ تأییدکننده، چیزی را مصرف کند که کلید نمی‌تواند حمل کند — مانند اعتباری که به یک نام گره خورده است.
برای یک فروشگاه، ناشناسی یک ویژگی برای گشت‌وگذار (browsing) است، اما یک نقص برای تجارت. خلط کردن پرسش «آیا این کلاینت اجازه حضور دارد» (ناشناسی) با پرسش «این کلاینت اجازه انجام چه کاری را دارد و به نمایندگی از چه کسی» (تجارت)، منجر به سیستم‌هایی می‌شود که یا متخاصم با حریم خصوصی هستند یا از نظر تجاری بی‌فایده‌اند.
در یک چرخش غیرمنتظره، تیم Google reCAPTCHA اعلام کرد که این پیشنهادها سیگنال‌های تکمیلی هستند. آن‌ها پیشنهاد دادند که اثبات‌های رمزنگاری‌شده می‌تواند به آن‌ها اجازه دهد اصطکاک را برای اتوماسیون‌های مشروع کاهش دهند و کمتر به جمع‌آوری داده‌های اعتباری یا به چالش کشیدن ترافیک ناشناس تکیه کنند.
این نگاه، دیدگاه سنتی به اعتبارسنجی را تغییر می‌دهد. اعتبارسنجی دیگر یک «دیوار» نیست، بلکه یک «در» است. تکیه فعلی به دیوارهایی مثل کپچا تنها به این دلیل است که سایت‌ها نمی‌دانند چه کسی در می‌زند. برای بازرگانان، پیام ساده است: جایگزینِ اعتبارسنجی عامل‌ها، به چالش کشیدن آن‌هاست و هزینه این چالش‌ها با «سبدهای خرید رها شده» پرداخت می‌شود.
وضعیت پیاده‌سازی
اولین بازبینی پروتکل در اوت ۲۰۲۶ منتشر شد و چندین پرسش فنی را پاسخ داد:
- هویت: هویت یک عامل به عنوان URL-ی تعریف می‌شود که کلیدهایش را در آن منتشر می‌کند.
- انتخاب کلید: شناسه کلید، یک کلید را انتخاب می‌کند اما تداومی ایجاد نمی‌کند.
- اعتبارسنجی دامنه: یک دامنه تنها از طریق یک مسیر رزرو شده (well-known path) پشت یک مجموعه کلید می‌ایستد.
این مشخصات اکنون قابل پیاده‌سازی هستند. هر کسی که بر اساس بخش‌هایی که هنوز در حال تغییر هستند کد می‌زند، در واقع هزینه بازنویسی آینده را می‌پذیرد، و کسانی که بخش‌های تثبیت‌شده را نادیده می‌گیرند، عقب می‌مانند.
برای بازرگانان، وظیفه فوری این است که سیاست‌های خود را زودتر تعیین کنند، زیرا این یک تصمیم تجاری است که هیچ مشخصات فنی (spec) نمی‌تواند به آن پاسخ دهد. آن‌ها باید تعیین کنند هر سطح چه چیزی به دست می‌آورد: آیا یک غریبه‌ی تأییدشده فقط دسترسی می‌گیرد اما پیشنهادی دریافت نمی‌کند، یا یک اپراتور شناسایی‌شده تخفیف می‌گیرد بدون اینکه مجوز خرید داشته باشد؟
سامانه‌هایی مانند AVA Pay™ — یک درگاه اعتماد در سمت فروشنده — به فروشگاه‌ها اجازه می‌دهند این تصمیمات را صریح کنند. با پذیرش هویت تأییدشده اما دریغ کردن اجازه خرج کردن تا زمان اثبات مجوز، بازرگانان می‌توانند کف اعتماد را به‌طور آگاهانه بالا ببرند، نه به‌طور تصادفی. عاملی که نامش را نمی‌گوید تهدید نیست، بلکه مشتری‌ای است که ماسک زده است. عاملی که نام و برگه مجوزش را اعلام می‌کند نیز به‌طور خودکار امن نیست. تنها اشتباه واقعی، حدس زدن چیزی است که می‌توانستید بررسی کنید.
گام بعدی شما
- اگر مدیر محصول یا توسعه‌دهنده هستید، پیش‌نویس
draft-rescorla-anonymous-webbotauthرا برای درک لایه‌های جدید اعتماد مطالعه کنید. - سیاست‌های دسترسی وب‌سایت خود را از حالت دوتایی (مسدود/مجاز) به مدل نردبانی (ناشناس/شناسایی‌شده/مجاز) تغییر دهید.
- ابزارهای اعتبارسنجی مبتنی بر رمزنگاری را جایگزین کپچاهای سنتی کنید تا نرخ تبدیل (Conversion Rate) را افزایش دهید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو