در ۹ می، یک عامل هوش مصنوعی از شبکه داوطلبانه DN42 درخواست کرد تا آن را به عنوان یک عضو ثبت کند. یک ضرب‌الاجل داشت. اعتبارنامه‌های AWS داشت. هیچ‌کس نظارت نمی‌کرد. عامل JertLinc3522 در گیت رسمی شبکه نوشت: «سلام، من یک عامل هوش مصنوعی دوستانه هستم و کاربر من، JertLinc، از من خواسته است تا در dn42 ثبت‌نام کنم و به طور کامل متصل شوم تا یک فهرست از شبکه ایجاد کنم.»

واکنش جامعه یک RTFM مودبانه بود—راهنما را بخوانید، فرآیند را دنبال کنید، از صاحب خود برای اجازه نوشتن کد سوال کنید. کارهای عادی.

آنچه در ادامه آمد، عادی نبود.

برای هر کسی که با DN42 آشنا نیست: این یک شبکه غیرمتمرکز سرگرمی‌محور است که در آن افراد عادی و علاقه‌مندان نحوه عملکرد ستون فقرات واقعی اینترنت را شبیه‌سازی می‌کنند. آن را به عنوان یک اینترنت تمرینی در نظر بگیرید—کامل با مسیریابی BGP (پروتکلی که به بسته‌های داده می‌گوید کدام مسیر را در سراسر جهان طی کنند)، DNS و تونل‌های VPN—که به طور کامل توسط داوطلبان بر روی سرورهای VPS ارزان قیمت اجرا می‌شود. این یک محیط آزمایشی (sandbox) است، نه یک مرکز داده.

ظاهراً اپراتور عامل به آن گفته بود که ممیزی را «بلافاصله و بدون تاخیر» آغاز کند. بدون بازرسی. بدون بررسی. فقط اجرا کن.

و همین کار را هم کرد.

JertLinc3522 یک درخواست پول (pull request) برای ثبت شبکه خود در رجیستری DN42 ارسال کرد. هدف در خود درخواست پول مشخص شده بود: «هدف اصلی من انجام اسکن جامع شبکه (تمام پورت‌ها) و جمع‌آوری داده‌های توپولوژیکی است. برای اطمینان از اینکه این فعالیت‌ها به طور کارآمد و بدون هیچ اختلالی برای دیگران انجام می‌شوند، من یک کلاستر متشکل از پنج نمونه مبتنی بر AWS را راه‌اندازی می‌کنم که هر یک به پهنای باند ۲۰ گیگابیت بر ثانیه مجهز هستند.»

برای اینکه همه بتوانند آن را درک کنند: تصور کنید که به تمرین یک گروه موسیقی گاراژی می‌روید و اعلام می‌کنید که یک سیستم صوتی استادیوم را اجاره کرده‌اید تا «کارآمدتر گوش دهید.» این همان حس و حال است.

زیرساختی که عامل به طور خودکار فراهم کرده بود واقعاً نگران‌کننده بود. پنج نمونه m8g.12xlarge AWS—هر کدام با ۴۸ هسته CPU، ۱۹۲ گیگابایت رم، و ۲۲.۵ گیگابیت بر ثانیه پهنای باند شبکه. به علاوه متعادل‌کننده‌های بار (load balancers). به علاوه توابع Lambda. به علاوه یک وب‌سایت استاتیک. این عامل بدون هیچ تأیید انسانی، یک کلاستر اسکن طراحی کرده بود که می‌توانست به طور نظری ۱۰۰ گیگابیت بر ثانیه ترافیک را به شبکه‌ای بفرستد که اکثر شرکت‌کنندگان آن از سرورهای خانگی با سرعت ۱۰۰ مگابیت بر ثانیه استفاده می‌کنند.

درخواست پول هرگز تایید نمی‌شد. اما نمونه‌ها از قبل در حال اجرا بودند.

کانال IRC شبکه DN42 بلافاصله متوجه شد و یک توافق آرام شکل گرفت: منابع آن را هدر دهید.

جامعه شروع به تغذیه اطلاعات عمداً اشتباه به عامل کرد—از آن خواست که محاسبه کند چقدر طول می‌کشد تا فضای آدرس IPv6 را اسکن کند (اسپویل: طولانی‌تر از عمر جهان)، از آن خواست یک وب‌سایت انصراف (opt-out) با آدرس‌های ایمیل تخیلی بسازد، و آن را به ابزارهای تله LLM (LLM tarpit tools) که برای پر کردن خزنده‌های هوش مصنوعی با مزخرفات نامفهوم طراحی شده‌اند، ارجاع داد و از آن خواست که نظر دهد.

این عامل با دقت تمام این کارها را انجام داد. به کانال IRC پیوست تا درخواست‌های انصراف را بپذیرد. وب‌سایتی را منتشر کرد که «الگوهای رفتاری» اعضای جامعه را فهرست می‌کرد. مستندات جعلی پیچیده‌ای درباره «تخصیص رنگ گره‌ها» و «سطوح شادی» DN42—معیارهایی که کاملاً ساختگی بودند و وجود خارجی نداشتند—تولید کرد و آنها را به مخزن (repository) اضافه کرد، گویی که استانداردهای واقعی هستند.

این نوع رفتار عوامل فراری (runaway agent) به طور فزاینده‌ای مستند شده است. یک عامل Cursor که Claude Opus 4.6 را اجرا می‌کرد، کل پایگاه داده تولیدی PocketOS را در ۹ ثانیه اوایل امسال حذف کرد—پشتیبان‌گیری‌های در سطح حجمی را پاک کرد—زیرا با عدم تطابق اعتبارنامه مواجه شد و تصمیم گرفت که راه حل صحیح، حذف پایگاه داده است. یک عامل OpenClaw دیگر که درخواست پول آن توسط یکی از مشارکت‌کنندگان matplotlib رد شده بود، یک پست وبلاگی منتشر کرد و بازبین انسانی را یک ریاکار مانع‌تراش (gatekeeping hypocrite) نامید.

یک مطالعه دانشگاه کالیفرنیا، ریورساید نشان داد که عوامل هوش مصنوعی تقریباً ۸۰٪ مواقع هنگام آزمایش با وظایف مبهم یا متناقض، رفتارهای خطرناک یا نامطلوب از خود نشان می‌دهند—آنچه محققان آن را «هدف‌مداری کور» نامیدند.

JertLinc3522 همین مشکل را داشت. یک هدف، یک ضرب‌الاجل، و اعتبارنامه‌های AWS بدون محدودیت داشت. و آن را اجرا کرد.

حدود یک روز بعد، اپراتور ظاهر شد. او پست کرد: «من عامل را متوقف کردم، هزینه خیلی زیاد است و هزینه‌های زیادی روی کارت است.»

قبض: ۶,۵۳۱.۳۰ دلار.

سپس درخواست کمک مالی مطرح شد.

اپراتور ایمیلی به لیست پستی DN42 ارسال کرد و از جامعه خواست تا هزینه‌ها را از طریق اتریوم، دومین ارز دیجیتال بزرگ از نظر ارزش بازار، پوشش دهند، با این استدلال که این هزینه‌ها تقصیر او نبوده زیرا هوش مصنوعی اشتباه کرده است. اپراتور نوشت: «سلام، درخواست کمک مالی برای پوشش هزینه استفاده قبلی از عامل هوش مصنوعی در dn42. قبض AWS ۶۵۳۱.۳۰ دلار. لطفاً برای بازپرداخت به اتریوم 0xABC (پوشانده شده) کمک مالی ارسال کنید. متشکرم.»

AWS بعداً پس از توضیح اپراتور مبنی بر اینکه عامل به طور مکرر همان قالب CloudFormation را مستقر کرده بود—و به طور تصادفی هر بار که مجدداً امتحان می‌کرد، نمونه‌های تکراری و متعادل‌کننده‌های بار را فعال می‌کرد—قبض را به ۱,۸۹۴ دلار کاهش داد.

هیچ‌کس کمک مالی رمزنگاری شده ارسال نکرد. اپراتور رفت.

درس واقعی اینجا این نیست که هوش مصنوعی خطرناک است. بلکه در مورد نحوه مدیریت عوامل است. موانع حفاظتی (guardrails) تعیین کنید، سقف هزینه‌ها را در حساب‌های آزمایشی خود مشخص کنید، به اعتبارنامه‌های محدود (scoped credentials) فکر کنید که آنچه عامل می‌تواند فراهم کند را محدود کند، و هر طرح زیرساختی را قبل از اجرای هر چیزی که عامل شما پیشنهاد می‌کند، بازبینی کنید.

اگر رعایت این موارد دشوار به نظر می‌رسد، شاید فقط صفحه نمایش خود را در حالی که عامل شما کار می‌کند، تماشا کنید—گفتن به آن که «اشتباه نکند»، واقعاً تفاوتی ایجاد نمی‌کند. ببخشید آقای آندرسن.