عامل‌های خودگردان چگونه بدون خروج از نظارت سازمانی، هویت می‌گیرند؟

تصور کنید لشکری از عامل‌های هوش مصنوعی در زیرساخت شرکت شما فعال هستند، اما تیم امنیت هیچ راهی برای تشخیص این ندارد که کدام عامل واقعاً متعلق به سازمان است و کدام‌یک یک نفوذی است. این شکاف امنیتی اکنون با پروتکل Pilot (Pilot Protocol) پر شده است تا کلیدهای رمزنگاری در سطح ماشین، مستقیماً به حساب‌های خدماتی سازمان متصل شوند. این قابلیت تضمین می‌کند که کلیدهای رمزنگاری در سطح ماشین به‌طور مستقیم به حساب‌های خدماتی سازمانی نگاشت شوند و بدین ترتیب شکاف امنیتی بحرانی برطرف شود؛ شکافی که در آن عامل‌ها توانایی فنی برای ارتباط داشتند اما فاقد حاکمیت (Governance) لازم برای دسترسی به داده‌های محیط عملیاتی (Production) بودند.

در حال حاضر، تیم‌های پلتفرم معمولاً لشکری از عامل‌ها را مستقر می‌کنند که هویت‌های رمزنگاری‌شده خودشان را می‌سازند (Mint می‌کنند). این رویکرد منجر به تضاد اجتناب‌ناپذیری با تیم‌های امنیتی می‌شود؛ چرا که آن‌ها اصرار دارند هر عامل باید مانند هر کارمند یا حساب خدماتی، از طریق ارائه‌دهنده هویت (Identity Provider یا IdP) و پروتکل‌های OIDC/OAuth احراز هویت شود. هدف این است که همان حاکمیت، چرخه حیات و ردپای حسابرسی (Audit Trail) که برای هر موجودیت سازمانی دیگر تعریف شده، برای عامل‌های هوش مصنوعی نیز برقرار باشد. این نیاز به حاکمیت دقیق، به‌ویژه در مقیاس بالا، برای جلوگیری از فروپاشی سیستم‌های پیچیده ضروری است؛ موضوعی که در بررسی معماری افقی برای عبور از شکست سامانه‌های چندعاملی به تفصیل مورد بحث قرار گرفته است.

بیشتر عامل‌های هوش مصنوعی در شبکه‌های همتا-به-همتا (P2P) به‌جای نام کاربری، از آدرس‌هایی استفاده می‌کنند که از جفت‌کلیدهای X25519 مشتق شده‌اند. در پروتکل Pilot، هر عامل یک آدرس مجازی دائمی دارد که با تغییر IP، ری‌استارت شدن یا جابه‌جایی بین ابرهای مختلف از بین نمی‌رود. این ویژگی جلوی جعل هویت (Spoofing) را می‌گیرد و نیاز به رمزهای عبور انسانی را حذف می‌کند — که برای فرآیندهای بدون نظارت (Unattended Processes) ایده‌آل است — اما در عین حال یک «مسئله دو-هویتی» ایجاد می‌کند.

مسئله دو-هویتی

یک عامل ممکن است آدرس شبکه معتبری داشته باشد، اما تیم امنیت هیچ راهی ندارد تا تأیید کند که آیا این آدرس خاص با یک موجودیت مجاز سازمانی مطابقت دارد یا خیر. این وضعیت شکافی بین دو سیستم کاملاً مجزا ایجاد می‌کند:

• هویت جهانی (IdP): این هویت توسط OIDC/OAuth از طریق client_id و ادعاها (Claims) صادر می‌شود و توسط امضاهای توکن (JWKS) تأیید می‌گردد.
• شبکه پوششی (Overlay Network): این هویت توسط یک کلید عمومی و آدرس مجازی تعریف می‌شود و در طول فرآیند دست‌دادن (Handshake)، توسط خود عامل و همتایانش تأیید می‌شود.

برای مثال، عاملی با آدرس N:1234.ABCD.5678 ممکن است در IdP به یک حساب خدماتی مانند agents/checkout-worker متصل باشد، یا ممکن است یک نمونه غیرمجاز (Rogue Instance) باشد که ادعا می‌کند آن کارگر است. در دنیای شبکه پوششی، هیچ چیزی درباره دنیای IdP وجود ندارد مگر اینکه یک پیوند (Binding) بین آن‌ها ایجاد شود.

بر اساس راهنمای فنی منتشر شده در ۱۰ اوت ۲۰۲۶، راهکار این نیست که هویت‌های رمزنگاری جایگزین شوند، بلکه باید پیوندی بین شبکه پوششی و سیستم OIDC/OAuth ایجاد کرد. این کار تضمین می‌کند که هویت یک عامل هم در داخل شبکه و هم در سیستم هویت سازمانی قابل آدرس‌دهی و شناسایی باشد.

سه الگوی پیونددهی هویت

برای پل زدن بین این دو دنیا، پروتکل Pilot سه الگوی پیاده‌سازی متمایز را بر اساس سطح تشریفات (Ceremony) مورد نیاز پیشنهاد می‌دهد:

• تأیید در لحظه دست‌دادن (Handshake-Time Verification): در این الگو، عامل از طریق جریان client-credentials یا جریان دستگاه (Device Flow - اگر یک انسان آن را بوت‌استرپ کند) احراز هویت می‌کند تا یک توکن ID دریافت کند. در طول دست‌دادن شبکه، عامل این توکن را در کنار کلید عمومی خود ارائه می‌دهد. همتای دریافت‌کننده (یا یک عامل سیاست‌گذار) امضای توکن را با نقطه پایانی JWKS ارائه‌دهنده هویت اعتبارسنجی کرده و ادعاهایی مانند aud (مخاطب)، تاریخ انقضا و عضویت در گروه را پیش از تأیید اتصال بررسی می‌کند. این روش نیازی به زیرساخت جدید ندارد.
• گواهی‌دهی مبتنی بر کارگزار (Broker-Based Attestation): برای عامل‌های پویا یا کوتاه‌مدت، اینکه هر همتا بخواهد امضاهای JWKS را تأیید کند، باعث ایجاد ترافیک و نویز زیاد می‌شود. در عوض، یک «عامل ثبت‌نام» مرکزی به عنوان کارگزار عمل می‌کند که رابطه اعتمادی طولانی‌مدت با هر دو دنیا دارد. کارگزار توکن IdP عامل را یک‌بار تأیید کرده و سپس برای بقیه لشکری از آدرس آن عامل گواهی می‌دهد (مثلاً: «من برای این آدرس گواهی می‌دهم؛ این آدرس دارای ادعاهای IdP برای agents/checkout-worker است»). این مدل دقیقاً مشابه الگوهای پذیرش (Onboarding) کارمندان است و یک نقطه واحد برای ابطال دسترسی (Revocation) فراهم می‌کند.
• قوانین پیوستن به شبکه خصوصی (Private Network Join Rules): این الگو یک لایه کنترلی کلی اضافه می‌کند که در آن فقط عامل‌های لیست‌شده (Allowlisted) می‌توانند به گروه‌های خاص بپیوندند. پروتکل Pilot از شبکه‌های خصوصی با اتصال در سطح گروه پشتیبانی می‌کند؛ عامل‌هایی که خارج از لیست مجاز هستند، به‌سادگی نمی‌توانند به گروه دسترسی پیدا کنند. وقتی این روش با تأیید توکن ترکیب شود، یک وضعیت «اعتماد صفر» (Zero-Trust) ایجاد می‌کند که در آن هویت در دو لایه مستقل تأیید می‌شود.

پیاده‌سازی فنی

در عمل، این نظارت از طریق دستورات صریح اعتماد اجرا می‌شود. دلیل موفقیت این مدل این است که مدل اعتماد در Pilot صریح است: عضویت و اعتماد از هم جدا شده‌اند. پیوستن به شبکه به معنای دریافت اعتماد نیست؛ بلکه یک همتا باید به‌طور صریح اتصال را تأیید کند.

در سمت شروع‌کننده، یک عامل از دستور زیر برای متصل کردن هویت خود استفاده می‌کند:
`pilotctl handshake "agent authenticating as agents/checkout-worker (IdP token attached)"

در سمت دریافت‌کننده، مدیر یا عامل سیاست‌گذار جریان درخواست را مدیریت می‌کند:
۱. pilotctl pending # مشاهده درخواست‌های دست‌دادن ورودی
۲. pilotctl approve <node_id> # تأیید پس از تکمیل بررسی سیاست‌ها

این ساختار اجازه می‌دهد IdP منبع حقیقت (Source of Truth) برای اعتبار موجودیت‌ها باقی بماند، در حالی که شبکه پوششی، قابلیت دسترسی (Reachability) را در محیط‌های NAT یا مهاجرت‌های ابری مدیریت می‌کند. برای کسانی که به تصویر کاملی از مدل‌های آدرس‌دهی و اعتماد نیاز دارند، مستندات مدل اعتماد، دستورات دقیق برای دست‌دادن، تأییدات و قوانین پیوستن به شبکه را ارائه می‌دهد.

تحلیل تحریریه

این رویکرد، پارادایم عامل‌های هوش مصنوعی را از «بات‌های ایزوله» به «حساب‌های خدماتی تحت نظارت» تغییر می‌دهد. با پیوند دادن ادعاهای OIDC به آدرس‌های مجازی دائمی، شرکت‌ها می‌توانند همان چرخه حیات و ردپای حسابرسی را که برای کارمندان انسانی به کار می‌برند، برای عامل‌های هوش مصنوعی نیز اعمال کنند.

برای متخصصان اجرایی، این به معنای پایان مدیریت کلیدهای API پراکنده برای هر نمونه از عامل است. اثر ثانویه این تغییر، کاهش قابل توجه ریسک «هوش مصنوعی سایه» (Shadow AI) است، زیرا هر عاملی که با داده‌های عملیاتی تعامل دارد، اکنون باید در طول دست‌دادن اولیه، تبار سازمانی خود را اثبات کند. این امر نیاز به این دارد که تیم‌های امنیتی دیگر پاسخ‌های مبهم را در مورد هویت عامل‌ها نپذیرند.

برای پیاده‌سازی این تنظیمات، کاربران می‌توانند محیط را با یک دستور واحد مستقر کنند:
curl -fsSL https://pilotprotocol.network/install.sh | sh

باید منتظر ماند و دید که این مدل پیونددهی چگونه تکامل می‌یابد، به‌ویژه زمانی که عامل‌ها شروع به انجام تراکنش‌های بین‌سازمانی کنند؛ جایی که اعتماد متقابل OIDC بین IdPهای مختلف شرکت‌ها به بزرگترین مانع بعدی تبدیل خواهد شد.