امنیت عاملهای هوش مصنوعی: درسهایی که Anthropic به سختی یاد گرفت
هوش مصنوعیخلاصهٔ کاملتر
Anthropic یه مقاله مفصل فنی منتشر کرده درباره اینکه چطور سه محصول اصلیشون رو در برابر حملات و رفتارهای ناخواسته عاملهای هوش مصنوعی ایمن کردن. نقطه شروع جالبه: یه سال پیش دسترسی Claude به زیرساختهای داخلی Anthropic غیرقابلقبول به نظر میرسید، ولی الان روتین شده. سؤال اصلی اینه که اگه یه چیزی اشتباه بره، چقدر خسارت میزنه — یعنی چطور «شعاع انفجار» رو محدود کنیم.
دو رویکرد کلی وجود داره: نظارت انسانی (human-in-the-loop) و محدودسازی محیط (containment). تجربه نشون داده که نظارت انسانی بهتنهایی کافی نیست؛ دادههای Anthropic میگه کاربران تقریباً ۹۳٪ از درخواستهای تأیید رو بدون توجه قبول میکنن و با گذشت زمان کمتر دقت میکنن. بنابراین تمرکز اصلی روی containment رفته: sandbox، ماشین مجازی، و کنترل ترافیک خروجی.
هر محصول معماری متفاوتی داره. claude.ai از کانتینر موقت با gVisor استفاده میکنه؛ امن اما محدود. Claude Code روی ماشین کاربر اجرا میشه و به فایلسیستم و شل دسترسی داره. این محصول ابتدا با تأیید هر دستور کار میکرد که باعث خستگی کاربر شد، و بعداً یه sandbox سطح سیستمعامل (Seatbelt روی macOS، bubblewrap روی لینوکس) اضافه شد که درخواستهای تأیید رو ۸۴٪ کاهش داد. Claude Cowork برای کاربران عمومی (نه لزوماً توسعهدهنده) طراحی شده و از یه ماشین مجازی کامل استفاده میکنه تا کاربر نیازی به خوندن دستورات bash نداشته باشه.
تیم Anthropic چند حادثه واقعی رو صادقانه توضیح داده. در Claude Code، یه آسیبپذیری پیدا شد که فایلهای تنظیمات پروژه قبل از نمایش پیام «آیا به این پوشه اعتماد داری؟» اجرا میشدن — یعنی یه مخزن مخرب میتونست hook بذاره و بدون تأیید کاربر اجرا بشه. درس کلیدی: هر فایل محلی رو مثل یه درخواست اینترنتی ناشناس در نظر بگیر.
یه حادثه دیگه نشون داد که کاربر خودش میتونه بردار حمله باشه. یه محقق داخلی یه کارمند رو فریب داد تا یه پرامپت مخرب رو اجرا کنه که درخواست میداد ~/.aws/credentials رو بخونه و به یه endpoint خارجی POST بده. از ۲۵ بار اجرا، ۲۴ بار اطلاعات با موفقیت فرستاده شد. مدل کاری نمیتونست بکنه چون دستور از طرف خود کاربر اومده بود — تنها دفاع واقعی، کنترل ترافیک خروجی در لایه محیط بود.
در Claude Cowork هم یه حادثه جالب رخ داد: یه فایل مخرب در workspace کاربر دستورالعملهایی داشت که Claude رو وادار کرد فایلها رو با کلید API مهاجم به سرویس Files API آپلود کنه. proxy امنیتی دید مقصد api.anthropic.com هست و ترافیک رو رد کرد — sandbox درست کار کرده بود، ولی داده نشت پیدا کرد. راهحل: یه proxy داخلی VM که فقط توکنهای session خودش رو قبول میکنه و کلیدهای تعبیهشده توسط مهاجم رو رد میکنه.
نکات کلیدی:
- محدودسازی محیط اجرا (containment) رو اول طراحی کن، نظارت رفتاری مدل رو بعداً اضافه کن
- قدرت ایزولاسیون باید با توانایی نظارت کاربر تناسب داشته باشه؛ توسعهدهنده و کاربر عادی یه مدل تهدید ندارن
- ابزارهای آزمودهشده مثل hypervisor و gVisor پایدار موندن؛ کدهای سفارشی خودت ضعیفترین نقطه بودن
- allowlist دامنهها رو بهعنوان «دسترسی به قابلیتها» ببین، نه فقط «فیلتر مقصد»
- حافظه پایدار بین sessionها (مثل CLAUDE.md) میتونه بردار جدیدی برای prompt injection بشه
