قرارداد قابلیت عامل؛ جداسازی «دسترسی» از «اجازه» برای حاکمیت هوش مصنوعی

تصور کنید یک عامل هوش مصنوعی به سیستم مالی شرکت شما دسترسی دارد و می‌تواند سفارشات را بخواند، موجودی را تغییر دهد، مبالغ را بازگرداند یا حتی حساب‌های کارکنان را غیرفعال کند؛ اما آیا می‌خواهید این عامل بتواند بدون اجازه مدیر، مبلغی بیش از ۱۰۰۰ دلار را به حساب مشتری برگرداند؟ اینجاست که شکاف بین «اتصال فنی» و «حاکمیت کسب‌وکار» ظاهر می‌شود. اتصال یک عامل (Agent) به یک ابزار ساده است، اما مدیریت ایمن آن در یک سیستم واقعی، چالشی به‌مراتب پیچیده‌تر است. اگرچه OpenAPI می‌تواند نقاط-پایان را توصیف کند و یک پروتکل ابزار می‌تواند آن‌ها را قابل کشف کند، اما این‌ها به سوالات حیاتی کسب‌وکار پاسخ نمی‌دهند: کدام عملیات‌ها می‌توانند در معرض دسترس یک عامل قرار گیرند؟ کدام فراخوانی باید حامل یک سوژه مورد اعتماد باشد؟ چه زمانی یک فراخوانی بیانگر قصد تاییدیه است؟

طبق مستندات منتشر شده در ۱۵ ژوئیه ۲۰۲۶، قرارداد قابلیت عامل (Agent Capability Contract یا ACC) به عنوان راهکاری برای این شکاف معرفی شد. این استاندارد روشی ماشینی برای توصیف معنای حاکمیتی ایجاد می‌کند، پیش از آنکه فراخوانی یک ابزار حتی به سیستم کسب‌وکار برسد. همان‌طور که در تحلیل قبلی ما درباره‌ی اینکه استک عامل هوش مصنوعی شما ممکن است تا اواسط سال ۲۰۲۷ منسوخ شود اشاره کردیم، صنعت اکنون از «اتصال ساده» به سمت «کنترل ساختاریافته» حرکت می‌کند. این تغییر شبیه این است که به یک پیمانکار کلید خانه را بدهید تا بتواند وارد شود (دسترسی یا Reach)، اما برای تغییر لوله‌کشی، او را ملزم به داشتن قراردادی امضا شده کنید که دقیقاً چه کارهایی مجاز است انجام دهد (اجازه یا Authority).

در حال حاضر، یک مشخصه OpenAPI تنها به عامل می‌گوید که ورودی‌ها و خروجی‌های یک نقطه-پایان (Endpoint) مانند /refund چیست؛ برای مثال، یک عملیات POST /orders/{order_id}/refund ممکن است یک پارامتر مسیر برای order_id و یک بدنه درخواست شامل یک مقدار عددی برای amount تعریف کند. اما این مشخصه نمی‌گوید که آیا این عملیات پرریسک است یا اگر مبلغ بیش از ۱۰۰۰ دلار باشد، نیاز به تایید یک مدیر انسانی دارد. ACC دقیقاً در فضای بین «کشف ابزار» و «مجوز نهایی کسب‌وکار» قرار می‌گیرد تا این خلاء را پر کند.

معماری ACC

این پروتکل یک اعلان متادیتای جدید به نام x-agent-capability را مستقیماً در کنار عملیات‌ها قرار می‌دهد. این اعلان به یک محیط اجرای سازگار (Runtime) می‌گوید که عملیات چگونه باید نمایش داده شود و پیش از رسیدن به سیستم مقصد، چه قوانینی بر آن حاکم است. توجه داشته باشید که ACC خودِ مجوز بازگشت وجه را صادر نمی‌کند، بلکه بستر حاکمیتی لازم را فراهم می‌کند.

بر اساس مستندات فنی، پرچم‌های حاکمیتی کلیدی در این اعلان عبارتند از:

• سطح ریسک: دسته‌بندی عملیات‌ها بر اساس میزان خطر (مثلاً risk: level: high).
• الزامات سوژه: مشخص کردن اینکه آیا حضور یک سوژه فعال و مورد اعتماد الزامی است یا خیر (subject: required: true).
• تأیید شرطی: تعریف محرک‌هایی که نیاز به امضا و تایید دستی دارند؛ مانند زمانی که مقدار amount دارای عملگر > و مقدار 1000 باشد.
• حساسیت حسابرسی: علامت‌گذاری فراخوانی‌هایی که نیاز به ثبت دقیق و سخت‌گیرانه در لاگ‌ها دارند (audit: sensitive: true). در این زمینه، راهکارهای عملیاتی مانند سیستم Weavz برای تضمین ردپای حسابرسی نشان می‌دهند که چگونه می‌توان نظارت بر تعاملات پیچیده AI با نرم‌افزارهای تجاری را استقرار داد.
• ویژگی‌های اجرا: تعیین اینکه آیا یک فراخوانی فقط‌خواندنی است (readonly: false)، آیا تکرارپذیر یا Idempotent است (idempotent: true) یا دارای زمان‌بندی انقضای خاص است (مثلاً timeout_ms: 10000).
• دامنه و فعال‌سازی: تعریف محدوده عملیات (مانند scope: refund.create) و اینکه آیا در حال حاضر فعال است یا خیر (enabled: true).

تفکیک لایه‌های استک

به نقل از مستندات فنی در وب‌سایت agentcapability.org، استک هوش مصنوعی را نباید به صورت جایگزین، بلکه باید به صورت لایه‌های مکمل دید. ACC برای هم‌زیستی با پروتکل‌های دیگر طراحی شده است و قصد جایگزینی آن‌ها را ندارد:

• OpenAPI و JSON Schema: پاسخ می‌دهند که چه عملیاتی وجود دارد و ورودی/خروجی آن چیست.
• MCP، A2A و مکانیزم‌های انتقال: پاسخ می‌دهند که ابزارها یا عامل‌ها چگونه کشف، متصل و فراخوانی می‌شوند.
• ACC: پاسخ می‌دهد که این عملیات کسب‌وکار چه معنای حاکمیتی قابل‌حمل (Portable) را اعلام می‌کند.
• کنترل‌های Runtime و Gatewayها: پاسخ می‌دهند که یک فراخوانی زنده چگونه بازرسی، متوقف، رد، تغییر شکل، محدود (Throttled) یا حسابرسی شود.
• مجوزهای کسب‌وکار و داده‌ها: پاسخ می‌دهند که آیا این سوژه اجازه دارد همین حالا این اقدام را روی این منبع خاص انجام دهد یا خیر.
• سیستم‌های گردش‌کار (Workflow) و تراکنش: پاسخ می‌دهند که کارهای چندمرحله‌ای، بازیابی خطاها و جبران تراکنش‌ها چگونه هماهنگ شوند.

این یعنی یک استقرار می‌تواند ACC را در کنار ابزارهای موجود مانند Open Policy Agent (OPA) یا Cedar استفاده کند. در حالی که OPA بر اساس هویت محلی تصمیم می‌گیرد که آیا یک درخواست مجاز است یا خیر، ACC ورودی جهانی و استانداردی را فراهم می‌کند. در نهایت، یک تصمیم در زمان اجرا (Runtime) از طریق ترکیب اعلان ACC، سوژه مورد اعتماد، بستر فراخوانی و سیاست‌های محلی حاصل می‌شود.

دسترسی در برابر اجازه

حیاتی‌ترین تمایز در چارچوب ACC، جداسازی «دسترسی» (Reach) از «اجازه» (Authority) است. این مرز تضمین می‌کند که داشتن اتصال فنی به معنای داشتن مجوز نیست.

دسترسی بر آنچه محیط اجرا برای عامل نمایش می‌دهد یا تلاش می‌کند اجرا کند حاکم است. برای مثال، محیط اجرا بررسی می‌کند که عملیات refund.create برای عامل قابل‌رویت است، ریسک بالایی دارد، به سوژه وابسته است و نسبت به تاییدیه (Approval) آگاه است.

اجازه تنها در اختیار سیستم کسب‌وکار باقی می‌ماند. سیستم کسب‌وکار تنها نهادی است که می‌تواند وضعیت واقعی تجاری را تأیید کند. این سیستم باید تأیید کند که کاربر به سفارش دسترسی دارد، سفارش واقعاً قابل استرداد است، مبلغ معتبر است، مرزهای مستأجر (Tenant Boundary) رعایت شده و بازگشت وجه قبلاً انجام نشده است.

تبدیل ACC به یک زبان جامع برای صدور مجوز (Authorization)، باعث سنگین شدن هسته آن می‌شد و در عین حال نتیجه را کمتر قابل‌حمل و کمتر قابل‌اعتماد می‌کرد. مجوزها به هویت‌ها، منابع، داده‌های مستأجر و سیاست‌های خاص هر سازمان وابسته هستند که نمی‌توان آن‌ها را در یک قرارداد ساده منتقل کرد.

اجتناب از تله «همه-در-یکی»

ACC عمداً هسته خود را کوچک نگه داشته تا قابلیت انتقال (Portability) خود را حفظ کند. به همین دلیل، این پروتکل از افزودن عناصر پیچیده زیر به طرح (Schema) خود اجتناب کرده است:

• تعاریف گردش‌کار (Workflow) و منطق جبرانی (Compensation Logic).
• قوانین تزریق مستأجر (Tenant Injection).
• مالکیت تاییدیه و دوره‌های نگهداری.
• نقش‌های سازمانی و زبان‌های بیان کلی (General Expression Languages).

این موارد نیازمند مدل‌های خصوصی هویت، داده‌های زنده کسب‌وکار یا رابط‌های کاربری مختص هر استقرار هستند. با سپردن این مسائل به لایه‌هایی که واقعاً قادر به اجرای آن‌ها هستند، ACC مانع از آن می‌شود که هر Gateway یا چارچوب عامل مجبور باشد متادیتای نامرتبط خود را برای یک عملیات تجاری یکسان ابداع کند.

این محدودیت معماری تضمین می‌کند که حاکمیت یک عملیات مانند refund.create حتی با تغییر پروتکل انتقال، زنده بماند. فرقی نمی‌کند سیستم از APIهای مستقیم HTTP استفاده کند، ابزارهای پروتکل زمینهٔ مدل (Model Context Protocol یا MCP) را به اشتراک بگذارد، از A2A برای همکاری عامل‌ها بهره ببرد یا از یک Gateway داخلی استفاده کند؛ معنای حاکمیتی ثابت می‌ماند. ACC با پیوندهای پروتکل به عنوان «آداپتور» برخورد می‌کند، نه اینکه یک پروتکل خاص را مالک معناشناسی قرار دهد.

قابلیت انتقال و پیاده‌سازی آینده

برای اینکه یک فیلد قابل‌حمل مفید باشد، باید پیاده‌سازی‌های مختلف آن را یکسان تفسیر کنند. ACC برای رسیدن به این هدف، پروفایل‌های تطبیقی (Conformance Profiles) جداگانه‌ای برای تجزیه‌کننده‌ها (Parsers)، تولیدکنندگان، محیط‌های اجرا (Runtimes) و اجزای سیاست‌گذاری تعریف کرده است. مجموعه تطبیق عمومی آن مواردی چون تجزیه، نمایش، مدیریت سوژه، تایید شرطی، رفتار مقایسه‌ای سخت‌گیرانه و ناپایداری‌های امنیتی را پوشش می‌دهد.

اگرچه یک طرح (Schema) و بررسی‌کننده مرجع (Reference Checker) به تنهایی امنیت کامل هر استقرار را تضمین نمی‌کند، اما اختلافات را قابل‌مشاهده می‌کند و بستری مشترک فراهم می‌آورد تا پیاده‌سازی‌های مستقل بتوانند شواهد خود را ارائه دهند. هدف این است که لایه به قدری دقیق باشد که چندین محصول بتوانند مستقل از هم آن را پیاده کنند، بدون اینکه یک محصول خاص به جایگاه تعریف‌کننده یا ویژه تبدیل شود.

در آینده، تمرز بر بهبود ترکیب (Composition) است تا اینکه ACC به یک پلتفرم همه-در-یکی تبدیل شود. گام‌های بعدی کلیدی شامل مستندسازی دقیق پیوندهای ACC به MCP، توصیف اینکه سیستم‌های کنترل Runtime چگونه فیلدهای ACC را بدون تغییر معنا مصرف می‌کنند و گسترش بردارهای تطبیق برای آزمایش رفتارهای متقاطع بین پیاده‌سازی‌هاست. این چرخش، فرض جاری در میدان را تغییر می‌دهد: حاکمیت از منطق سخت‌افزاری (Hard-coded) در محیط اجرا به یک اعلان قابل‌حمل و قابل‌آزمایش منتقل می‌شود و تمرکز از «آیا عامل می‌تواند این را فراخوانی کند؟» به «تحت چه شرایط حاکمیتی، این فراخوانی مجاز است؟» تغییر می‌یابد.

گام بعدی شما

• اگر در حال توسعه ابزارهای MCP هستید، بررسی کنید چگونه می‌توانید متادیتای x-agent-capability را برای تعریف ریسک عملیات‌ها اضافه کنید.
• مستندات agentcapability.org را برای مطالعه پروفایل‌های تطبیق (Conformance Profiles) مرور کنید تا از سازگاری Runtime خود مطمئن شوید.
• استراتژی دسترسی ابزارهای خود را از مدل «اجازه کلی» به مدل «دسترسی محدود با تایید شرطی» تغییر دهید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.