تصور کنید یک عامل هوش مصنوعی برای خرید بلیط هواپیما یا ثبت شکایت در یک وب‌سایت اقدام می‌کند، اما سیستم امنیتی شرکت او را به عنوان یک ربات مخرب شناسایی کرده و مسدود می‌کند. در حال حاضر عامل‌ها با یک انتخاب دوتایی و سخت مواجه‌اند: آن‌ها یا باید تظاهر کنند که یک کاربر انسانی هستند تا کارهایشان پیش برود، یا اینکه توسط سیستم‌های امنیتی شرکت‌ها مسدود شوند.
Sierra با معرفی پروتکل عامل شخصی یا Poppy، این بن‌بست را می‌شکند و برای نخستین بار هویتی رسمی و روشی استاندارد برای درخواست دسترسی به عامل‌ها تعریف می‌کند. این تحول در حالی رخ می‌دهد که صنعت به سمتی می‌رود که در آن عامل (Agent) — شبیه به یک دستیار شخصی که اجازه دارد به‌جای شما در دنیای دیجیتال خرید کند، رزرو انجام دهد یا درخواست‌های اداری ثبت کند — به‌طور مستقل امور را مدیریت می‌کند. تا پیش از این، شرکت‌ها هیچ راهی برای تشخیص یک عامل معتبر شخصی از یک ربات مخرب یا یک کاربر انسانی نداشتند. نتیجه این وضعیت، ایجاد یک شکاف امنیتی بود که در آن عامل‌ها در لباس مبدل (تظاهر به انسان بودن) فعالیت می‌کردند و کاربران هیچ کنترل دقیقی بر روی آنچه هوش مصنوعی‌شان واقعاً می‌تواند از طرف آن‌ها انجام دهد، نداشتند.
به نقل از مستندات منتشر شده، در ۹ اکتبر ۲۰۲۶، برت تیلور و کلی باوور از شرکت Sierra پیش‌نویس نسخه ۰.۱ این پروتکل را منتشر کردند. آن‌ها این ابتکار را در اوایل همان هفته، در کنار ائتلافی قدرتمند شامل Meta، Genesys، Instinct، NiCE، Rocket، Shopify، Stripe و Walmart به راه انداختند. شتاب این حرکت به‌سرعت افزایش یافت و ۳۵ شریک طراحی دیگر نیز به این گروه پیوستند، از جمله Adyen، Bank of America، Cloudflare، ElevenLabs، Mastercard، Notion، Okta، OpenAI، PayPal، Plaid، Target، Visa، Zapier، Zendesk و 1Password.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های عامل‌محور اشاره کردیم، نبودِ یک لایه شناسایی استاندارد، بزرگ‌ترین مانع برای پذیرش گسترده این فناوری در محیط‌های سازمانی بود.
پنج رکن سازنده Poppy
بر اساس بررسی مستندات وب‌سایت personalagentprotocol.org، پروتکل Poppy رویکرد «همه یا هیچ» را با پنج مکانیسم فنی مشخص جایگزین می‌کند:
- کشف (Discovery): شرکت‌ها فایلی استاندارد در مسیر
/.well-known/poppy.jsonمنتشر می‌کنند که به عامل‌ها می‌گوید چگونه باید با آن کسب‌وکار تعامل کنند. - جلسات (Sessions): عامل‌ها در ابتدا به عنوان «مهمان» وارد می‌شوند و باید صراحتاً خود را به عنوان عامل معرفی کنند، نه به عنوان یک انسان.
- ورود (Sign-in): این پروتکل برای مدیریت احراز هویت، از استاندارد OAuth در صفحه اختصاصی خود شرکت استفاده می‌کند.
- یکپارچگی چندکاناله (Cross-Channel Unity): این سیستم یک جلسه واحد را در وب‌سایت‌ها، APIها و عامل‌های اختصاصی شرکت حفظ می‌کند.
- اجرا (Execution): انجام کارها از طریق وب‌سایت‌ها، APIهای مبتنی بر OpenAPI و پروتکل زمینه مدل (MCP)، یا از طریق یک عامل شرکت صورت می‌گیرد.
حریم خصوصی و سیستم «نام مستعار»
یکی از حیاتی‌ترین ویژگی‌های Poppy نحوه مدیریت داده‌های کاربر است. تا زمانی که یک شخص به‌طور صریح وارد حساب خود نشود (Sign-in)، شرکت تنها یک شناسه پایدار (Stable ID) را می‌بیند که هیچ حاوی اطلاعات شخصی نیست.
این شناسه برای هر شرکت منحصربه‌فرد است؛ به این معنا که هویت یک کاربر توسط عامل در سرویس‌های مختلف ردیابی نمی‌شود. همچنین عامل همیشه خود را به عنوان یک هوش مصنوعی معرفی می‌کند تا شرکت اطمینان یابد که با یک انسان طرف نیست. دسترسی‌ها نیز دقیقاً محدود به «دامنه» (Scope)های اعطا شده است و می‌توان آن‌ها را فوراً لغو کرد. این تغییر، سیستم را از یک رویکرد «مبتنی بر سیاست» (Policy-based) به یک رویکرد «مبتنی بر کنترل» (Control-based) منتقل می‌کند.
نردبان دسترسی (Scope Ladder)
پروتکل Poppy یک سلسله‌مراتب مجوز تعریف می‌کند تا از دسترسی‌های بیش از حد عامل‌ها جلوگیری کند. در یک پیاده‌سازی عملی، این سیستم شبیه به یک نردبان دسترسی است:
۱. مهمان (Guest): پایین‌ترین پله. عامل‌ها می‌توانند اقدامات موجود در «لیست سفید» (Allowlist) را انجام دهند، مانند بررسی موجودی کالا یا خواندن سیاست‌های مرجوعی. این‌ها تنها اقداماتی هستند که پیش از ورود کاربر مجاز هستند.
۲. خواندنی (Read): این سطح امکان مشاهده داده‌های خصوصی را باز می‌کند، مانند مشاهده سفارشات موجود.
۳. نوشتنی (Write): بالاترین سطح دسترسی که به عامل اجازه می‌دهد روش‌های پرداخت را تغییر دهد یا سفارشات جدید ثبت کند.
اگر عاملی بدون داشتن دامنه (Scope) مورد نیاز، اقدام به انجام کاری کند، سیستم به‌صورت «بسته شکست می‌خورد» (Fail Closed)؛ به این معنی که درخواست به‌طور پیش‌فرض رد می‌شود. این سازوکار تضمین می‌کند که یک عامل مهمان نتواند به‌طور تصادفی خریدی انجام دهد یا به جزئیات حساس حساب دسترسی پیدا کند.
فشار یکپارچه در صنعت
تلاش Sierra تنها یک اقدام تک‌نفره نیست. در همان هفته‌ای که جزئیات Poppy منتشر شد، غول‌های دیگر نیز در همین مسیر حرکت کردند. در ۸ اکتبر ۲۰۲۶، Google Cloud جزئیات یک عامل جهانی برای محیط کار را منتشر کرد که دارای برنامه‌ریزی، ابزارها، کنترل‌های سخت‌گیرانه هزینه و حاکمیت بود. همچنین در ۷ اکتبر ۲۰۲۶، OpenAI یک «رابط کاربری هوشمند» (Intelligent UI) برای GPT-6 توصیف کرد که از اجزای تعاملی برای ترکیب و ساخت پاسخ‌ها استفاده می‌کند.
اگرچه محصولات متفاوت هستند، اما فشار یکسان است: عامل‌ها به راهی نیاز دارند تا خود را به عنوان «عامل» معرفی کنند. صنعت در حال فاصله گرفتن از ربات‌هایی است که «تقلیدکننده مرورگر» هستند و به سمت یک مدل شناسایی ساختاریافته و مبتنی بر API حرکت می‌کند.
زیرساخت فنی
پروتکل Poppy یک سیلو یا سیستم انحصاری نیست. این پروتکل تحت لایسنس Apache 2.0 منتشر شده و بر استانداردهای تثبیت‌شده وب بنا شده است:
- استفاده از OAuth و JWT برای مجوزهای امن.
- استفاده از HTTPS برای انتقال رمزنگاری‌شده داده‌ها.
- به‌کارگیری OpenAPI و MCP برای تعریف ابزارها.
- یکپارچگی تکمیلی با پروتکل تجارت جهانی (UCP).
در اجلاس Sierra، شرکت Rocket و مدل Muse متعلق به Meta، یک جریان پیش‌تأیید وام مسکن را با استفاده از همین مکانیسم‌ها به‌صورت زنده نمایش دادند.
بررسی عمیق: یک پیاده‌سازی نمونه
برای درک عملی نحوه کارکرد این سیستم، می‌توان به یک مدل ساده TypeScript از یک «دروازه کشف» نگاه کرد. در این مدل، یک خرده‌فروش فرضی (Acme Retail) یک سند کشف منتشر می‌کند. عامل این سند را بارگذاری کرده و یک جلسه مهمان را آغاز می‌کند.
سند کشف: در یک تنظیمات واقعی Poppy، فایل /.well-known/poppy.json قوانین را تعریف می‌کند. در نسخه نمونه ما، این موارد شامل است:
- شناسه شرکت:
acme-retail - نام شرکت:
Acme Retail (example company) - کانال‌ها: وب‌سایت، API و عامل.
- مجاز برای مهمان:
checkStockوreturnsPolicy. - دامنه‌ها (Scopes): مهمان، خواندنی و نوشتنی.
- روش ورود: OAuth.
شناسایی عامل: عامل خود را با یک agentId (مثلاً muse-like-agent-example) و یک userPseudonym (مثلاً usr_acme_7f3a9c) معرفی می‌کند. نام مستعار به شرکت اجازه می‌دهد کاربر بازگشتی را شناسایی کند بدون اینکه نام یا ایمیل او را بداند. agentId صراحتاً بیان می‌کند چه کسی در حال اقدام است، در حالی که نام مستعار، رابطه با مشتری بازگشتی را بدون نیاز به اطلاعات شناسایی شخصی (PII) مدیریت می‌کند.
خط زمانی اجرا: وقتی عامل اقدام به انجام کارهایی می‌کند، سیستم یک ترتیب بررسی سخت‌گیرانه را دنبال می‌کند: ابتدا اقدامات ناشناخته رد می‌شوند، سپس لیست سفید مهمان بررسی می‌شود و در نهایت حداقل دامنه مورد نیاز تأیید می‌گردد.
- فاز مهمان: عامل می‌تواند با موفقیت
checkStock(با نتیجه «SKU-1001 موجود است: ۱۴ عدد») وreturnsPolicy(با نتیجه «مرجوعی ۳۰ روزه با رسید») را اجرا کند. اما هنگام تلاش برایplaceOrderیاseeOrdersرد می‌شود، زیرا این‌ها در لیست سفید مهمان نیستند. - فاز خواندنی: پس از یک رضایت OAuth شبیه‌سازی شده، دامنه به «read» ارتقا می‌یابد. اکنون عامل می‌تواند
seeOrdersرا اجرا کند (با نتیجه «۲ سفارش باز: #۴۸۱۲، #۴۸۱۹») اما همچنان برایplaceOrderرد می‌شود زیرا به دامنه «write» نیاز دارد. - فاز نوشتنی: پس از تأیید بیشتر، عامل در نهایت می‌تواند
placeOrder(با نتیجه «سفارش #۴۸۲۰ برای SKU-1001 ثبت شد») وchangePayment(با نتیجه «روش پرداخت به‌روزرسانی شد») را اجرا کند. - فاز لغو: اگر کاربر دسترسی را لغو کند، عامل به پله مهمان بازگردانده می‌شود. او دوباره می‌تواند موجودی را چک کند، اما تمام اقدامات در سطح حساب به‌صورت پیش‌فرض مسدود (Fail Closed) می‌شوند.
جایگاه مدل نمونه: ذکر این نکته ضروری است که یک یکپارچگی واقعی Poppy به‌طور قابل توجهی پیچیده‌تر از یک دموی TypeScript است. یک سیستم عملیاتی نیازمند موارد زیر است:
- توکن‌های واقعی: به‌جای رشته‌های ساده، از JWTها با تاییدیه صدور، انقضا و مخاطب (Audience) استفاده می‌کند که یک تأییدکننده بتواند به آن‌ها اعتماد کند.
- کشف غنی: فایل
.jsonواقعی حاوی نقاط انتهایی (Endpoints) کامل برای وب‌سایت، API و عامل‌های شرکت است و بسیار فراتر از پنج فیلد ساده است. - تداوم چندکاناله: پروتکل تضمین می‌کند که یک جلسه در رابط‌های مختلف تداوم یابد، در حالی که یک مدل نمونه در یک فرآیند واحد باقی می‌ماند.
- سیاست محصول: پروتکل «چگونگی» (How) کنترل‌ها را فراهم می‌کند، اما شرکت همچنان «چیستی» (What) قوانین را تعریف می‌کند. برای مثال، یک شرکت هواپیمایی ممکن است به هر عاملی اجازه جستجوی پرواز را بدهد اما برای رزرو، تأیید خاصی را الزامی کند.
تحلیل: پایان جنگ ربات‌ها
برای کاربر عادی، این به معنای پایان بازی «موش و گربه» است که در آن وب‌سایت‌ها ابزارهای هوش مصنوعی را مسدود می‌کردند. به‌جای جنگ با ربات‌ها، شرکت‌ها اکنون می‌توانند قوانین تعامل را تعیین کنند. احتمالاً در آینده، شما به هوش مصنوعی خود دسترسی «فقط خواندنی» برای حساب بانکی و دسترسی «نوشتنی» برای لیست خریدتان می‌دهید.
برای توسعه‌دهندگان، این موضوع بار امنیتی را از دوش عامل به دوش پروتکل منتقل می‌کند. با استفاده از سند کشف، توسعه‌دهندگان دیگر مجبور نیستند حدس بزنند API یک شرکت چگونه کار می‌کند یا ریسک مسدود شدن به دلیل درخواست‌های زیاد را بپذیرند. این اتفاق، وب را به یک API خوانا برای هوش مصنوعی تبدیل می‌کند.
این یک حرکت بنیادین به سمت چیزی است که برخی آن را «عصر هویت» در هوش مصنوعی می‌نامند. در ۱۹ سپتامبر، در مقاله‌ای با عنوان The Computer Is Becoming an API for AI، پیش‌بینی شد که سال ۲۰۲۷ زمانی است که عامل‌ها دارای هویت شوند: حساب‌های اختصاصی، اعتبارنامه‌ها، بودجه‌ها، مجوزها و ردپاهای حسابرسی (Audit Trails). Poppy نخستین تلاش جدی برای تبدیل این فرآیند به یک استاندارد خسته‌کننده، امن و پیش‌بینی‌پذیر است.
برای مشاهده این سازوکار در عمل، می‌توانید پیاده‌سازی ساده‌شده این دروازه کشف را در گیت‌هاب در مسیر bobbyhalljr/tiny-poppy-gate بررسی کنید.
گام بعدی شما
- اگر توسعه‌دهنده هستید، مستندات
personalagentprotocol.orgرا بررسی کنید تا متوجه شوید چگونه می‌توانید وب‌سایت خود را برای پذیرش عامل‌ها آماده کنید. - در تنظیمات ابزارهای عامل‌محور خود، به دنبال قابلیت‌های مدیریت Scope یا مجوزهای سطح‌بندی شده باشید.
- بررسی کنید که آیا سرویس‌های فعلی شما از MCP برای تعریف ابزارها استفاده می‌کنند یا خیر.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو