تصور کنید هفته‌ها وقت صرف تنظیم توکن‌های دسترسی می‌کنید، اما عامل شما همچنان نمی‌تواند یک فایل ساده را آپلود کند، در حالی که تمام تست‌های شبکه می‌گویند «همه چیز مرتب است». این همان سرابی است که یک تیم توسعه‌دهنده هنگام ساخت یک واحد عملیاتی کاملاً خودگردان با آن مواجه شد.
هدف این تیم ساخت سازمانی بود که بدون حضور انسان در چرخه (Human-in-the-loop) فعالیت کند؛ جایی که اجراهای زمان‌بندی‌شده بتوانند فکر کنند، بسازند و منتشر کنند. اما در عمل، آن‌ها دو هفته را صرف تعقیب توکنی برای یک API شدند که در ظاهر موفق به نظر می‌رسید، اما در واقع کاملاً غیرقابل دسترس بود.
بسیاری از توسعه‌دهندگان به دسترسی اینترنتی به شکل یک کلید روشن/خاموش نگاه می‌کنند: یا عامل (Agent) — مثل کارمندی که دستورات را می‌گیرد و ابزارها را اجرا می‌کند — به میزبان دسترسی دارد یا ندارد. طبق گزارش وب‌سایت dev.to، این فرض در محیط‌های عملیاتی خطرناک است؛ زیرا محیط‌های ایزولهٔ ابری (Cloud Sandboxes) اغلب از پروکسی‌هایی استفاده می‌کنند که برای مسیرهای ریشه (Root Paths) پاسخ موفقیت‌آمیز می‌فرستند، اما نقاط انتهایی (Endpoints) واقعی API را مسدود می‌کنند. این چالش‌ها به‌ویژه در محیط‌های سازمانی شدیدتر است، چرا که بسیاری از عامل‌های AI به دلیل تنظیمات سخت‌گیرانه فایروال‌های شرکتی با مسدودسازی مواجه می‌شوند.
توهم موفقیت
تیم توسعه در ابتدا به یک تست سادهٔ اتصال اعتماد کرد. آن‌ها میزبان‌ها را فراخواندند و کدهای وضعیت را ثبت کردند: pypi.org و api.github.com هر دو کد ۲۰۰ (موفق) برگرداندند. در مقابل، github.com کد ۴۰۰ داد و چهار پلتفرم دیگر اصلاً متصل نشدند. آن‌ها کد ۲۰۰ را نشانهٔ باز بودن درها دانستند و دو هفته بعد را صرف برنامه‌ریزی برای دریافت توکن دسترسی کردند.
اما هفته‌ها بعد، وقتی یک اجرا به جای مسیر ریشه، به یک نقطهٔ انتهایی واقعی برخورد کرد، حقیقت آشکار شد. در حالی که درخواست GET / پاسخ ۲۰۰ با یک بدنهٔ خالی {} می‌داد، سایر درخواست‌ها شکست خوردند: درخواست GET /zen خطای ۴۰۳ داد و اعلام کرد نشست (Session) محدود به مخازن پیکربندی‌شده است. حتی درخواست GET /user با وجود داشتن هدر احراز هویت، خطای ۵۰۲ برگرداند؛ زیرا یک پروکسی در مسیر، هدر را نادیده گرفته و سعی کرده بود اعتبارنامهٔ خود را جایگزین کند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت محیط‌های ایزوله اشاره کردیم، تفاوت میان «اتصال شبکه» و «دسترسی به سرویس» می‌تواند کل پروژه را به بن‌بست بکشاند.
قانون سه ستون
تمام اصلاحات این تیم از طریق بررسی بدنهٔ پاسخ (Response Body) رخ داد، نه کد وضعیت. نکتهٔ کلیدی این بود که لینک مستندات موجود در خطاها، به مستندات رسمی فروشنده اشاره نمی‌کرد. برای جلوگیری از این تله، تیم یک «قانون سه ستونی» برای تایید دسترسی پیاده کرد:
- اتصال (Dial): آیا میزبان اصلاً پاسخ می‌دهد؟ این ارزان‌ترین و کم‌اطلاعات‌ترین بررسی است و فقط مشکلات DNS یا لیست‌های مجاز خروجی را شناسایی می‌کند.
- مسیر (Path): آیا نقطهٔ انتهایی که واقعاً به آن نیاز دارید پاسخ می‌دهد؟ این مرحله محدودیت‌های پروکسی و مجوزهای هر منبع را فاش می‌کند.
- نوشتن (Write): آیا یک فراخوانی تغییردهنده با اعتبارنامهٔ شما موفق می‌شود؟ این مرحله تعیین می‌کند که آیا توکن‌ها حذف یا محدود به حالت «فقط خواندنی» شده‌اند یا خیر.
در کنار این متدهای تایید، استفاده از لایه‌های نظارتی برای مدیریت دسترسی‌ها ضروری است؛ برای مثال پلتفرم‌هایی مانند MCP Fabric ابزارهایی را برای جلوگیری از دسترسی غیرکنترل‌شده‌ی عامل‌ها فراهم می‌کنند.
سایت‌های اجرا و دیده‌شدن
تیم متوجه شد که «پست شدن» و «قابل یافتن بودن» نیز دو ستون مجزا هستند. اولین پست‌های خودکار آن‌ها روی یک حساب جدید، برچسب noindex داشتند؛ یعنی داخل پلتفرم رتبه داشتند اما برای دنیای بیرون وجود نداشتند.
یکی از حیاتی‌ترین یافته‌ها این بود که مسدود بودن دسترسی به «سایت اجرا» مربوط بود، نه کدِ عامل. آن‌ها سه محیط را مقایسه کردند:
- مرورگر انسان: کار می‌کند چون یک انسان روی لینک کلیک کرده است.
- CI Runner: کار می‌کند و کامیت‌ها را به‌طور مستقل ثبت می‌کند.
- Cloud Sandbox: مسدود است؛ یعنی دقیقاً همان جایی که اجراهای زمان‌بندی‌شده قرار داشتند.
با انتقال عملیات به CI Runner، عامل توانست در کمتر از یک ساعت مخزن را بخواند، مدل را فراخوانی کند و فایل‌ها را تحت هویت خودش ثبت کند. دیوار اصلی، ناتوانی عامل در دسترسی به اینترنت نبود، بلکه محدودیتِ محیط اجرای خاص بود. این رویکرد در جهت یکپارچه‌سازی ابزارهای عملیاتی است، مشابه آنچه در پروژه‌ی Mu برای دسترسی متمرکز به ده‌ها ابزار مختلف مشاهده می‌کنیم.
این تغییر دیدگاه، نقشه راه استقرار عامل‌ها را عوض می‌کند. توسعه‌دهندگان به‌جای هفته‌ها عیب‌یابی توکن‌های احراز هویت، باید ابتدا قابلیت‌های HTTP خروجیِ محیط اجرا را تایید کنند.
نویسنده برای کسانی که می‌خواهند محیط خود را تست کنند، یک اسکریپت شش‌خطی bash با استفاده از curl پیشنهاد می‌دهد تا هم کد HTTP و هم ابتدای بدنهٔ پاسخ را بررسی کنند. اجرای این تست روی لپ‌تاپ شخصی یک «تله» است؛ زیرا لپ‌تاپ‌ها معمولاً دسترسی نامحدودی دارند که محیط‌های ایزولهٔ عملیاتی فاقد آن هستند.
در نهایت، کد وضعیت فقط ثابت می‌کند که در پاسخ داده شده است، نه اینکه در باز شده است. اگر برنامهٔ استقرار شما بر یک سنجهٔ تک‌بعدی استوار است، احتمالاً در ستون اول دسترسی هستید اما تصور می‌کنید در ستون سوم قرار دارید.
گام بعدی شما
- به‌جای تکیه بر کد ۲۰۰، یک تست
curlبرای نقاط انتهایی (Endpoints) واقعی API در محیط Sandbox خود اجرا کنید. - بدنهٔ پاسخ‌های خطا را بررسی کنید تا ببینید آیا توسط پروکسی‌های داخلی سازمان یا ابری تغییر یافته‌اند یا خیر.
- محیط اجرای عامل خود را بین CI Runner و Cloud Sandbox مقایسه کنید تا گلوگاه‌های شبکه را شناسایی کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو