آیا باید دسترسی کامل سرور را به هوش مصنوعی بدهیم؟

وسوسه واضح است: به Agent کلید SSH یا نقش Admin ابری بدهید تا «خودش دیپلوی و دیباگ کند». هزینهٔ این راحتی می‌تواند حذف دیتابیس، نشت Secret، یا اجرای دستور مخرب از مسیر Prompt Injection باشد. سؤال درست این نیست که آیا AI مفید است؛ این است که با چه مرزی مفید می‌ماند.

OWASP سال‌هاست Excessive Agency را ریسک می‌داند: دادن خودمختاری و ابزار بیش از حد به سیستم مبتنی بر LLM. NIST AI RMF هم بر ایمنی، امنیت، شفافیت و نظارت انسانی تأکید دارد. فروشنده‌هایی مثل Anthropic و Cursor در مستندات Agent، مجوز، سندباکس و ایزولاسیون VM را برجسته کرده‌اند — یعنی خودشان هم فرض «دسترسی کامل بی‌قید» را توصیه نمی‌کنند.

پاسخ کوتاه مقاله: تقریباً هرگز دسترسی کامل Production ندهید؛ دسترسی را لایه‌بندی، موقت، قابل ممیزی و نیازمند Approval کنید.

پاسخ کوتاه

به AI دسترسی root یا Owner ابری روی Production ندهید. از Least Privilege استفاده کنید: نقش حداقلی، محیط جدا (Staging/VM ایزوله)، سندباکس شبکه/فایل، تأیید انسانی برای دستورهای مخرب، و Audit کامل. Cloud Agent فقط داخل محدودهٔ تعریف‌شده و با Secretهای کوتاه‌عمر کار کند.

قدرت Agent را با شعاع انفجار محدود اندازه بگیرید، نه با هیجان اتوماسیون.

Excessive Agency یعنی چه؟

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

پنج اصل کنترل

۱) Least Privilege

فقط مجوزی بدهید که برای همان وظیفه لازم است. خواندن لاگ با نقش ReadOnly؛ دیپلوی با نقش جدا و محدود به یک سرویس؛ هرگز یک توکن همه‌کاره برای همهٔ Agentها.

۲) Sandbox

مستندات Claude Code از سندباکس Bash با ایزولاسیون فایل‌سیستم و شبکه و مرز دایرکتوری کاری صحبت می‌کند. Cursor Cloud Agents را در VM ایزوله توصیف می‌کند. ترجمه: کد و دستور را جایی اجرا کنید که خرابی‌اش Production را نمی‌کشد.

۳) Audit

هر فرمان، هر دسترسی Secret، هر Push باید قابل ردگیری باشد. بدون لاگ، بعد از حادثه فقط حدس می‌زنید. طرح‌های سازمانی Cursor و Claude و Copilot قابلیت‌های audit را برای همین لایه دارند.

۴) Approval

دستورهای پرریسک — حذف منبع، تغییر فایروال، مهاجرت دیتابیس، انتشار Production — باید تأیید انسان بخواهند. Auto-run را فقط برای مسیرهای Allowlistشده در محیط کم‌ریسک بگذارید.

۵) Credentials کوتاه‌عمر

به‌جای کلید ثابت روی دیسک Agent، از نقش موقت، OIDC، یا Secret با TTL استفاده کنید. بعد از اتمام کار، دسترسی بمیرد.

جدول تصمیم دسترسی

الگوی امن پیشنهادی

1. Agent روی شاخهٔ فیچر در محیط ایزوله کار می‌کند.
2. تست و lint در همان محیط اجرا می‌شود.
3. PR ساخته می‌شود؛ انسان Review می‌کند.
4. دیپلوی Staging با نقش محدود و لاگ.
5. Production فقط از Pipeline با Approval انسانی.

این الگو سرعت را حفظ می‌کند بدون اینکه کلید تاج را به مدل بدهید.

نشانه‌هایی که الان خطرناک کار می‌کنید

• کلید SSH Production داخل تنظیمات Agent ذخیره شده.
• Auto-approve برای همهٔ Bashها روشن است.
• یک توکن cloud با دسترسی Billing و IAM به چت وصل است.
• Agent می‌تواند از Staging به دادهٔ واقعی مشتری برسد.
• هیچ‌کس نمی‌تواند بگوید هفتهٔ پیش Agent چه دستوری زده.

اگر قبلاً دسترسی کامل داده‌اید

1. توکن‌ها و کلیدها را Rotate کنید.
2. نقش‌ها را به حداقل برش دهید.
3. Auto-run را خاموش یا محدود کنید.
4. لاگ‌های اخیر را برای دستور غیرعادی بررسی کنید.
5. سیاست مکتوب Least Privilege + Approval را اعلام کنید.

جمع‌بندی برای تصمیم

دسترسی کامل سرور به AI یک میان‌بر جذاب و معمولاً غیرقابل‌دفاع است. با Least Privilege، Sandbox، Audit، Approval و اعتبارنامهٔ موقت می‌توانید از قدرت Agent استفاده کنید بدون اینکه شعاع انفجار را به اندازهٔ کل زیرساخت کنید.

این هفته یک کار کنید: هر Secret و نقش Admin که به ابزار AI داده‌اید را فهرست و حداقل‌سازی کنید.

Cloud Agent در برابر Agent محلی

Agent محلی روی لپ‌تاپ شما به همان فایل‌ها و گاهی به همان SSH agentی دسترسی دارد که خودتان دارید. خطر اینجاست که مجوز انسانی‌تان را به مدل قرض می‌دهید. Cloud Agent طبق مستندات فروشندگانی مثل Cursor در VM جدا اجرا می‌شود؛ این ایزولاسیون خوب است، اما اگر همان VM به شبکهٔ Production یا Secretهای قوی وصل باشد، فقط محل اجرا عوض شده نه شعاع انفجار.

سؤال طراحی: این Agent اگر اشتباه کند یا فریب بخورد، بدترین کار ممکن چیست؟ اگر جواب «حذف کلاستر» است، طراحی غلط است.

الگوی Break-glass

برای مواقع نادر که انسان نیاز به دسترسی گسترده دارد، حساب break-glass با MFA، زمان‌محدود و آلارم اجباری تعریف کنید — و آن را به مدل ندهید. Agent حداکثر به نقش روزمرهٔ محدود برسد. این تفکیک جلوی عادت خطرناک «همان نقش Admin را به همه چیز وصل کنیم» را می‌گیرد.

شبکه و خروجی (egress)

حتی در سندباکس، اگر egress باز باشد، Agent می‌تواند داده را به مقصد ناخواسته بفرستد یا بستهٔ مخرب بگیرد. کنترل دامنه، پروکسی خروجی، و ممنوعیت پیش‌فرض curl/wget بدون تأیید — چنان‌که در راهنمای امنیتی Claude Code هم برای فرمان‌های شبکه سخت‌گیری دیده می‌شود — لایهٔ مهمی است.

برای MCP و کانکتورها هم همین منطق را اعمال کنید: هر سرور MCP یعنی سطح حملهٔ جدید. فقط منابع معتمد، با حداقل Scope.

معیار پذیرش امنیتی قبل از روشن کردن Agent روی سرور

1. فهرست دستورها و APIهای مجاز مکتوب است.
2. Secretها TTL دارند و در Vault/مدیر ابری‌اند نه در متن تنظیمات.
3. محیط اجرای Agent از Production جداست.
4. Audit روشن است و مسئول بررسی هفتگی دارد.
5. تمرین Tabletop یک‌صفحه‌ای برای سناریوی «Agent دستور خطرناک پیشنهاد کرد» انجام شده.

پاسخ به فشار مدیریتی «بگذار خودش دیپلوی کند»

اتوماسیون دیپلوی خوب است؛ مالک اتوماسیون باید Pipeline باشد نه گفت‌وگوی آزاد با LLM. Pipeline تکرارپذیر، Reviewپذیر و دارای Approval است. Agent می‌تواند PR دیپلوی یا تغییر مانیفست را آماده کند؛ فشردن دکمهٔ Production کار انسان یا سیستم کنترل‌شده است. این جمله را در سیاست بگذارید تا بحث هر بار از صفر شروع نشود.

تفکیک نقش‌ها: انسان، Pipeline، Agent

انسان هدف و ریسک را تعیین می‌کند. Pipeline تغییر را تکرارپذیر و قابل ممیزی اعمال می‌کند. Agent پیش‌نویس و اجرای محدود در سندباکس می‌سازد. وقتی این سه نقش قاطی شوند — مثلاً Agent هم بنویسد هم مستقیم روی Production اعمال کند — کنترل از بین می‌رود.

در تیم‌های کوچک وسوسهٔ یکی‌کردن نقش‌ها زیاد است. حداقل با دو محیط و یک Approval دستی برای Production، همان تیم سه نفره هم می‌تواند مرز را نگه دارد.

سؤالاتی که قبل از دادن دسترسی بپرسید

• اگر Prompt Injection موفق شود، چه منابعی در دسترس مهاجم است؟
• آیا می‌توانیم در کمتر از ۱۵ دقیقه همهٔ توکن‌های Agent را باطل کنیم؟
• آیا لاگ فرمان‌ها به سامانهٔ متمرکز می‌رود؟
• آیا محیط Agent به دادهٔ واقعی مشتری می‌رسد؟
• چه کسی هفته‌ای یک‌بار دسترسی‌ها را مرور می‌کند؟

اگر برای هر سؤال جواب عملی ندارید، دسترسی را گسترش ندهید.

جمع‌بندی عملیاتی

هدف، فلج کردن AI نیست؛ محدود کردن خسارت است. مثل سرویس production-facing با آن رفتار کنید: سطح حمله، پچ، مانیتورینگ، و پاسخ به حادثه. تیمی که این را بپذیرد، می‌تواند با خیال راحت‌تر از Agent برای کارهای بزرگ استفاده کند چون شعاع انفجار از قبل طراحی شده است.

طراحی دسترسی به‌سبک Zero Trust برای Agent

فرض کنید Agent هر لحظه ممکن است فریب بخورد یا اشتباه کند. بنابراین اعتماد دائمی به نشست Agent ندهید: هویت جدا، مجوز لحظه‌ای، و تأیید برای عمل حساس. این همان روح Least Privilege است که در امنیت کلاسیک می‌شناسید، فقط بازیگر جدید یک LLM است.

بخش‌بندی شبکه مهم است. Agent بیلد نباید به subnet پایگاه‌دادهٔ Production برسد. Agent تحلیل لاگ بهتر است روی کپی یا جریان خواندنی کار کند. هر اتصال عرضی را مثل استثنا مستند کنید.

زمان‌بندی دسترسی را جدی بگیرید. مجوز دیپلوی که همیشه روشن است خطرناک‌تر از مجوزی است که فقط در پنجرهٔ انتشار فعال می‌شود. با این کار حتی اگر توکن لو برود، پنجرهٔ سوءاستفاده کوچک‌تر است.

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

در محیط‌های Kubernetes یا ابری، به‌جای kubeconfig کامل، یک ServiceAccount با Role محدود به namespaceٔ مشخص به Agent بدهید و آن را زمان‌بندی‌شده باطل کنید.

برای دیتابیس، کاربر فقط‌خواندنی روی Replica معمولاً برای تحلیل کافی است؛ نوشتن را به مسیر مهاجرت کنترل‌شده بسپارید.

مستند معماری دسترسی را کنار ADR نگه دارید تا اعضای جدید نپرسند «چرا Agent به Production SSH ندارد؟» و از روی دلسوزی دوباره Admin نسازند.

اگر یک فروشنده وعدهٔ «امنیت کامل Agent» می‌دهد، باز هم مدل تهدید خودتان را بنویسید. مستندات رسمی مجوز و سندباکس نقطهٔ شروع‌اند نه پایان مسئولیت شما.

تصمیم نهایی مقاله را تکرار می‌کنیم: دسترسی کامل سرور به AI پیش‌فرض قابل‌قبول نیست؛ دسترسی محدود، موقت و قابل‌ممیزی هست.

برای تیم‌های کوچک که «Pipeline کامل نداریم» هم نسخهٔ حداقلی وجود دارد: شاخهٔ محافظت‌شده، Review اجباری، دیپلوی دستی از روی تگ، و Agent فقط روی شاخهٔ فیچر. این چهار مورد هزینهٔ کمی دارند و جلوی فاجعهٔ دسترسی کامل را می‌گیرند.

به زبان مدیریتی: هزینهٔ یک Incident ناشی از Agent با دسترسی Admin معمولاً از هزینهٔ چند ساعت اصطکاک Approval بیشتر است. امنیت این‌جا ضدسرعت نیست؛ ضد غافلگیری است.

هرگاه ابزار جدیدی با وعدهٔ «اتوماسیون سرور» آمد، همین مقاله را دوباره بخوانید و جدول تصمیم دسترسی را پر کنید. محصول عوض می‌شود؛ اصول Least Privilege و Audit عوض نمی‌شوند.

پیشنهاد اجرایی آخر: یک ماتریس دسترسی یک‌صفحه‌ای روی ویکی تیم بگذارید با ستون‌های محیط، نقش، مدت، Approval، و صاحب بازبینی. هر درخواست جدید Agent باید یک ردیف به این ماتریس اضافه کند قبل از صدور توکن.

با این نظم، بحث «آیا به AI دسترسی سرور بدهیم؟» از بله/خیر مطلق خارج می‌شود و به طراحی کنترل‌شده تبدیل می‌گردد — دقیقاً جایی که هم بهره‌وری و هم امنیت می‌توانند با هم جلو بروند.

این اصول را در کنار مقالات ۰۹۹ و ۱۰۴ بخوانید: بدون حفاظت Secret و بدون مدل تفویض کنترل‌شده، محدود کردن دسترسی سرور به‌تنهایی کامل نیست. دفاع لایه‌ای است.

برای جمع‌بندی تصمیم مدیریتی: اگر امروز مجبورید بین «Agent بدون دسترسی سرور» و «Agent با دسترسی کامل» یکی را انتخاب کنید، اولی را بگیرید و به‌تدریج دسترسی‌های باریک و ممیزی‌شده اضافه کنید. مسیر عکس — دادن همه چیز و بعد محدود کردن — از نظر رفتاری و عملیاتی بسیار سخت‌تر است.

منابع و مراجع

• OWASP GenAI LLM Top 10 (Excessive Agency theme) — https://genai.owasp.org/llm-top-10/
• OWASP LLM project page — https://owasp.org/www-project-top-10-for-large-language-model-applications/
• NIST AI RMF — https://www.nist.gov/itl/ai-risk-management-framework
• NIST AI 100-1 — https://doi.org/10.6028/NIST.AI.100-1
• Claude Code Security — https://code.claude.com/docs/en/security
• Cursor Cloud Agent security — https://cursor.com/docs/cloud-agent/security
• Cursor Privacy and Data Governance — https://cursor.com/docs/enterprise/privacy-and-data-governance

کنترل دسترسی را مثل کد Production Review کنید؛ چون همان‌قدر خطرناک است.