MCP حفاظتی حدود: AI ایجنٹس کے لیے محفوظ اجازتیں

MCP ٹوکن دراصل آپ کے اکاؤنٹ کا پاس ورڈ ہے جس کے ساتھ ایک API جڑا ہوا ہے۔ اسے کسی ایجنٹ کو دیں تو آپ کے پاس ایسا یوزر ہوگا جو کبھی نہیں تھکتا، جس صفحے کی طرف اشارہ کریں اسے پڑھ لیتا ہے، اور اس کے کانٹیکسٹ کی آخری ہدایت جو کہے بالکل وہی کرتا ہے۔ زیادہ تر وقت یہی مطلوب ہوتا ہے۔ یہ صفحہ باقی وقت کے بارے میں ہے۔

نیچے کی ہر بات صفحے کے اوپر لکھی تاریخ پر لائیو سرور سے جانچی گئی ہے: ٹولز کی فہرست https://mcp.eqvps.com/mcp پر tools/list سے آئی ہے، اور حدود براہِ راست API سے۔ اگر آپ نئے ہیں تو پہلے MCP کلائنٹ جوڑنا اور API ٹوکنز پڑھیں، پھر واپس آئیں۔

خطرے کا ماڈل: حقیقت میں کیا غلط ہوتا ہے

تین چیزیں، اسی ترتیب میں جس میں ہم انہیں دیکھتے ہیں:

1. ایجنٹ غلط سمجھتا ہے۔ "ٹیسٹ مشین صاف کر دو" کسی اور سرور کے ری انسٹال میں بدل جاتا ہے۔ کوئی بری نیت نہیں، بس ماڈل نے ہدایت کا خالی حصہ خود بھر دیا۔
2. Prompt injection. ایجنٹ کوئی ایسی تحریر پڑھتا ہے جو آپ نے نہیں لکھی (README، سپورٹ کا جواب، اسکریپ کیا گیا صفحہ) اور وہ تحریر اسے کچھ کرنے کو کہتی ہے۔ اگر ایجنٹ کے پاس مکمل اختیارات والا ٹوکن ہے تو داخل کی گئی ہدایت کے پاس بھی وہی اختیارات ہیں۔
3. ٹوکن لیک ہو جاتا ہے۔ وہ shell ہسٹری، پبلک repo، شیئر کی گئی MCP کنفیگ یا کسی لاگ لائن میں پہنچ جاتا ہے۔

MCP سرور جانچتا ہے کہ ٹوکن درست ہے اور سرور اسی اکاؤنٹ کا ہے (یا اسے ڈیلیگیٹ کیا گیا ہے)۔ آپ کا اصل ارادہ کیا تھا، یہ اسے معلوم نہیں۔ نیچے کی ہر حفاظتی حد ایک ہی سوال کا جواب دیتی ہے: اگر ہدایت غلط ہو تو نقصان کتنا بڑا ہو سکتا ہے؟

تمام MCP ٹولز، خطرے کی سطح کے لحاظ سے

کسٹمر ٹوکن کو 45 ٹولز دکھتے ہیں (MCP سرور 1.6.0)۔ ری سیلر ٹوکن (rk_…) کو 30 ری سیلر ٹولز کا الگ سیٹ دکھتا ہے اور ان میں سے کوئی بھی نہیں، اس لیے endpoint پر کل 75 ٹولز ہیں۔ آپ کا کلائنٹ tools/list سے صرف اپنا سیٹ حاصل کرتا ہے۔

یہ پیج ٹولز کو خطرے کے لحاظ سے ترتیب دیتا ہے۔ ہر ٹول کے پیرامیٹرز اور کال کی مثالیں پیرامیٹر ریفرنس میں ہیں؛ 30 ری سیلر ٹولز سمیت تمام ٹولز ایک ایک سطر میں مکمل فہرست میں ہیں۔

ہم ابھی MCP ٹول اینوٹیشنز (readOnlyHint، destructiveHint) نہیں بھیجتے، اس لیے آپ کا کلائنٹ انہیں خود نہیں چھانٹ سکتا۔ نیچے دی گئی سطحوں کے مطابق منظوری ہاتھ سے سیٹ کریں۔

سطح 0 — عوامی، ٹوکن کی ضرورت نہیں (5)

سطح 1 — اکاؤنٹ پڑھنا، کوئی ضمنی اثر نہیں (15)

سطح 2 — حالت بدلتے ہیں، کچھ خرچ نہیں کرتے (17)

سطح 3 — پیسے خرچ کرتے ہیں، ڈیٹا مٹاتے ہیں یا رسائی دیتے ہیں (8)

ٹول سیٹ کا تبدیلی ریکارڈ

چلتا ہوا ورژن عوامی ہے: curl -s https://mcp.eqvps.com/healthz۔ جب یہ بدلے گا، یہ جدول بھی ساتھ بدلے گا۔

بیلنس ہی خرچ کی حد ہے

EQVPS پری پیڈ ہے۔ نہ کوئی محفوظ کارڈ، نہ کریڈٹ لائن، نہ منفی بیلنس: ایجنٹ زیادہ سے زیادہ اتنا ہی خرچ کر سکتا ہے جتنا بیلنس میں ہے۔ تین ٹولز پیسے خرچ کرتے ہیں: order_vps، change_plan اور create_sandbox۔ آپ کے موجودہ سرورز کی تجدید بھی اسی بیلنس سے کٹتی ہے۔

ایجنٹ پیسوں کی درخواست بنا سکتا ہے، لیکن ادائیگی نہیں کر سکتا۔ topup_balance اور pay_invoice کرپٹو ادائیگی کا لنک لوٹاتے ہیں، اور پیچھے والیٹ نہ ہو تو لنک کچھ نہیں کرتا۔ رقم نکالنے کا کوئی endpoint بھی نہیں: بیلنس کی رقم آپ کے اکاؤنٹ میں سروسز خرید سکتی ہے، باہر نہیں جا سکتی۔ فوری منسوخی پر ملنے والا ریفنڈ بھی بیلنس میں ہی واپس آتا ہے۔

ایک انتباہ، اور یہ سنجیدہ ہے۔ ایجنٹ کو روکنے کے لیے اگر آپ بیلنس بہت کم رکھیں گے تو آپ کے اپنے سرورز کی تجدید ناکام ہونے لگے گی اور سرورز گریس پیریڈ میں چلے جائیں گے۔ ہمارا اصول: جو پہلے سے چل رہا ہے اس کی ایک تجدید کی رقم، اور ساتھ ایجنٹ کے موجودہ کام کا بجٹ۔ ایجنٹ بجٹ گائیڈ میں حساب سمجھایا گیا ہے۔ اور اگر آپ ایجنٹ کو پیسوں والا اس کا اپنا والیٹ دیتے ہیں تو وہ والیٹ دوسری حد بن جاتا ہے جس پر بھی نظر رکھنی ہوگی۔

کم سے کم اختیار: صرف پڑھنے والا ٹوکن (ابھی) نہیں ہے

سیدھی بات: ہر کسٹمر ٹوکن کے پاس وہی اختیارات ہیں جو ڈیش بورڈ میں اکاؤنٹ کے پاس ہیں۔ ٹوکن کا نام اور مدت سیٹ کی جا سکتی ہے، اسکوپ نہیں۔

آج سب سے محدود راستہ ڈیلیگیشن ہے۔ آپ ایجنٹ کو صفر بیلنس والا اس کا اپنا اکاؤنٹ دیتے ہیں اور اسے ایک سرور ڈیلیگیٹ کرتے ہیں:

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 1 سے 365 تک ہو سکتا ہے۔ اسکرین شاٹس کے ساتھ مرحلہ وار: رسائی ڈیلیگیٹ کرنا اور دستاویزات میں رسائی۔

دائیں طرف کے کالم کی آخری دو سطروں پر غور کریں۔ ڈیلیگیٹ آپ کے پیسے خرچ نہیں کر سکتا، لیکن اس سرور کو مٹا سکتا ہے۔ جس بھی سرور کو ایجنٹ ری انسٹال کر سکتا ہے، اس پر بیک اپ آن کریں۔

ٹوکن کی حفاظت

ہر ایجنٹ کا ایک ٹوکن، نام کے ساتھ۔ اسے ڈیش بورڈ ← ترتیبات ← ایجنٹس کے لیے 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}'

ٹوکن صرف ایک بار دکھایا جاتا ہے۔ مدت 1 سے 1825 دن، کچھ نہ بتائیں تو 365۔ ایجنٹس کے لیے ہم 90 چنتے۔

اسے ایسی فائل میں رکھیں جسے صرف آپ پڑھ سکیں، repo میں نہیں، پرامپٹ میں نہیں، اور ایسے 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 پاس ورڈ بدلیں ہر اس سرور پر جسے وہ ٹوکن دیکھ سکتا تھا۔ reveal: true کے ساتھ get_vps_status root پاس ورڈ دے دیتا ہے، اس لیے لیک ہوا ٹوکن یعنی لیک ہوا root پاس ورڈ۔ ساتھ ہی ~/.ssh/authorized_keys بھی دیکھ لیں۔
5. پاس ورڈ والا دروازہ بند کریں۔ اگر آپ کے اکاؤنٹ پر کبھی پاس ورڈ نہیں تھا تو ٹوکن رکھنے والے نے set_password سے ایک سیٹ کیا ہو سکتا ہے۔ ای میل کوڈ سے لاگ اِن کریں اور پاس ورڈ بدلیں۔

پانچویں قدم کی روک تھام مفت ہے: ابھی خود اکاؤنٹ کا پاس ورڈ سیٹ کر دیں، اور set_password آپ کے بعد آنے والے ہر شخص کو 409 لوٹائے گا۔

انسانی منظوری

سرور کیا نافذ کرتا ہے:

• reinstall_vps، reset_password اور type: immediate والا cancel_service، confirm میں بالکل درست hostname مانگتے ہیں (ری انسٹال اور ری سیٹ کے لیے DELETE بھی چلتا ہے)۔
• change_plan کے لیے confirm: true درکار ہے۔
• ڈیفالٹ منسوخی end_of_period ہے: سرور ادا شدہ مدت کے آخر تک چلتا ہے، اور undo_cancel اسے واپس لیتا ہے۔
• ہر اکاؤنٹ کی شرح کی حدود: ری انسٹال 4/منٹ، پاس ورڈ ری سیٹ 6/منٹ، پاور 20/منٹ، آرڈر 20/منٹ۔ اتنا کہ لوپ میں پھنسا ایجنٹ ایک ہی کام پچاس بار نہ کرے، لیکن ایک غلط کال روکنے کے لیے کافی نہیں۔

واضح سمجھ لیں کہ confirm کیا ہے۔ یہ ایجنٹ کو "وہاں صاف کر دو" جیسی بات پر عمل کرنے سے روکتا ہے۔ یہ حملہ آور کو نہیں روکتا، کیونکہ hostname صرف ایک get_vps_status کال دور ہے۔ اصل منظوری آپ کے MCP کلائنٹ میں ہوتی ہے۔ زیادہ تر کلائنٹ ہر ٹول کال سے پہلے پوچھ سکتے ہیں: سطح 0 اور 1 کو کھلا چھوڑیں، سطح 3 کو ہمیشہ پوچھنے دیں۔ جن کلائنٹس میں ہر ٹول کی الگ اجازت ہوتی ہے، جیسے Claude Code کی settings.json (سرور 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. کلائنٹ میں سطح 3 کے ٹولز "ask" یا "deny" پر۔
5. ایجنٹ کا ٹوکن 600 اجازت والی فائل میں، میعاد سے پہلے ریفریش۔

جس ایجنٹ کو سرور آرڈر کرنے ہوں یا سینڈ باکس چلانے ہوں، اس کے لیے ڈیلیگیشن کافی نہیں، کیونکہ اسے بیلنس چاہیے۔ تب بیلنس ہی آپ کی حد ہے: ہر کام کے حساب سے ٹاپ اپ کریں، ٹوکن کو نام دیں، اور ہفتے میں ایک بار last_used_at دیکھیں۔ اگر صرف پڑھنے والا ٹوکن آپ کے ایجنٹ چلانے کا طریقہ بدل دے گا تو ہمیں سپورٹ پر بتائیں: آگے ہم کیا بنائیں گے، یہ بالکل ایسی ہی آراء طے کرتی ہیں۔