محافظ‌های MCP: دسترسی امن برای ایجنت‌های هوش مصنوعی

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

همهٔ مطالب زیر در تاریخ بالای صفحه روی سرور اصلی بررسی شده‌اند: فهرست ابزارها از tools/list روی https://mcp.eqvps.com/mcp آمده و محدودیت‌ها از خود API. اگر تازه شروع کرده‌اید، اول اتصال کلاینت MCP و توکن‌های API را بخوانید و بعد برگردید.

مدل تهدید: در عمل چه چیزی خراب می‌شود

سه چیز، به ترتیبی که می‌بینیم:

1. ایجنت اشتباه می‌فهمد. «ماشین تست را تمیز کن» تبدیل می‌شود به نصب مجدد سرور اشتباه. نیت بدی در کار نیست؛ فقط مدل جای خالی دستور را خودش پر کرده.
2. تزریق پرامپت. ایجنت متنی را می‌خواند که شما ننوشته‌اید (یک README، پاسخ پشتیبانی، صفحه‌ای از وب) و آن متن به او می‌گوید کاری بکند. اگر ایجنت توکنی با دسترسی کامل دارد، دستور تزریق‌شده هم همان دسترسی را دارد.
3. توکن نشت می‌کند. سر از تاریخچهٔ shell، یک مخزن عمومی، کانفیگ مشترک MCP یا یک خط لاگ درمی‌آورد.

سرور MCP بررسی می‌کند که توکن معتبر باشد و سرور متعلق به همان حساب باشد (یا به آن واگذار شده باشد). نمی‌داند منظور شما چه بوده. هر محافظ زیر به یک پرسش پاسخ می‌دهد: اگر دستور اشتباه باشد، چقدر خسارت ممکن است؟

همهٔ ابزارهای MCP بر اساس سطح ریسک

توکن مشتری ۴۵ ابزار می‌بیند (سرور MCP نسخهٔ 1.6.0). توکن نمایندهٔ فروش (rk_…) مجموعهٔ جداگانه‌ای از ۳۰ ابزار نمایندگی می‌بیند و هیچ‌کدام از این‌ها را نه؛ پس این endpoint در مجموع ۷۵ ابزار دارد. کلاینت شما از tools/list فقط مجموعهٔ خودش را می‌گیرد.

این صفحه ابزارها را بر اساس ریسک مرتب می‌کند. پارامترها و نمونه فراخوانی‌های هر ابزار در مرجع پارامترها آمده است؛ همهٔ ابزارها در یک سطر، از جمله ۳۰ ابزار نمایندگان فروش، در فهرست کامل هستند.

ما هنوز حاشیه‌نویسی ابزارهای MCP (readOnlyHint، destructiveHint) را ارسال نمی‌کنیم، پس کلاینت نمی‌تواند خودش آن‌ها را دسته‌بندی کند. تأییدها را بر اساس سطوح زیر دستی تنظیم کنید.

سطح ۰ — عمومی، بدون توکن (۵)

سطح ۱ — خواندن حساب، بدون اثر جانبی (۱۵)

سطح ۲ — وضعیت را تغییر می‌دهند، چیزی خرج نمی‌کنند (۱۷)

سطح ۳ — پول خرج می‌کنند، داده پاک می‌کنند یا دسترسی می‌دهند (۸)

تغییرات مجموعهٔ ابزارها

نسخهٔ در حال اجرا عمومی است: curl -s https://mcp.eqvps.com/healthz. هر وقت تغییر کند، این جدول هم با آن تغییر می‌کند.

موجودی همان سقف خرج است

EQVPS پیش‌پرداخت است. نه کارت ذخیره‌شده، نه اعتبار، نه موجودی منفی: بیشترین مبلغی که ایجنت می‌تواند خرج کند همان چیزی است که در موجودی هست. سه ابزار پول خرج می‌کنند: order_vps، change_plan و create_sandbox. تمدید سرورهای فعلی شما هم از همان موجودی کم می‌شود.

ایجنت می‌تواند درخواست پرداخت بسازد، اما نمی‌تواند پرداختش کند. topup_balance و pay_invoice یک لینک پرداخت رمزارزی برمی‌گردانند و لینکی که کیف پولی پشتش نباشد هیچ کاری نمی‌کند. endpoint برداشت هم وجود ندارد: پولِ موجودی فقط می‌تواند در حساب شما سرویس بخرد، نه اینکه بیرون برود. بازپرداخت لغو فوری هم به موجودی برمی‌گردد.

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

حداقل دسترسی: توکن فقط‌خواندنی (هنوز) نداریم

صاف و ساده: هر توکن مشتری همان دسترسی‌های حساب در داشبورد را دارد. نام و مدت اعتبار توکن قابل تنظیم است، اما دامنهٔ دسترسی (scope) نه.

محدودترین گزینه‌ای که امروز وجود دارد واگذاری دسترسی است. به ایجنت یک حساب جداگانه با موجودی صفر می‌دهید و یک سرور را به آن واگذار می‌کنید:

delegate_service  { "service_id": "EQ-XXXX", "email": "agent@yourdomain.com", "expires_days": 30 }

همین کار با REST:

curl -s -X POST "https://api.eqvps.com/api/v1/eqvps/services/EQ-XXXX/delegations" \
  -H "Authorization: Bearer $EQVPS_TOKEN" -H "Content-Type: application/json" \
  -d '{"email":"agent@yourdomain.com","expires_days":30}'

دعوت‌نامه باید در حالی پذیرفته شود که با همان ایمیل وارد شده‌اید (accept_delegation) و expires_days می‌تواند از ۱ تا ۳۶۵ باشد. گام‌به‌گام با تصویر: واگذاری دسترسی و بخش دسترسی در مستندات.

به دو سطر آخر ستون سمت راست دقت کنید. واگذارشده نمی‌تواند پول شما را خرج کند، اما می‌تواند آن سرور را پاک کند. روی هر سروری که ایجنت می‌تواند دوباره نصبش کند، پشتیبان‌گیری را فعال کنید.

بهداشت توکن

برای هر ایجنت یک توکن، با نام. آن را از داشبورد ← تنظیمات ← توکن‌های API برای ایجنت‌ها بسازید، یا این‌طور:

curl -s -X POST "https://api.eqvps.com/api/v1/eqvps/auth/tokens" \
  -H "Authorization: Bearer $EQVPS_TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"backup-agent","expires_in_days":90}'

توکن فقط یک بار نمایش داده می‌شود. مدت اعتبار ۱ تا ۱۸۲۵ روز است و اگر چیزی تعیین نکنید ۳۶۵. برای ایجنت‌ها ما ۹۰ را انتخاب می‌کردیم.

آن را در فایلی نگه دارید که فقط خودتان بتوانید بخوانید، نه در مخزن، نه در پرامپت، نه در متغیر shell که این‌طرف و آن‌طرف کپی‌اش می‌کنید:

mkdir -p ~/.config/eqvps && chmod 700 ~/.config/eqvps
( umask 077; read -rsp 'EQVPS token: ' T; echo; printf 'EQVPS_TOKEN=%s\n' "$T" > ~/.config/eqvps/agent.env )
ls -l ~/.config/eqvps/agent.env   # انتظار: -rw-------

سپس آن را در سرویس ایجنت با EnvironmentFile= (systemd) یا set -a; . ~/.config/eqvps/agent.env; set +a بارگذاری کنید.

پیش از انقضا عوضش کنید. ابزار refresh_token یا POST /auth/tokens/{id}/refresh توکن جدیدی با همان نام صادر می‌کند و قدیمی را فوراً باطل می‌کند. اگر توکن مستقیم در کانفیگ کلاینت MCP نوشته شده، بلافاصله بعد از آن به‌روزش کنید، وگرنه نشست بعدی 401 می‌گیرد.

ببینید چه کسی از چه چیزی استفاده می‌کند: GET /auth/tokens هر توکن را با نام، تاریخ انقضا و last_used_at نشان می‌دهد. توکنی که نمی‌شناسید، یا توکنی که بعد از خاموش کردن ایجنت استفاده شده، زنگ خطر است.

اگر توکنی نشت کرد

به همین ترتیب:

1. باطلش کنید. داشبورد ← تنظیمات ← توکن‌های API برای ایجنت‌ها ← ابطال، یا curl -s -X DELETE -H "Authorization: Bearer $EQVPS_TOKEN" https://api.eqvps.com/api/v1/eqvps/auth/tokens/<id>. از درخواست بعدی دیگر کار نمی‌کند.
2. دنبال توکن‌های جدید بگردید که خودتان نساخته‌اید، و آن‌ها را هم باطل کنید.
3. دامنهٔ آسیب را بررسی کنید: تاریخچهٔ سرویس هر سرور، فاکتورها و موجودی، و list_delegations برای دسترسی‌ای که شما نداده‌اید.
4. رمز root را عوض کنید، روی همهٔ سرورهایی که آن توکن می‌دید. get_vps_status با reveal: true رمز root را تحویل می‌دهد، پس توکن نشت‌کرده یعنی رمز root نشت‌کرده. همان‌جا ~/.ssh/authorized_keys را هم بررسی کنید.
5. درِ رمز عبور را ببندید. اگر حساب شما هرگز رمز نداشته، کسی که توکن را داشته ممکن است با set_password رمزی تعیین کرده باشد. با کد ایمیلی وارد شوید و رمز را عوض کنید.

پیشگیری از گام ۵ هزینه‌ای ندارد: همین حالا خودتان برای حساب رمز بگذارید تا set_password برای هر کسی که بعد از شما بیاید 409 برگرداند.

تأیید انسانی

آنچه سرور اعمال می‌کند:

• reinstall_vps، reset_password و cancel_service با type: immediate نیاز دارند confirm دقیقاً برابر نام میزبان باشد (DELETE هم برای نصب مجدد و بازنشانی کار می‌کند).
• change_plan به confirm: true نیاز دارد.
• لغو پیش‌فرض end_of_period است: سرور تا پایان دورهٔ پرداخت‌شده کار می‌کند و undo_cancel آن را برمی‌گرداند.
• محدودیت نرخ برای هر حساب: نصب مجدد ۴ در دقیقه، بازنشانی رمز ۶ در دقیقه، روشن/خاموش ۲۰ در دقیقه، سفارش ۲۰ در دقیقه. کافی است تا یک حلقه همان کار را پنجاه بار انجام ندهد، اما برای جلوگیری از یک فراخوانی اشتباه کافی نیست.

روشن باشید که confirm چیست. جلوی ایجنت را می‌گیرد که با یک «آنجا را تمیز کن» دست به کار شود. جلوی مهاجم را نمی‌گیرد، چون نام میزبان فقط یک فراخوانی get_vps_status فاصله دارد. تأیید واقعی در کلاینت MCP شماست. بیشتر کلاینت‌ها می‌توانند پیش از هر فراخوانی ابزار بپرسند: سطح ۰ و ۱ را آزاد بگذارید و سطح ۳ را همیشه روی پرسیدن بگذارید. در کلاینت‌هایی که دسترسی را برای هر ابزار جدا تنظیم می‌کنند، مثل settings.json در Claude Code (سرور با نام eqvps ثبت شده):

{
  "permissions": {
    "ask": ["mcp__eqvps__order_vps", "mcp__eqvps__change_plan", "mcp__eqvps__create_sandbox", "mcp__eqvps__reset_password", "mcp__eqvps__delegate_service"],
    "deny": ["mcp__eqvps__reinstall_vps", "mcp__eqvps__cancel_service", "mcp__eqvps__kill_sandbox"]
  }
}

یک خط هم به دستورالعمل‌های ایجنت اضافه کنید. به‌تنهایی سازوکار امنیتی نیست، اما موارد «بد فهمیدن» را کم می‌کند (به انگلیسی نگهش دارید، مدل‌ها همان‌قدر خوب می‌فهمندش):

Never call reinstall_vps, reset_password, cancel_service (type=immediate), change_plan,
order_vps, create_sandbox, kill_sandbox or delegate_service unless the human has typed
the target server's hostname in this conversation for that specific action.

اگر ایجنت به‌جای نگه‌داشتن توکن بلندمدت با کد ایمیلی وارد می‌شود، ورود ایجنت از طریق MCP را ببینید.

ممیزی: بعداً چه می‌بینید

• فهرست توکن‌ها (GET /auth/tokens یا تنظیمات ← توکن‌های API برای ایجنت‌ها): نام، تاریخ ساخت، انقضا، last_used_at. دلیل اینکه توکن‌ها را به نام هر ایجنت نام‌گذاری کنید همین است.
• تاریخچه سرویس (داشبورد، صفحهٔ سرور): عملیات روشن/خاموش، نصب‌های مجدد، بازنشانی رمز، تغییر پلن، پرداخت‌ها؛ هرکدام با زمان و انجام‌دهنده: شما، پشتیبانی یا خودکار. نمی‌گوید کدام توکن یا کدام واگذارشده این کار را کرده، فقط اینکه از سمت شما بوده.
• فاکتورها و موجودی: هر کسر و هر بازپرداخت.
• list_delegations: چه کسی به چه چیزی و تا کی دسترسی دارد.

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

تنظیمی که ما انتخاب می‌کردیم

برای ایجنتی که یک سرور عملیاتی را مدیریت می‌کند:

1. حساب جداگانه برای ایجنت، موجودی صفر، سرور با expires_days: 90 واگذار شده.
2. توکن مالک نزد خودتان می‌ماند و در هیچ کانفیگ ایجنتی نیست.
3. پشتیبان‌گیری روی آن سرور، چون واگذارشده می‌تواند نصب مجدد کند.
4. ابزارهای سطح ۳ در کلاینت روی «ask» یا «deny».
5. توکن ایجنت در فایلی با دسترسی 600، پیش از انقضا تمدید می‌شود.

برای ایجنتی که باید سرور سفارش دهد یا سندباکس اجرا کند، واگذاری کافی نیست، چون به موجودی نیاز دارد. آنجا موجودی سقف شماست: برای هر کار شارژ کنید، برای توکن نام بگذارید و هفته‌ای یک بار last_used_at را نگاه کنید. اگر توکن فقط‌خواندنی شیوهٔ کار شما با ایجنت‌ها را تغییر می‌داد، از طریق پشتیبانی به ما بگویید: دقیقاً همین بازخوردهاست که تعیین می‌کند قدم بعدی ما چه باشد.