اگر امروز یک محصول SaaS می‌سازید، احتمالاً قیف جذب کاربر شما برای مهم‌ترین مشتری جدیدتان یعنی «عامل هوش مصنوعی» کاملاً شکسته است. در ۱۶ ژوئن ۲۰۲۶، شرکت WorkOS پروتکل Auth.md را منتشر کرد؛ پروتکلی که به عامل‌های خودگردان اجازه می‌دهد بدون نیاز به مرورگر، فرم‌های ثبت‌نام یا حضور یک انسان در حلقه (Human-in-the-loop)، در سرویس‌ها احراز هویت کنند.
به مدت دو دهه، اینترنت برای انسان‌ها ساخته شد. ما APIها و جریان‌های احراز هویت را بر این فرض طراحی کردیم که یک شخص روی دکمه‌ای کلیک می‌کند، ایمیل تایید ثبت‌نام را می‌خواند یا یک کلید API را کپی و جای‌گذاری می‌کند. این مدل انسان‌محور، دیواری بلند مقابل عامل‌های هوش مصنوعی ایجاد می‌کند؛ طبق گزارش WorkOS، وقتی یک عامل با یک API مواجه می‌شود و خطای ۴۰۱ (عدم دسترسی) دریافت می‌کند، معمولاً یا تسلیم می‌شود یا کاربر انسان را مجبور می‌کند تا دستی وارد عمل شود. این دخالت دستی — یعنی اینکه از یک انسان بخواهیم کاری را که در حال انجام آن است متوقف کند تا یک کلید را کپی کند — شبیه به بازگشت به سال ۲۰۱۴ است و استقلال و خودگردانی سیستم را نابود می‌کند.
Auth.md یک مفهوم (Primitive) جدید برای عصر عامل‌ها پیشنهاد می‌دهد. این پروتکل در واقع یک فایل ساده Markdown است که در دامنه سایت منتشر می‌شود (مثلاً https://yourapp.com/auth.md). عامل‌ها می‌توانند این فایل را بخوانند و تجزیه (Parse) کنند تا بفهمند چگونه باید ثبت‌نام کنند و هویت خود را ثابت نمایند. این یک دست‌انداز اختصاصی یا یک ادغام محدود به یک فروشنده خاص نیست، بلکه روشی استاندارد است تا یک موجود خودگردان، خود را به سرویسی معرفی کند که پیش از این او را نمی‌شناخته است.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی زیرساخت‌های مدل‌های زبانی اشاره کردیم، حذف لایه‌های رابط کاربری (UI) برای افزایش سرعت استنتاج ضروری است. استنتاج (Inference) — که مثل لحظه‌ی خودِ آشپزی است، نه دوره‌ی آموزش آشپز — در دنیای عامل‌ها باید بدون توقف‌های انسانی رخ دهد.
مبانی پروتکل
بر اساس مستندات WorkOS، این پروتکل باز (Open) است و محدود به کاربران این شرکت نیست. هر اپلیکیشنی می‌تواند یک فایل auth.md منتشر کند و هر عاملی می‌تواند آن را بخواند. این پروتکل برای جلوگیری از نیاز به رمزنگاری‌های جدید یا توزیع کلیدهای پیچیده، بر استانداردهای موجود تکیه دارد:
- OAuth 2.0 و OIDC: به عنوان زیربنای اعتبارنامه‌های نهایی که در پایان فرآیند صادر می‌شوند.
- Protected Resource Metadata (RFC 9728): که برای کشف سرویس‌ها (Discovery) مورد استفاده قرار می‌گیرد.
- JWT-based identity assertions: که برای تایید هویت به کار می‌روند.
در نهایت، اعتبارنامه‌های استاندارد OAuth از این فرآیند خارج می‌شوند. بخش هوشمندانه این سیستم در لایه‌ی «کشف» و دو جریانی است که موارد شکست OAuth را مدیریت می‌کنند؛ چرا که OAuth سنتی همیشه فرض می‌کرد یک انسان در حلقه حضور دارد.
دو جریان احراز هویت
برای حل مشکل «حضور انسان در حلقه»، Auth.md دو مسیر ثبت‌نام مجزا معرفی می‌کند که هر دو در نهایت به اعتبارنامه‌های OAuth محدود (Scoped) و قابل ابطال ختم می‌شوند:
- تاییدشده توسط عامل (Agent Verified): این جریان از یک ارائه‌دهنده معتبر استفاده می‌کند (هر پلتفرمی که عامل‌هایش به نمایندگی از کاربران احراز هویت شده عمل می‌کنند). ارائه‌دهنده یک تاییدیه هویت — که به عنوان ID-JAG شناخته می‌شود — را امضا می‌کند تا صحت هویت کاربر را تضمین کند. عامل این تاییدیه را به نقطه انتهایی
agent-authسرویس می‌فرستد. سرویس سپس JWT را در برابر JWKS ارائه‌دهنده تایید کرده و یک رکورد کاربر را به صورت JIT (در لحظه نیاز) ایجاد می‌کند. این فرآیند از نظر ساختاری دقیقاً شبیه به JIT-provisioning در Google Sign-In است، با این تفاوت که به جای مرورگر، یک عامل به عنوان واسط اعتماد عمل می‌کند. - ادعای کاربر (User Claimed): این مسیر زمانی استفاده می‌شود که هیچ تاییدیه از سوی ارائه‌دهنده معتبر وجود ندارد. در این حالت، اپلیکیشن یک توکن ادعا (Claim Token) صادر کرده و برای کاربر یک لینک یک‌بار مصرف می‌فرستد یا یک کد ۶ رقمی (OTP) را نمایش می‌دهد. سپس عامل، پیوند نهایی (Binding) را به نمایندگی از کاربر تکمیل می‌کند. اگرچه این روش نیاز به مدیریت وضعیت (State) بیشتری دارد، اما در نهایت منجر به همان اعتبارنامه‌ی محدود و قابل ابطال می‌شود که به یک کاربر واقعی متصل است.
فراتر از احراز هویت: چرخش زیرساختی
این پروتکل بخشی از یک تغییر گسترده‌تر به سمت زیرساخت‌های «عامل-محور» است. پذیرش این واقعیت که «عامل‌ها مشتری جدید شما هستند»، شعار قدیمی استارتاپ‌ها یعنی «مشتری‌ات را بشناس» را وارونه می‌کند. سال‌ها مشتری، انسانی بود که با مرورگر وارد می‌شد؛ اما اکنون موجودیتی که به API شما درخواست می‌زند، یک فرآیند خودگردان است که به نمایندگی از یک انسان اجرا می‌شود.
این تغییر از نظر مقیاس شبیه به ظهور TCP/IP است. همان‌طور که اینترنت اولیه مفاهیمی مثل TCP، IP و HTTP را تعریف کرد تا ماشین‌ها بتوانند با یکدیگر صحبت کنند، Auth.md هم مفهوم (Primitive) شناسایی عامل‌ها را تعریف می‌کند. این رویکرد طراحی در حال حاضر در چندین ابزار تخصصی پیاده‌سازی شده است:
- MeshWire: به گونه‌ای طراحی شده است که عامل‌ها بتوانند یکدیگر را در جلسات (Sessions) مختلف کشف کرده و به هم متصل شوند. این امر نیاز مهندسان به سیم‌کشی دستی یک گراف در فایل‌های پیکربندی (Config) را از بین می‌برد. برای مثال، عاملی در یک جلسه Copilot CLI می‌تواند بدون دانش قبلی از وجود عامل دیگر، او را در یک جلسه متفاوت در شبکه پیدا کرده و با او صحبت کند. این ابزار مشکل «اتصال تک‌تک عامل‌ها» را حل می‌کند.
- Hookflows: این پلتفرم به جای انسان‌ها، حاکمیت (Governance) را برای عامل‌ها فراهم می‌کند. یک «هوک‌فلو» به عامل اجازه می‌دهد در یک نقطه بازرسی (Checkpoint) تعریف شده، یک قلاب (Hook) را فعال کند. سپس پلتفرم می‌تواند بدون اینکه انسانی ترمینال را تماشا کند، اقدام را مشاهده، تایید یا مسدود کند. این سیستم قراردادهای رفتاری را از طریق پاسخگویی عامل-به-عامل در یک ناوگان از عامل‌های خودگردان اجرا می‌کند.
- رمزنگاری محتوا (Content Encryption): این فناوری تضمین می‌کند که محتوا فقط توسط عامل‌هایی که دسترسی تاییدشده دارند مصرف شود. مدل آن ساده است: عامل اعتبارنامه‌ها را ارائه می‌دهد، محتوای رمزگشایی شده را دریافت می‌کند و روی آن عمل می‌کند. در اینجا هیچ جریان ورود انسانی وجود ندارد زیرا مصرف‌کننده اصلی، خودِ عامل است.
مسئله حل‌نشده: صورت‌حساب عامل‌ها
در حالی که Auth.md لایه‌ی هویت را حل می‌کند، شکاف بزرگی را در اقتصاد فعلی SaaS آشکار می‌کند: پرداخت‌ها. بیشتر نرم‌افزارها فرض می‌کنند انسانی کارت اعتباری خود را در صفحه قیمت‌ها وارد می‌کند. یک عامل خودگردان نمی‌تواند جدول قیمت‌ها را تحلیل کند، یک پلن را انتخاب کند یا فرم کارت اعتباری را پر نماید.
این موضوع چالشی درجه‌دوم برای توسعه‌دهندگان ایجاد می‌کند. «سفر مشتری» در حال حاضر شکل انسانی دارد و به محض اینکه مشتری یک عامل باشد، قیف جذب کاربر می‌شکند. سوالات حیاتی هنوز بی‌پاسخ‌اند:
- هزینه APIهای عامل را چه کسی پرداخت می‌کند؟ کاربر نهایی یا پلتفرم ارائه‌دهنده عامل؟
- سرویس چگونه تشخیص دهد کدام بافت صورت‌حساب سازمانی (Billing Context) باید به اعتبارنامه‌ی صادر شده برای یک فرآیند خودگردان متصل شود؟
حل مسئله پرداخت‌های عامل-به-سرویس، گام بعدی و فوری پس از تبدیل احراز هویت به یک استاندارد است.
تحلیل تحریریه
شرکت WorkOS با نام‌گذاری این دسته‌بندی — «عامل‌ها مشتری جدید شما هستند» — توسعه‌دهندگان را مجبور می‌کند تا از نگاه به هوش مصنوعی به عنوان یک «قابلیت» (Feature) دست بردارند و آن را به عنوان «کاربر اصلی» ببینند. داشتن این واژگان، گفتگو را تغییر می‌دهد. موضوع دیگر «یک ابزار توسعه‌دهنده با API» نیست، بلکه «زیرساخت عامل-محور» است.
برای خواننده، این بدان معناست که مزیت رقابتی در حال تغییر است. شرکت‌هایی که APIهای خود را برای کشف توسط عامل‌ها و احراز هویت خودگردان بهینه کنند، ترافیکی را جذب خواهند کرد که در حال حاضر به دلیل دیوارهای خطای ۴۰۱، از سایت‌های سنتی «برمی‌گردند» (Bounce). در دنیای عامل‌های خودگردان، اصطکاک ایجاد شده توسط رابط کاربری انسانی در حال تبدیل شدن به یک نقطه ضعف (Liability) است.
اگر احساس می‌کنید به سمت این رویکرد طراحی کشیده می‌شوید، بدانید که عقب نیستید، بلکه همین حالا در قلب این تحول هستید. این تغییر در حال رخ دادن است و یک هدف دوردست برای سال ۲۰۳۰ نیست. برای اینکه ببینید سرویس شما از نگاه عاملی که سعی دارد وارد شود چگونه به نظر می‌رسد، می‌توانید با پیاده‌سازی مشخصات Auth.md در گیت‌هاب و انتشار اولین فایل auth.md خود شروع کنید.
گام بعدی شما
- اگر توسعه‌دهنده API هستید، بررسی کنید چند درصد از درخواست‌های ۴۰۱ شما مربوط به ابزارهای اتوماسیون است.
- مستندات Auth.md را در گیت‌هاب مطالعه کنید و اولین فایل
auth.mdخود را برای تسهیل دسترسی عامل‌ها منتشر کنید. - استراتژی قیمت‌گذاری خود را برای «مصرف‌کننده غیرانسانی» بازنگری کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو