รั้วกั้นความปลอดภัย MCP: สิทธิ์ที่ปลอดภัยสำหรับเอเจนต์ AI

โทเค็น MCP ก็คือรหัสผ่านบัญชีที่มี API ติดมาด้วย ส่งให้เอเจนต์เมื่อไร คุณก็จะได้ผู้ใช้ที่ไม่เคยเหนื่อย อ่านทุกหน้าที่คุณชี้ไป และทำตามคำสั่งสุดท้ายในบริบทของมันแบบเป๊ะ ๆ ส่วนใหญ่นั่นคือสิ่งที่คุณต้องการ หน้านี้พูดถึงช่วงเวลาที่เหลือ

ทุกอย่างด้านล่างตรวจสอบกับเซิร์ฟเวอร์จริงตามวันที่ด้านบนของหน้า รายการเครื่องมือมาจาก tools/list ที่ https://mcp.eqvps.com/mcp และข้อจำกัดมาจาก API โดยตรง ถ้าเพิ่งเริ่ม ให้อ่าน การเชื่อมต่อไคลเอนต์ MCP และ โทเค็น API ก่อน แล้วค่อยกลับมา

โมเดลภัยคุกคาม: อะไรผิดพลาดได้จริง

มีสามเรื่อง เรียงตามที่เราเจอบ่อย:

1. เอเจนต์เข้าใจผิด "เคลียร์เครื่องทดสอบหน่อย" กลายเป็นการติดตั้งใหม่ผิดเครื่อง ไม่มีเจตนาร้าย แค่โมเดลเติมช่องว่างในคำสั่งเอาเอง
2. Prompt injection เอเจนต์อ่านข้อความที่คุณไม่ได้เขียน (README คำตอบจากซัพพอร์ต หรือหน้าเว็บที่ดึงมา) แล้วข้อความนั้นสั่งให้มันทำบางอย่าง ถ้าเอเจนต์ถือโทเค็นสิทธิ์เต็ม คำสั่งที่ถูกแทรกเข้ามาก็ได้สิทธิ์เต็มไปด้วย
3. โทเค็นรั่ว ไปโผล่ในประวัติ shell รีโพสาธารณะ ไฟล์ตั้งค่า MCP ที่แชร์กัน หรือบรรทัดหนึ่งในล็อก

เซิร์ฟเวอร์ MCP ตรวจว่าโทเค็นใช้ได้ และเซิร์ฟเวอร์เป็นของบัญชีนั้น (หรือได้รับมอบสิทธิ์) เท่านั้น มันไม่รู้ว่าคุณตั้งใจอะไร รั้วกั้นทุกข้อด้านล่างตอบคำถามเดียว: ถ้าคำสั่งผิด ความเสียหายไปได้ไกลแค่ไหน

เครื่องมือ MCP ทั้งหมด แยกตามระดับความเสี่ยง

โทเค็นลูกค้าเห็น 45 เครื่องมือ (เซิร์ฟเวอร์ MCP 1.6.0) โทเค็นตัวแทนจำหน่าย (rk_…) เห็นชุดแยกของเครื่องมือตัวแทนจำหน่าย 30 ตัวและไม่เห็นตัวใดในนี้เลย ดังนั้น endpoint มีทั้งหมด 75 ตัว ไคลเอนต์ของคุณได้รับจาก tools/list เฉพาะชุดของตัวเอง

หน้านี้จัดเครื่องมือตามระดับความเสี่ยง พารามิเตอร์และตัวอย่างการเรียกของแต่ละเครื่องมืออยู่ในคู่มืออ้างอิงพารามิเตอร์ ส่วนเครื่องมือทั้งหมดแบบบรรทัดเดียว รวม 30 เครื่องมือตัวแทนจำหน่าย อยู่ในรายการทั้งหมด

เรายังไม่ได้ส่ง annotation ของเครื่องมือ 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 ถอนเงินด้วย เงินในยอดเงินใช้ซื้อบริการในบัญชีคุณได้ แต่โอนออกไม่ได้ เงินคืนจากการยกเลิกทันทีก็กลับเข้ายอดเงินเช่นกัน

มีข้อควรระวังหนึ่งข้อ และเป็นเรื่องจริงจัง ถ้าคุณปล่อยยอดเงินไว้ต่ำมากเพื่อจำกัดเอเจนต์ การต่ออายุเซิร์ฟเวอร์ของคุณเองจะเริ่มล้มเหลว และเซิร์ฟเวอร์จะเข้าสู่ช่วงผ่อนผัน หลักของเราคือ: เงินสำหรับต่ออายุสิ่งที่ใช้อยู่หนึ่งรอบ บวกงบของงานที่เอเจนต์กำลังทำ คู่มืองบประมาณเอเจนต์ อธิบายวิธีคิดไว้ และถ้าคุณให้เอเจนต์มีกระเป๋าเงินของตัวเองที่มีเงินอยู่ กระเป๋านั้นจะกลายเป็นเพดานที่สองที่คุณต้องคอยดูด้วย

สิทธิ์น้อยที่สุด: (ยัง) ไม่มีโทเค็นแบบอ่านอย่างเดียว

พูดตรง ๆ: โทเค็นลูกค้าทุกตัวมีสิทธิ์เท่ากับบัญชีในแดชบอร์ด ชื่อและอายุของโทเค็นตั้งค่าได้ แต่ขอบเขตสิทธิ์ (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 ตั้งได้ 1 ถึง 365 วิธีทำทีละขั้นพร้อมภาพหน้าจอ: การมอบสิทธิ์เข้าถึง และ หัวข้อการเข้าถึงในเอกสาร

สังเกตสองแถวสุดท้ายฝั่งซ้าย ผู้ได้รับมอบสิทธิ์ใช้เงินของคุณไม่ได้ แต่ลบเซิร์ฟเวอร์นั้นได้ เปิดการสำรองข้อมูลบนทุกเซิร์ฟเวอร์ที่เอเจนต์ติดตั้งใหม่ได้

การดูแลโทเค็น

หนึ่งเอเจนต์หนึ่งโทเค็น และตั้งชื่อให้ด้วย สร้างได้ที่ แดชบอร์ด → การตั้งค่า → โทเค็น API สำหรับ agent หรือแบบนี้:

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

เก็บไว้ในไฟล์ที่มีแค่คุณอ่านได้ ไม่ใช่ในรีโพ ไม่ใช่ในพรอมต์ และไม่ใช่ในตัวแปร 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 สำหรับ agent → เพิกถอน หรือ 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 ให้ล็อกอินด้วยรหัสทางอีเมลแล้วเปลี่ยนรหัสผ่าน

การป้องกันข้อ 5 ไม่มีค่าใช้จ่าย: ตั้งรหัสผ่านบัญชีเองตอนนี้เลย แล้ว set_password จะคืน 409 ให้ทุกคนที่มาทีหลัง

การอนุมัติโดยมนุษย์

สิ่งที่เซิร์ฟเวอร์บังคับใช้:

• reinstall_vps, reset_password และ cancel_service ที่ใช้ type: immediate ต้องมี confirm เท่ากับชื่อโฮสต์ที่ตรงเป๊ะ (การติดตั้งใหม่และรีเซ็ตใช้ DELETE ได้ด้วย)
• change_plan ต้องมี confirm: true
• การยกเลิกเริ่มต้นคือ end_of_period เซิร์ฟเวอร์ทำงานจนสิ้นรอบที่จ่ายแล้ว และ undo_cancel ย้อนกลับได้
• จำกัดอัตราต่อบัญชี: ติดตั้งใหม่ 4 ครั้ง/นาที รีเซ็ตรหัสผ่าน 6 ครั้ง/นาที คำสั่งพลังงาน 20 ครั้ง/นาที สั่งซื้อ 20 ครั้ง/นาที พอที่จะกันลูปไม่ให้ทำซ้ำห้าสิบครั้ง แต่ไม่พอจะหยุดการเรียกที่ผิดครั้งเดียว

เข้าใจให้ชัดว่า confirm คืออะไร มันกันไม่ให้เอเจนต์ลงมือเพราะคำว่า "เคลียร์ตรงนั้นหน่อย" มันหยุดผู้โจมตีไม่ได้ เพราะชื่อโฮสต์ได้มาด้วยการเรียก get_vps_status แค่ครั้งเดียว การอนุมัติจริงอยู่ในไคลเอนต์ MCP ของคุณ ไคลเอนต์ส่วนใหญ่ถามก่อนเรียกเครื่องมือทุกครั้งได้ ปล่อยระดับ 0 และ 1 ให้ทำงานเอง และให้ระดับ 3 ถามทุกครั้ง ในไคลเอนต์ที่ตั้งสิทธิ์รายเครื่องมือได้ เช่น 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 สำหรับ agent): ชื่อ วันที่สร้าง วันหมดอายุ last_used_at นี่คือเหตุผลที่ควรตั้งชื่อโทเค็นตามเอเจนต์
• ประวัติบริการ (แดชบอร์ด หน้าเซิร์ฟเวอร์): คำสั่งพลังงาน การติดตั้งใหม่ การรีเซ็ตรหัสผ่าน การเปลี่ยนแพ็กเกจ การชำระเงิน แต่ละรายการมีเวลาและผู้กระทำ: คุณ ฝ่ายสนับสนุน หรืออัตโนมัติ มันไม่ได้บอกว่าโทเค็นหรือผู้รับมอบสิทธิ์ ตัวไหน เป็นผู้ทำ บอกแค่ว่ามาจากฝั่งคุณ
• ใบแจ้งหนี้และยอดเงิน: ทุกการหักเงินและเงินคืน
• list_delegations: ใครเข้าถึงอะไรได้ และถึงเมื่อไร

ช่องว่างในประวัติบริการนี้คือขีดจำกัดตามจริงของการตรวจสอบฝั่งเซิร์ฟเวอร์ในตอนนี้ ถ้าคุณต้องรู้ว่าเอเจนต์ตัวไหนทำอะไร ให้บันทึกทุกการเรียกเครื่องมือพร้อมอาร์กิวเมนต์ (ตัดความลับออก) ที่ฝั่งเอเจนต์

การตั้งค่าที่เราจะเลือก

สำหรับเอเจนต์ที่ดูแลเซิร์ฟเวอร์ใช้งานจริงหนึ่งเครื่อง:

1. บัญชีแยกสำหรับเอเจนต์ ยอดเงินเป็นศูนย์ มอบสิทธิ์เซิร์ฟเวอร์ด้วย expires_days: 90
2. โทเค็นเจ้าของอยู่กับคุณ ไม่อยู่ในไฟล์ตั้งค่าของเอเจนต์ใด ๆ
3. เปิดการสำรองข้อมูลบนเซิร์ฟเวอร์นั้น เพราะผู้รับมอบสิทธิ์ติดตั้งใหม่ได้
4. ตั้งเครื่องมือระดับ 3 เป็น "ask" หรือ "deny" ในไคลเอนต์
5. โทเค็นของเอเจนต์อยู่ในไฟล์สิทธิ์ 600 และต่ออายุก่อนหมดอายุ

สำหรับเอเจนต์ที่ต้องสั่งซื้อเซิร์ฟเวอร์หรือรันแซนด์บ็อกซ์ การมอบสิทธิ์ไม่พอ เพราะมันต้องมียอดเงิน ตอนนั้นยอดเงินคือเพดานของคุณ: เติมตามงาน ตั้งชื่อโทเค็น และดู last_used_at สัปดาห์ละครั้ง ถ้าโทเค็นแบบอ่านอย่างเดียวจะเปลี่ยนวิธีที่คุณใช้งานเอเจนต์ บอกเราได้ที่ ฝ่ายสนับสนุน ความเห็นแบบนี้แหละที่ตัดสินว่าเราจะสร้างอะไรต่อ