اعتبارنامه‌های agent یک مسئله سیاستی است، نه یک مسئله prompt

حالت شکست، مدل نیست؛ اعتبارنامه محیطی است

وقتی یک agent به نشست OAuth یک انسان متصل می‌شود، قصد انسان را به ارث نمی‌برد. scope انسان را به ارث می‌برد. یک system prompt که می‌گوید «ایمیل نفرست»، برای یک فرایند تصادفی یک پیشنهاد است؛ این یک محدودیت اعمال‌شده توسط سرور مجوزدهی نیست. مدل می‌تواند aligned باشد، prompt می‌تواند دقیق باشد، و agent باز هم می‌تواند درخواستی صادر کند که اعتبارنامه از نظر قانونی مجاز به انجام آن است.

نتیجه عملی این است که prompt injection و privilege escalation دیگر دسته‌های جداگانه نیستند. یک دستور تزریق‌شده نیازی ندارد مدل را بشکند. فقط باید به یک tool call برسد که token محیطی از قبل آن را مجاز کرده است. مدل به یک لایه مسیریابی برای اختیاری تبدیل می‌شود که پیش از آغاز گفتگو اعطا شده است.

به همین دلیل «ایمیل نفرست» یک primitive کنترل دسترسی نیست. primitiveهای کنترل دسترسی عبارت‌اند از scopeها، audienceها، زمان‌های انقضا و محدودیت‌های منبع. آن‌ها در token و در broker زندگی می‌کنند، نه در متن دستور. یک prompt یک بیان سیاستی بدون نقطه اعمال است. وقتی شکست می‌خورد، هیچ رویداد audit، هیچ رد و هیچ revocation وجود ندارد.

شعاع انفجار بر اساس کلاس اعتبارنامه متفاوت است. یک token agent لو‌رفته با scope باریک و کوتاه‌عمر می‌تواند تا زمان انقضا مجموعه محدودی از منابع را بخواند. یک نشست کاربر لو‌رفته می‌تواند به‌جای انسان در هر سرویسی که به identity provider اعتماد دارد عمل کند، از جمله بازنشانی رمز، صورت‌حساب و خروجی داده. token agent یک ابزار محدود است؛ نشست کاربر یک کلید اصلی است. سیستم‌هایی که این دو را یکی می‌کنند، شعاع انفجار کلید اصلی را در هر نوبت agent به ارث می‌برند.

بودجه‌های اختیار به‌عنوان یک artefact درجه‌یک

بودجه اختیار یک توصیف اعلانی از کارهایی است که یک agent می‌تواند انجام دهد، بیان‌شده در واحدهایی که runtime می‌تواند اعمال کند. این یک prompt نیست و یک توصیف نقش هم نیست. این پیکربندی است که همراه agent ارسال می‌شود، در همان مخزن کد agent نسخه‌بندی می‌شود و توسط همان افرادی بازبینی می‌شود که اتصالات ابزار را بازبینی می‌کنند.

یک بودجه مفید حداقل چهار بُعد دارد:

• هزینه: سقف هر وظیفه و هر بازه زمانی بر عملیات پولی، بیان‌شده به‌صورت یک حد سخت که broker از عبور از آن امتناع می‌کند.
• حجم پیام: سقفی بر پیام‌های خروجی، دعوت‌نامه‌ها یا اعلان‌ها در هر بازه، تا یک agent به‌خطرافتاده نتواند از صندوق پستی به‌عنوان تقویت‌کننده استفاده کند.
• عملیات نوشتن: یک شمارش و یک scope منبع برای تغییرات، جدا از خواندن.
• فراخوانی‌های خارجی: یک allow-list از مقاصد، با محدودیت نرخ برای هر مقصد، تا exfiltration داده نیازمند مقصدی باشد که از قبل تأیید شده است.

بودجه باید اختیار خواندن را از اختیار نوشتن و از اختیار برگشت‌ناپذیر جدا کند. خواندن یک تقویم با حذف یک رویداد از یک کلاس عمل نیست. ارسال یک پیش‌نویس با ارسال یک پیام یکسان نیست. ارسال پست در یک کانال با انتقال وجه یکسان نیست. هر کلاس grant خودش، انقضای خودش و سیاست checkpoint خودش را دارد.

یک مکانیزم مشخص: فرایند agent هرگز یک secret بلندمدت نگه نمی‌دارد. در شروع وظیفه، هویت خود و مجموعه capability درخواستی را به یک broker ارائه می‌دهد. broker درخواست را در برابر بودجه ثبت‌شده agent اعتبارسنجی می‌کند، یک token کوتاه‌عمر دقیقاً محدود به همان capabilityها و منابع صادر می‌کند و آن را برمی‌گرداند. token یک audience، یک انقضای اندازه‌گیری‌شده به دقیقه و یک شناسه بودجه حمل می‌کند. هر فراخوانی پایین‌دستی آن token را ارائه می‌دهد. broker خود grant را ثبت می‌کند، نه فقط فراخوانی را.

معامله صادقانه، latency و پیچیدگی است. یک رفت‌وبرگشت broker روی مسیر بحرانی هر وظیفه قرار می‌گیرد و فایل بودجه به یک artefact دیگر تبدیل می‌شود که می‌تواند از واقعیت فاصله بگیرد. تیم‌هایی که broker را برای agentهای «ساده» نادیده می‌گیرند، معمولاً بعداً تحت فشار حادثه، اعتبارنامه‌های محیطی را دوباره معرفی می‌کنند، زمانی که agent ساده یک صندوق پستی و یک روش پرداخت پیدا کرده است.

قواعد درگیری پیش از نخستین tool call

ثبت، لحظه درست برای اعلام قواعد درگیری است. در ثبت، agent ابزارهای مجاز، مقاصد مجاز و checkpointهای انسانی موردنیاز خود را اعلام می‌کند. broker این اعلام را ذخیره می‌کند و در زمان grant آن را اعمال می‌کند. ابزاری که اعلام نشده باشد قابل فراخوانی نیست، صرف‌نظر از آنچه مدل منتشر می‌کند.

checkpointهای انسانی به همان اعلام تعلق دارند. یک عملیات برگشت‌ناپذیر می‌تواند نیازمند یک grant دوم با هویت تأییدکننده انسانی پیوست باشد. تأیید یک artefact امضاشده است، نه یک پیام چت، بنابراین می‌تواند در بازبینی بازپخش شود.

طراحی لایه واسطه از اینجا نتیجه می‌شود. سه ویژگی اهمیت دارند:

1. agent هرگز secret خام را نگه نمی‌دارد. یک ارجاع به یک grant را نگه می‌دارد.
2. broker ارجاع را با یک token کوتاه‌عمر محدودشده مبادله می‌کند. این مبادله نقطه اعمال است.
3. ثبت وقایع، grant را ضبط می‌کند: چه کسی آن را درخواست کرد، برای کدام capability، در برابر کدام منبع، با کدام بودجه و کدام تأییدکننده آن را امضا کرد. Cal

یک ورودی grant log تفاوت میان «agent یک ایمیل فرستاد» و «agent اختیار ارسال برای گیرنده X تحت بودجه B را درخواست کرد و broker آن را اعطا کرد زیرا اعلام آن را مجاز می‌دانست» است. گزاره دوم قابل بازبینی است. اولی یک شایعه است.

در اینجا یک هزینه واقعی وجود دارد: grant logging یک جریان رویداد دوم تولید می‌کند که باید نگهداری، ایندکس و با call logها همبسته شود. این ذخیره‌سازی بیشتر و سطح پرس‌وجوی بیشتری است. جایگزین آن یک بازبینی حادثه است که نمی‌تواند بودجه پیکربندی‌نادرست را از یک injection موفق تشخیص دهد.

Revocation و هزینه عملیاتی اشتباه کردن

latency چرخش، شدت حادثه را غالب می‌کند. اگر لغو اختیار یک agent ساعت‌ها طول بکشد، پنجره حادثه ساعت‌ها است، صرف‌نظر از اینکه مدل چقدر سریع وصله شود. اگر revocation یک عملیات واحد broker باشد که یک خانواده grant و tokenهای مشتق‌شده از آن را باطل می‌کند، پنجره به انقضای token به‌علاوه زمان انتشار فرو می‌ریزد.

این revocation را به یک محدودیت طراحی تبدیل می‌کند، نه یک گام runbook. broker باید پشتیبانی کند از:

• Grant revocation: باطل کردن یک grant مشخص و همه tokenهای صادرشده از آن.
• Budget revocation: باطل کردن هر grant تحت یک شناسه بودجه.
• Agent revocation: باطل کردن هر grant برای یک هویت agent.
• Key rotation: صدور مجدد کلیدهای امضای broker بدون استقرار کامل مجدد.

مسیرهای revocation به evaluation harness تعلق دارند، نه فقط به runbookهای تولید. یک harness می‌تواند تأیید کند که پس از یک رویداد revocation، یک token که قبلاً معتبر بود در تعداد محدودی درخواست رد می‌شود و آن رد با شناسه grant ثبت می‌شود. این یک ویژگی قابل آزمون است. برخورد با آن به‌عنوان یک آیتم runbook یعنی نخستین بار در طول یک حادثه آزموده می‌شود.

ریسک باقی‌مانده social engineering است و با scoping از بین نمی‌رود. یک agent محدودشده هنوز می‌تواند دستکاری شود تا از اختیار مشروع خود علیه منافع کاربر استفاده کند: ارسال یک پیام باورپذیر به یک گیرنده تأییدشده، خواندن سندی که مجاز به خواندن آن است و خلاصه کردن آن برای مقصدی تحت کنترل مهاجم در allow-list. scoping شعاع انفجار را کاهش می‌دهد؛ نیاز به بازبینی سطح محتوا، تأیید گیرنده یا ناهنجاری‌های نرخ را از بین نمی‌برد.

نتیجه طراحی باریک و باربر است. واحد طراحی، capability grant است. promptها رفتار را توصیف می‌کنند؛ grantها آن را محدود می‌کنند. سیستم‌هایی که با grant به‌عنوان پیکربندی رفتار می‌کنند، آن را نسخه‌بندی می‌کنند، بازبینی می‌کنند و مسیر revocation آن را می‌آزمایند، از تلاش‌های injection که در غیر این صورت به حادثه privilege escalation تبدیل می‌شدند جان سالم به در می‌برند. سیستم‌هایی که با prompt به‌عنوان control plane رفتار می‌کنند، همچنان کشف خواهند کرد که اعتبارنامه از همان ابتدا سیاست بوده است.