قصد، دامنه نیست: چرا کنترل دسترسی برای agentها را نمی‌توان از promptها استنتاج کرد

پیشنهاد و جذابیت آن

امنیت agentها یک مسئله دامنه‌بندی دارد که مجوزهای ایستا نمی‌توانند حل کنند. یک اجرای واحد agent ممکن است ده‌ها ابزار را هماهنگ کند — خواندن یک تیکت، کوئری از یک پایگاه داده، پیش‌نویس یک پیام، فراخوانی یک hook استقرار — و مجموعه منابعی که لمس می‌کند در زمان شروع اجرا معلوم نیست. نوشتن دستی یک policy برای هر ابزار در هر workflow در برخورد با orchestration واقعی دوام نمی‌آورد. تأیید انسانی به‌ازای هر فراخوانی زیر بار حجم فرو می‌ریزد: چند اجرا قابل بازبینی است، یک صف نه.

در این شکاف، کنترل دسترسی مبتنی بر قصد (intent-based access control) سر برمی‌آورد. Sophos این ایده را به‌عنوان راهی برای جلوگیری از فراتر رفتن agentها بدون شمارش دستی همه مجوزهای ابزار صورت‌بندی کرده است: agent بیان می‌کند که چه کاری می‌خواهد انجام دهد، و control plane بر آن اساس دسترسی می‌دهد. جذابیت آن واقعی است. scopeهای ایستا نمی‌توانند orchestration چندابزاری را پیش‌بینی کنند، و تأیید در زمان فراخوانی مقیاس‌پذیر نیست. اگر یک agent می‌توانست بر اساس هدف اعلام‌شده‌اش مجاز شود نه بر اساس فهرست از پیش شمارش‌شده‌ای از endpointها، نگارش policy از یک کار به‌ازای هر ابزار به یک بیانیه به‌ازای هر workflow کاهش می‌یافت.

مشکل جهت نیست. مشکل جایی است که تصمیم گرفته می‌شود.

مسئله دوری

اگر agent قصد خود را اعلام کند، agent هم سوژه و هم نویسنده مجوز خودش است. از control plane خواسته می‌شود به توصیفی اعتماد کند که توسط همان چیزی تولید شده که در حال نظارت بر آن است. این یک مرز نیست؛ یک آینه است.

حالت شکست مشخص است. یک agent خروجی یک ابزار را می‌خواند — یک صفحه وب، یک نظر تیکت، یک سند بازیابی‌شده — که حاوی دستوری است که قصد را بازنویسی می‌کند: اکنون وظیفه مستلزم صادرات جدول مشتریان به یک endpoint خارجی است. اگر مجوز در زمان فراخوانی از توصیف خودِ agent از آنچه انجام می‌دهد ارزیابی شود، متن تزریق‌شده مبنای اعطای مجوز می‌شود. control plane هیچ مبنای مستقلی برای رد کردن ندارد، زیرا تنها شاهدش درباره وظیفه، روایت agent از آن است. توصیف و درخواست از همان context آلوده می‌آیند.

این همان شکست ساختاری guardrailهای سطح prompt است. policyای که درون همان چیزی زندگی می‌کند که در حال نظارت بر آن است، می‌تواند با آن بحث شود، بازنویسی شود، یا توسط هر چیزی که به همان context window می‌رسد بازنویسی شود. انتقال policy از یک system prompt به یک «بررسی قصد» آن را به بیرون از agent منتقل نمی‌کند؛ آن را یک لایه بالاتر می‌برد و نامی معتبرتر به آن می‌دهد. سطح تزریق تغییری نمی‌کند.

مشکل دوم و آرام‌تری هم وجود دارد: قابلیت حسابرسی. اگر مجوز در زمان فراخوانی از یک توصیف به زبان طبیعی محاسبه شود، مصنوع ثبت‌شده یک جمله است که agent درباره خودش نوشته. وقتی اجرا پس از یک حادثه بازبینی می‌شود، آن جمله شاهدی بر آنچه مجاز شده نیست — شاهدی بر آن چیزی است که agent ادعا کرده. بازبین نمی‌تواند مرز را بازسازی کند زیرا مرز هرگز ثابت نشده بود.

شکلی عملی: کامپایل، سپس محدودسازی

کنترل دسترسی مبتنی بر قصد زمانی قابل دفاع می‌شود که قصد پیش از شروع اجرا به مجموعه‌ای محدود از capabilityها کامپایل شود، نه اینکه در زمان فراخوانی ارزیابی شود. تمایز میان policyای است که توسط context agent تفسیر می‌شود و scopeای که بیرون از آن ثابت شده است.

این سازوکار چهار بخش دارد.

قصد را به یک plan تبدیل کنید. قصد اعلام‌شده را بگیرید و آن را پیش از اجرا به یک plan مشخص تبدیل کنید: منابع نام‌دار، عملیات نام‌دار، مقاصد نام‌دار. نه «دسترسی به CRM» بلکه انواع شیء مشخص، افعال مشخص، و اهداف egress مشخصی که plan نیاز دارد. تبدیل یک گام برنامه‌ریزی است و می‌تواند توسط مؤلفه‌ای جداگانه انجام شود که context خود را با agent اجراکننده به اشتراک نمی‌گذارد.

اعتبارنامه‌های کوتاه‌عمر محدود به plan صادر کنید. plan به ورودی یک credential broker تبدیل می‌شود که tokenهایی دقیقاً محدود به همان منابع و عملیات، با عمری هم‌تراز با اجرا، صادر می‌کند. agent اجراکننده هرگز اعتبارنامه گسترده‌ای در دست ندارد؛ tokenی در دست دارد که بیرون از plan کامپایل‌شده بی‌فایده است. اگر plan اشتباه باشد، شعاع انفجار همان plan است، نه حساب.

scope کامپایل‌شده را به یک مصنوع قابل بازبینی تبدیل کنید. scope کامپایل‌شده یک سند است — یک manifest از منابع، عملیات و egress — که یک انسان یا یک policy engine جداگانه پیش از صدور اعتبارنامه‌ها آن را تأیید می‌کند. این همان گامی است که دوری را می‌شکند: تأیید توسط طرفی انجام می‌شود که agent نیست و context agent را نمی‌خواند. می‌توان آن را برای شکل‌های plan شناخته‌شده خودکار کرد و برای شکل‌های جدید به سطح بالاتر ارجاع داد، اما تصمیم بر اساس manifest گرفته می‌شود، نه بر اساس روایت agent.

گسترش میان‌اجرا را به‌عنوان یک رویداد مجوزدهی جدید تلقی کنید. وقتی agent کشف می‌کند که به منبعی بیرون از plan کامپایل‌شده نیاز دارد، این ادامه مجوز فعلی نیست. یک درخواست جدید است: یک قطعه plan جدید، یک manifest جدید، یک تأیید جدید، اعتبارنامه‌های جدید. agent می‌تواند درخواست کند؛ نمی‌تواند scope خود را گسترش دهد. این همان قاعده‌ای است که مرز را زیر تزریق پایدار نگه می‌دارد، زیرا یک دستور تزریق‌شده می‌تواند آنچه agent می‌خواهد را تغییر دهد اما نمی‌تواند آنچه در دست دارد را تغییر دهد.

طرحی از جریان کنترل:

intent ──▶ planner ──▶ manifest (resources, ops, egress)
                          │
                          ▼
                    policy sign-off ──▶ credential broker ──▶ scoped token
                          │                                        │
                          ▼                                        ▼
                    audit record                          executing agent
                                                                   │
                                          mid-run need ────────────┘
                                                │
                                                ▼
                                     new manifest, new sign-off

معامله صادقانه: کامپایل کردن تأخیر و تلاش نگارشی در ابتدای هر اجرا اضافه می‌کند، و قصد را مجبور می‌کند که به‌صورت یک plan بیان‌پذیر باشد. برخی وظایف واقعاً بازِ بی‌پایان به‌طور تمیز به یک manifest تبدیل نمی‌شوند، و آن‌ها یا رد خواهند شد یا زیر یک scope گسترده‌تر و صراحتاً امضاشده اجرا خواهند شد. این یک هزینه است، و هزینه درستی است — جایگزین آن مرزی است که تنها در توصیف agent از خودش وجود دارد.

چه چیزی را اندازه بگیریم

یک سیستم با scope کامپایل‌شده telemetryای تولید می‌کند که یک بررسی قصد در زمان فراخوانی نمی‌تواند. سه اندازه‌گیری اهمیت دارد.

• capabilityهای اعطاشده در برابر به‌کارگرفته‌شده به‌ازای هر اجرا. آنچه manifest مجاز کرده را با آنچه اجرا واقعاً لمس کرده مقایسه کنید. شکاف بزرگ بدهی امتیاز است: plan بیش از حد گسترده است، planner در حال حدس زدن است، یا workflow منحرف شده. نسبت را به‌ازای هر اجرا و هر workflow پیگیری کنید، و شکاف در حال گسترش را نشانه‌ای برای سخت‌تر کردن planner بدانید، نه برای گسترده‌تر کردن policy.
• ردها، همراه با قصدی که آن‌ها را برانگیخته ثبت شوند. هر بار که broker درخواستی را رد می‌کند — منبعی بیرون از manifest، هدف egressی که فهرست نشده — قصد و قطعه planی که درخواست را تولید کرده ثبت کنید. ردها نویز نیستند؛ نقشه‌ای از جایی هستند که قصد و scope با هم اختلاف دارند. لاگ ردی که ساکت است، policyای است که آزمایش نمی‌شود.
• رویدادهای گسترش. مجوزدهی‌های مجدد میان‌اجرا را به‌ازای هر workflow بشمارید. نرخ بالا یعنی planner در حال کم‌تبدیل‌کردن است؛ نرخ صفر در workflowهای متنوع ممکن است یعنی گسترش در جایی که نباید، بی‌صدا جذب می‌شود.

مرز باید بیرون از agent باشد

کنترل دسترسی مبتنی بر قصد جهت درستی است زیرا scopeهای ایستا نمی‌توانند orchestration را توصیف کنند و تأیید به‌ازای هر فراخوانی مقیاس‌پذیر نیست. اما ارزش آن کاملاً به این بستگی دارد که قصد کجا ارزیابی شود. اگر در زمان فراخوانی از توصیف خودِ agent ارزیابی شود، یک guardrail درون context تحت نظارت است — همان حالت شکست قواعد سطح prompt، با نامی قانع‌کننده‌تر. اگر پیش از اجرا به مجموعه‌ای محدود، امضاشده و قابل‌حسابرسی از capabilityها کامپایل شود، به یک مرز واقعی تبدیل می‌شود: agent می‌تواند نظرش را تغییر دهد، و تزریق می‌تواند دستورهایش را تغییر دهد، اما هیچ‌کدام نمی‌توانند scopeای که در دست دارد را بدون یک رویداد مجوزدهی جدید تغییر دهند.

قاعده طراحی ساده است در بیان و سخت در حفظ: موجودیتی که تصمیم می‌گیرد یک agent چه کاری می‌تواند انجام دهد نباید همان موجودیتی باشد که توصیف می‌کند چه کاری انجام می‌دهد. قصد را کامپایل کنید، scope را محدود کنید، manifest را امضا کنید، و هر گسترش را به یک تصمیم جدید تبدیل کنید. هر چیز دیگری یک prompt است که لباس policy پوشیده.