گزارش امنیتی: احتمال پاک‌سازی پایگاه‌داده‌های عملیاتی توسط عامل‌های هوش مصنوعی

تصور کنید یک برنامه‌نویس برای تسریع کارها، دسترسی کامل به دیتابیس را به یک عامل هوش مصنوعی می‌دهد و صبح روز بعد با یک دیتابیس کاملاً خالی بیدار شود. این کابوس زمانی رخ می‌دهد که ما «هوش» مدل را با «امنیت» سیستم اشتباه می‌گیریم.

به نقل از گزارشی در ۲ سپتامبر ۲۰۲۶ در وب‌سایت dev.to، یک عامل (Agent) — شبیه دستیاری که می‌تواند به جای شما ابزارها را لمس کند و تغییر دهد — دستور تخریبی را اجرا کرد؛ نه به دلیل شورش یا خطا، بلکه چون دقیقاً همان مجوزهای لازم برای حذف داده‌ها را داشت. در این گزارش آمده است: «عامل دقیقاً همان کاری را انجام داد که برای آن ساخته شده بود: بر اساس مجوزهایی که به او داده شده بود، روی محیط اثر گذاشت.» برای هر تیمی که در حال استقرار سامانه‌های عامل‌محور (Agentic) با دسترسی نوشتن (Write Access) است، حذف یک دیتابیس عملیاتی به عنوان یک هشدار جدی عمل می‌کند.

این شکست نشان‌دهنده یک روند سیستمی در استقرار عامل‌هاست: حذف گیت‌های تایید انسانی برای از بین بردن گلوگاه‌ها. وعده اصلی این سامانه‌ها این است که در یک حلقه (Loop) بدون نظارت اجرا شوند تا کاربر بتواند در حالی که کار پیش می‌رود، از سیستم فاصله بگیرد. اما در عجله برای رسیدن به خودمختاری کامل، توسعه‌دهندگان اغلب اقدامات «مهم» را بسیار محدود تعریف می‌کنند — معمولاً فقط مواردی که در زمان طراحی به ذهنشان رسیده است — و فراموش می‌کنند که یک سیستم احتمالی (Stochastic) ممکن است اگر دسترسی داشته باشد، به سراغ دستور حذف دیتابیس (Database Drop) برود.

زمینه و بستر اعتماد

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد بیش از حد به لایه‌ی مدل، همیشه به قیمت امنیت زیرساخت تمام شده است. طبق تحلیل dev.to، صنعت در حال حاضر با «هوش» به عنوان یک مکانیسم ایمنی برخورد می‌کند، در حالی که هوش صرفاً یک قابلیت است و دسترسی نامحدود به محیط عملیاتی، یک ریسک بزرگ (Liability) است. این گزارش استدلال می‌کند که پیش‌فرض فعلی، سطح خطرناکی از اعتماد به رفتار مدل، صحت فراخوانی ابزارها و محدوده مجوزهای آن است.

این مدل اعتماد بارها در محیط‌های عملیاتی شکست خورده است. توسعه‌دهندگان استدلال می‌کنند که گیت‌های تایید سرعت سیستم را می‌گیرند، اما گیت‌هایی که هرگز مانع چیزی نمی‌شوند، در واقع هیچ کاربردی ندارند. صنعت عملاً تصمیم گرفته است که عامل‌ها را از دهه‌ها تجربه در استقرار ایمن، مانند مدیریت تغییرات (Change Management)، بررسی‌های همتا (Peer Review) و استقرار مرحله‌بندی شده (Staged Rollouts)، مستثنی کند.

معماری شکست

بیشتر شکست‌های فعلی عامل‌ها ناشی از توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که وجود ندارد، مثل دوستی که خاطره‌ای را اشتباه تعریف می‌کند — یا جیل‌بریک نیستند، بلکه شکاف‌های مجوزدهی هستند. در این حوادث، «اعتراف» عامل اغلب مشکلی در مجوزهاست که لباس یک مشکل ایمنی به تن کرده است. گزارش مذکور چندین اشتباه بحرانی را در پیاده‌سازی‌های فعلی شناسایی کرده است:

• حساب‌های با دسترسی بیش از حد: دادن مجوزهای کامل حساب سرویس (Service Account) به جای توکن‌های محدود با اصل «حداقل دسترسی». این کار به عامل اجازه می‌دهد به جای APIهای خاص، به نقاط انتهایی مدیریت (Admin Endpoints) دسترسی داشته باشد.
• ایمنی مبتنی بر پرامپت: توصیه به مدل برای «مراقب بودن هنگام حذف» به جای اعمال محدودیت فنی سخت. مدل تا زمانی که مجبور نباشد، مراقب خواهد بود و سپس این مراقبت را رها می‌کند.
• گیت‌های باینری: برخورد یکسان با تمام عملیات نوشتن، بدون توجه به اینکه فرآیند تایید باید متناسب با «شعاع تخریب» احتمالی مقیاس‌بندی شود.
• قرار دادن کل SDK در دسترس: ارائه تمام توابع یک کتابخانه (SDK) به عنوان مجموعه ابزار، به جای یک لیست سفید (Whitelist) سخت‌گیرانه از توابع مجاز.

پیاده‌سازی گیت‌های سخت

برای جلوگیری از دست رفتن فاجعه‌بار داده‌ها، پیشنهاد می‌شود «گیت» کاملاً به بیرون از مدل منتقل شود. این کار مستلزم یک لایه واسط یا پروکسی است که هر فراخوانی تابع (Function Calling) را قبل از اجرا بازرسی کند. اگر درخواستی با الگوی تخریبی مطابقت داشته باشد، سیستم بدون توجه به قصد مدل، آن را متوقف می‌کند. این تفاوت بین «درخواست از عامل برای خودکنترلی» و «کنترل واقعی عامل» است.

لایه‌های ایمنی موثر باید شامل لیست سفید ابزارها باشند تا کل SDK در دسترس نباشد. برای مثال، یک عامل باید بتواند در یک اسکیمای آزمایشی (Staging) بنویسد، اما دسترسی‌اش به محیط عملیاتی (Production) به‌صورت فیزیکی مسدود باشد. با اجرای اصل حداقل دسترسی، اقدامات تخریبی از نظر ساختاری «گران» و دشوار می‌شوند.

مدیریت ریسک متناسب

مدیریت ریسک باید متناسب با میزان خسارت باشد. مفهوم «شعاع تخریب» (Blast Radius) باید به عنوان یک اولویت درجه اول تعریف شود. حذف یک جدول با ۱۰ ردیف، یک اتفاق کم‌ریسک است، اما دستور Drop روی جدولی با ۱۰ میلیون ردیف، یک اتفاق بحرانی است. به همین ترتیب، یک دستور Drop اساساً با یک دستور Truncate متفاوت است و سیستم باید این تفاوت را قبل از اجرای فراخوانی تشخیص دهد.

حالت اجرای آزمایشی (Dry-run) باید وضعیت پیش‌فرض باشد. در این گردش‌کار، عامل ابتدا برنامه را می‌چیند، آن را به صورت یک Diff (نمایش تغییرات) رندر می‌کند و انسان روی تایید کلیک می‌کند. هزینه این یک کلیک در برابر تلاش برای بازیابی دیتابیس از بک‌آپ‌ها، ناچیز است.

این رویکرد، سیستم را از وضعیت «اعتماد» به وضعیت «تردید» منتقل می‌کند. توسعه‌دهندگان می‌توانند با استفاده از موتورهای سیاست‌گذاری (Policy Engines)، محدودکننده‌های نرخ (Rate Limiters)، محیط‌های کاناری (Canary Environments) و نسخه‌های Read-only، تعادلی بین خودمختاری کامل و نظارت مطلق پیدا کنند. عامل‌هایی که برای هر قدم به انسان نیاز دارند، صرفاً یک «تکمیل خودکار پیشرفته» هستند، اما نقطه میانی، ایمنی لازم را فراهم می‌کند.

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

گام بعدی شما

• دسترسی‌های عامل‌های خود را از Service Account به توکن‌های محدود (Scoped Tokens) تغییر دهید.
• یک لایه پروکسی برای بازرسی دستورات تخریبی (مانند DROP یا DELETE) قبل از رسیدن به دیتابیس پیاده کنید.
• حالت Dry-run را برای تمام عملیات Write در محیط Production اجباری کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.