ده فرمان امنیتی برای عامل‌های هوش مصنوعی برنامه‌نویس

با گسترش استفاده از عامل‌های هوش مصنوعی در توسعهٔ نرم‌افزار، پرسش اصلی این است: چگونه باید دسترسی‌ها و امنیت این ابزارها را مدیریت کرد؟ 🛡️

وینای تاکر، مدیر فنی شرکت KloudStax، در مصاحبه‌ای با مجلهٔ Help Net Security به تشریح اصول کنترل دسترسی برای عامل‌های هوش مصنوعی پرداخته است. او توضیح می‌دهد که ده خط نخست سیاست دستوری برای یک عامل برنامه‌نویسی چه باید باشد و تیم‌های قرمز (Red Teams) چگونه باید استقرار این عامل‌ها را آزمایش کنند.

🪪 هویت عامل: نه قرض گرفتن، نه استقلال مطلق

تاکر معتقد است عامل هوش مصنوعی نباید صرفاً هویت انسانی را که آن را اجرا کرده قرض بگیرد و نباید هم کاملاً مستقل عمل کند. سؤال کلیدی این است: آیا عامل در حال انجام کاری برای کل کسب‌وکار است یا وظیفه‌ای برای یک فرد خاص؟

• 🏢 اگر کار برای کسب‌وکار باشد (مثل دسته‌بندی بلیت‌های پشتیبانی)، عامل هویت خودش را دارد و دسترسی‌هایش محدود به همان وظیفه است.
• 👤 اگر کار برای یک فرد باشد (مثل اعمال تغییرات زیرساختی توسط یک مهندس)، عامل باز هم هویت خودش را دارد اما هر درخواست، هویت شخص درخواست‌کننده را نیز حمل می‌کند.

در این حالت، عامل تنها کارهایی را انجام می‌دهد که هم خودش و هم کاربر اجازهٔ آن را دارند و در لاگ‌ها نام هر دو ثبت می‌شود. قرض گرفتن مستقیم حساب کاربری انسان رد می‌شود، زیرا اقدامات عامل از اقدامات انسان غیرقابل تفکیک خواهد شد.

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

هرگز نباید یک راز بلندمدت را مستقیماً به عامل داد. تاکر دو تصمیم مهم را از هم تفکیک می‌کند: طول عمر اعتبارنامه و اینکه آیا عامل اصلاً آن را در اختیار می‌گیرد یا خیر.

«یک پروکسی که اعتبارنامه را به هر درخواستی که عامل می‌سازد ضمیمه می‌کند، در واقع یک نمایندهٔ سردرگم (Confused Deputy) است که منتظر دستور می‌ماند.»

قوی‌ترین ساختارها هر دو روش را ترکیب می‌کنند: پروکسی هویت عامل را تأیید می‌کند، یک اعتبارنامهٔ کوتاه‌مدت مختص همان فراخوانی دریافت می‌کند و آن را هنگام خروج ضمیمه می‌سازد. حتی اگر توکن کوتاه‌مدتی مستقیماً به عامل داده شود، باید به ماشین یا کانتینری که آن را درخواست کرده گره بخورد تا نسخهٔ لو رفته در جای دیگر بی‌استفاده باشد.

⚡ ده خط سیاست دستوری برای عامل برنامه‌نویسی

برای عاملی که به ترمینال دسترسی دارد، تاکر نوشتن یک فهرست مجاز (Allowlist) را پیشنهاد می‌کند، نه فقط فهرست ممنوعه؛ زیرا عامل همیشه راهی برای دور زدن ممنوعیت‌ها پیدا می‌کند. این ده خط باید توسط محیط اجرایی (Harness) اعمال شوند، نه با درخواست از مدل زبانی:

1. ⛓️ عامل فقط در یک مخزن بررسی‌شده در محیطی یکبارمصرف کار می‌کند و نمی‌تواند خارج از آن چیزی بخواند یا بنویسد.
2. ✅ فقط دستورات تأییدشده (ساخت، تست، لینتر، فرمت، گیت فقط‌خواندنی و ویرایش فایل) اجرا می‌شوند؛ بقیه نیاز به اجازه دارند.
3. 🚫 هیچ اعتبارنامه‌ای در محیط عامل وجود ندارد؛ هر نیازی از طریق یک واسطه رفع می‌شود.
4. 🛑 عامل نمی‌تواند فایل‌های حاوی راز (مثل .env یا کلیدهای SSH) را باز کند.
5. 🌐 دسترسی شبکه خاموش است، مگر برای مخزن بستهٔ داخلی و میزبان‌های مشخص پروژه.
6. 📦 بسته‌ها فقط از مخزن داخلی می‌آیند و افزودن وابستگی جدید نیازمند تأیید انسان است.
7. 🌿 عامل می‌تواند روی شاخهٔ خود کامیت کند و Pull Request باز کند، اما حق ادغام یا پوش اجباری ندارد.
8. ⚠️ هر تغییری در زیرساخت یا دادهٔ مشترک متوقف شده و درخواست تأیید می‌کند.
9. 🔒 عامل نمی‌تواند سطح دسترسی خود را ارتقا دهد یا سیاست‌هایش را تغییر دهد.
10. 📝 تمام دستورات با هویت عامل و وظیفهٔ محرک لاگ می‌شوند و سقف هزینه یا زمان اجرا، نشست را پایان می‌دهد.

تاکر تأکید می‌کند که بسیاری از این خطوط نباید صرفاً به سیاست دستوری وابسته باشند. محافظت از شاخه‌ها باید در سیستم کنترل نسخه، قوانین شبکه در فایروال و دسترسی اعتبارنامه‌ها در سیستم هویت تعریف شود.

🛰️ کنترل شبکه و جلوگیری از نشت داده

عامل باید بدون دسترسی شبکه آغاز به کار کند. آزمون تاکر این است: آیا یک عامل واحد، دادهٔ خصوصی، محتوای افراد غیرقابل‌اعتماد و راهی برای ارسال داده به بیرون را همزمان دارد؟ اگر پاسخ مثبت باشد، یک ایمیل یا بلیت آلوده برای خروج داده از شرکت کافی است.

نصب بسته‌ها جایی است که فهرست‌های مجاز معمولاً شکست می‌خورند، زیرا مخازن عمومی وارد لیست می‌شوند. استفاده از مخازن داخلی (Artifact Repositories) این شکاف را می‌بندد. پارامترهای URL چالش سخت‌تری هستند؛ یک درخواست GET ساده به میزبانی تأییدشده می‌تواند داده را در رشتهٔ جستجو حمل کند. راه‌حل تاکر طراحی است: وقتی عامل محتوای غیرقابل‌اعتماد خواند، نباید بتواند بدون تأیید انسانی داده‌ای ارسال کند یا اقدام حساسی انجام دهد. ✨

منبع: Help Net Security