پرش به محتوای اصلی

OpenShell فقط نشانه را درمان می‌کند: ایمنی agent به قرارداد نیاز دارد، نه کلید قطع

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

نمای نزدیک از یک رک سرور با LEDهای وضعیت روشن و کابل‌های شبکه، نمایانگر زیرساخت زمان اجرا برای مهار agent هوش مصنوعی.

OpenShell در واقع چه چیزی را اعمال می‌کند

ابزارهای مهار در زمان اجرا مانند OpenShell شرکت Nvidia در نقطه‌ای مشخص از پشتهٔ agent عمل می‌کنند: پایین‌تر از استدلال مدل و بالاتر از tool call. آن‌ها لحظه‌ای را رهگیری می‌کنند که agent می‌کوشد ابزاری را فراخوانی کند، پیامی بفرستد یا رکوردی بنویسد. در آن مرز می‌توانند اقدام پیشنهادی را بررسی کنند، آن را با مجموعه‌ای از قواعد بسنجند و اجرا را متوقف کنند. این مفید است. اما به‌تنهایی ناقص است.

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

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

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

قرارداد پیش از اجرا

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

Hands holding Erlenmeyer flasks of blue liquid during a laboratory experiment

این اعلام یک دستور prompt نیست. یک مصنوع ماشین‌خوان است که زمان اجرا می‌تواند آن را به‌صورت قطعی بررسی کند. وقتی اعمالی به سبک OpenShell به‌جای قصد استنباط‌شده یک دامنهٔ اعلام‌شده را بررسی می‌کند، بررسی به یک مقایسهٔ مجموعه‌ای تبدیل می‌شود: آیا این ابزار در سطح اعلام‌شده هست، آیا این مقصد در فهرست خروجی اعلام‌شده هست، آیا این هزینه در سقف اعلام‌شده هست. پاسخ بله است یا خیر. نه classifier، نه تأخیر، نه تصمیم قضاوتی.

قراردادها همچنین ترکیب‌پذیرند. یک sub-agent باید سقفی محدودشده را از والد خود به ارث ببرد، نه سطح کامل والد را. اگر یک agent والد به یک API پرداخت و یک API پیام‌رسانی دسترسی داشته باشد، یک sub-agent که وظیفه‌اش پیش‌نویس یک پیام است باید فقط ابزار پیام‌رسانی را دریافت کند، با فهرست مقاصدی که به گیرندگان تأییدشدهٔ والد محدود شده است. این یک استنباط در زمان اجرا نیست؛ یک ویژگی ساختاری در تعریف agent است. sub-agent نمی‌تواند از سقف خود فراتر رود چون سقفش هرگز اعطا نشده است.

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

چرا کلید قطع ابتدایی نادرست است

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

پایان دادن به یک اجرا در میانهٔ مسیر، اثرات جانبی ناقص بر جای می‌گذارد. یک رکورد نیمه‌نوشته در پایگاه داده. یک پیام نیمه‌فرستاده به مشتری. یک تراکنش نیمه‌تعهدشده که دو سیستم را در وضعیت‌های ناسازگار رها می‌کند. کلید قطع agent را متوقف می‌کند، اما اقداماتی را که agent پیشاپیش انجام داده است، بازنمی‌گرداند. بازگردانی در برخی سیستم‌ها ممکن است، اما پرهزینه، خطاپذیر و اغلب ناقص است. هزینهٔ حادثه هزینهٔ کلید قطع نیست؛ هزینهٔ پاک‌سازی است.

مهار باید آخرین چاره پس از بررسی‌های دامنه، بودجه‌های خروجی و سقف‌های توانمندی باشد. یک بررسی دامنه مانع از آن می‌شود که agent ابزاری بیرون از سطح اعلام‌شده‌اش را فراخوانی کند. یک بودجهٔ خروجی مانع از آن می‌شود که داده‌ای بیش از اعلام‌شده بفرستد. یک سقف توانمندی مانع از آن می‌شود که مجوزهای خود را ارتقا دهد یا sub-agentهایی با دسترسی گسترده‌تر پدید آورد. این‌ها قطعی، ارزان و در هر مرحله قابل اعمال‌اند. کلید قطع همان چیزی است که وقتی همهٔ آن‌ها ناکام می‌مانند باقی Close-up of a server rack in a data center aisle with blue lighting Server rack closeup

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

یک لایه‌بندی عملی

یک معماری کارآمد برای ایمنی agent از چهار لایه استفاده می‌کند که هر یک از لایهٔ پیشین ارزان‌تر و قطعی‌تر است.

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

لایهٔ دو، اعتبارسنجی هر مرحله در برابر دامنهٔ اعلام‌شده است. پیش از هر tool call، زمان اجرا اقدام پیشنهادی را با قرارداد می‌سنجد. این بررسی ارزان و قطعی است: یک آزمون عضویت مجموعه‌ای، یک مقایسهٔ مقصد، یک شمارش هزینه. نیازی به مدل ندارد. تأخیری وارد نمی‌کند. یا قبول می‌شود یا رد، و یک رد، مرحله را پیش از بروز هر اثر جانبی متوقف می‌کند.

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

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

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

اشتراک‌گذاریXLinkedInپیوند یکتا6 دقیقه مطالعه

خواندن مرتبط

پرسش‌هایی که این پاسخ می‌دهد

What is the difference between a kill switch and a contract for AI agents?

A kill switch is a recovery mechanism that terminates a run after a problem is detected. A contract is a prevention mechanism that declares, before the run, which tools, destinations and spend levels are permitted. The contract makes enforcement deterministic; the kill switch only limits damage after the fact.

Why can't runtime containment tools like OpenShell know an agent's intent?

Containment tools intercept the tool call, not the reasoning that produced it. They see a structured request but not the goal or authority behind it. Without a declared scope, every halt is a judgement call made by a classifier, which is probabilistic and introduces latency.

What are the four layers of a practical agent safety architecture?

Layer one: static scope declaration at agent definition time. Layer two: per-step validation against the declared scope, which is cheap and deterministic. Layer three: runtime anomaly detection for drift, where classifier-based tools are useful. Layer four: containment and rollback, invoked only when the earlier layers fail.

What is the main trade-off of using contracts for agent safety?

Contracts require upfront work to declare a tool surface, egress destinations and spend envelope for every agent. They also constrain flexibility, because an agent that needs a tool outside its declared surface requires a human decision to amend the contract. The alternative is a system where every action is a judgement call.