Pengaman MCP: izin yang aman untuk agen AI

Token MCP adalah password akun Anda yang ditempeli API. Berikan ke agen dan Anda punya pengguna yang tidak pernah lelah, membaca setiap halaman yang Anda tunjukkan, dan melakukan persis apa yang dikatakan instruksi terakhir di konteksnya. Sering kali memang itu yang Anda mau. Halaman ini membahas sisanya.

Semua yang ada di bawah sudah dicek ke server produksi pada tanggal di bagian atas: daftar tool diambil dari tools/list di https://mcp.eqvps.com/mcp, batasnya dari API itu sendiri. Kalau Anda baru mulai, baca dulu menghubungkan klien MCP dan token API, lalu kembali ke sini.

Model ancaman: apa yang benar-benar bisa salah

Tiga hal, sesuai urutan yang kami lihat:

1. Agen salah paham. "Bersihkan mesin uji" berubah jadi instal ulang server yang salah. Tidak ada niat jahat, hanya model yang mengisi celah dalam instruksi.
2. Prompt injection. Agen membaca teks yang bukan Anda tulis (README, balasan support, halaman web) dan teks itu menyuruhnya melakukan sesuatu. Jika agen memegang token dengan hak penuh, instruksi sisipan itu juga punya hak yang sama.
3. Token bocor. Token berakhir di riwayat shell, repo publik, konfigurasi MCP bersama, atau satu baris log.

Server MCP memeriksa bahwa token valid dan server itu milik akun tersebut (atau didelegasikan kepadanya). Server tidak tahu apa maksud Anda. Setiap pengaman di bawah menjawab satu pertanyaan: seberapa besar kerusakan yang mungkin terjadi jika instruksinya salah?

Semua tool MCP per tingkat risiko

Token pelanggan melihat 45 tool (server MCP 1.6.0). Token reseller (rk_…) melihat set terpisah berisi 30 tool reseller dan tidak satu pun dari tool ini, jadi endpoint-nya punya total 75. Klien Anda hanya menerima set miliknya sendiri dari tools/list.

Halaman ini mengurutkan tool berdasarkan risiko. Parameter dan contoh panggilan setiap tool ada di referensi parameter; semua tool dalam satu baris, termasuk 30 tool reseller, ada di daftar lengkap.

Kami belum mengirim anotasi tool MCP (readOnlyHint, destructiveHint), jadi klien Anda tidak bisa mengelompokkannya sendiri. Atur persetujuan secara manual berdasarkan tingkat di bawah ini.

Tingkat 0 — publik, tanpa token (5)

Tingkat 1 — membaca akun, tanpa efek samping (15)

Tingkat 2 — mengubah keadaan, tidak membelanjakan apa pun (17)

Tingkat 3 — membelanjakan uang, menghapus data, atau memberi akses (8)

Catatan perubahan set tool

Versi yang berjalan bersifat publik: curl -s https://mcp.eqvps.com/healthz. Saat versinya berubah, tabel ini ikut berubah.

Saldo adalah batas belanja

EQVPS bersifat prabayar. Tidak ada kartu tersimpan, tidak ada batas kredit, tidak bisa minus: jumlah maksimal yang bisa dibelanjakan agen adalah isi saldo. Tiga tool membelanjakan uang: order_vps, change_plan, dan create_sandbox. Perpanjangan server Anda yang sudah ada juga dipotong dari saldo yang sama.

Agen bisa membuat permintaan uang, tetapi tidak bisa membayarnya. topup_balance dan pay_invoice mengembalikan tautan pembayaran kripto, dan tautan tidak melakukan apa pun tanpa dompet di belakangnya. Tidak ada juga endpoint penarikan: uang di saldo bisa membeli layanan di akun Anda, tidak bisa dikeluarkan. Pengembalian dana dari pembatalan seketika juga kembali ke saldo.

Satu catatan, dan ini serius. Jika saldo Anda biarkan sangat rendah untuk mengerem agen, perpanjangan server Anda sendiri mulai gagal dan server masuk masa tenggang. Patokan kami: satu siklus perpanjangan untuk yang sudah berjalan, ditambah anggaran tugas agen yang sedang berlangsung. Panduan anggaran agen menjelaskan hitungannya. Dan jika agen Anda beri dompet sendiri berisi dana, dompet itu jadi batas kedua yang juga harus Anda awasi.

Hak akses minimum: token baca-saja (belum) ada

Jawaban langsungnya: setiap token pelanggan punya hak yang sama dengan akun di dasbor. Nama dan masa berlaku token bisa diatur, scope-nya tidak.

Yang paling sempit saat ini adalah delegasi. Anda membuatkan agen akun sendiri dengan saldo nol dan mendelegasikan satu server kepadanya:

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

Hal yang sama lewat 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}'

Undangan harus diterima sambil masuk dengan email tersebut (accept_delegation), dan expires_days bisa 1 sampai 365. Langkah demi langkah dengan tangkapan layar: mendelegasikan akses dan akses di dokumentasi.

Perhatikan dua baris terakhir di kiri. Penerima delegasi tidak bisa membelanjakan uang Anda, tetapi bisa menghapus server itu. Aktifkan backup di setiap server yang bisa diinstal ulang oleh agen.

Kebersihan token

Satu token per agen, dengan nama. Buat di Dasbor → Pengaturan → Token API untuk agen, atau seperti ini:

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}'

Token hanya ditampilkan sekali. Masa berlaku 1 sampai 1825 hari, 365 jika tidak diisi. Untuk agen, kami akan memilih 90.

Simpan di file yang hanya bisa dibaca oleh Anda, bukan di repo, bukan di prompt, bukan di variabel shell yang Anda salin ke mana-mana:

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   # seharusnya: -rw-------

Lalu muat di layanan agen dengan EnvironmentFile= (systemd) atau set -a; . ~/.config/eqvps/agent.env; set +a.

Rotasi sebelum kedaluwarsa. Tool refresh_token, atau POST /auth/tokens/{id}/refresh, menerbitkan token baru dengan nama yang sama dan langsung mencabut yang lama. Jika token tertulis langsung di konfigurasi klien MCP, segera perbarui setelahnya, atau sesi berikutnya akan mendapat 401.

Periksa siapa memakai apa: GET /auth/tokens menampilkan setiap token dengan nama, masa berlaku, dan last_used_at. Token yang tidak Anda kenal, atau token yang dipakai setelah agen Anda matikan, adalah tanda bahaya.

Jika token bocor

Dengan urutan ini:

1. Cabut. Dasbor → Pengaturan → Token API untuk agen → Cabut, atau curl -s -X DELETE -H "Authorization: Bearer $EQVPS_TOKEN" https://api.eqvps.com/api/v1/eqvps/auth/tokens/<id>. Token berhenti berlaku di permintaan berikutnya.
2. Cari token baru yang tidak Anda buat, lalu cabut juga.
3. Periksa apa saja yang mungkin tersentuh: riwayat layanan setiap server, invoice dan saldo, serta list_delegations untuk akses yang tidak Anda berikan.
4. Ganti password root di setiap server yang bisa dilihat token itu. get_vps_status dengan reveal: true memberikan password root, jadi token yang bocor berarti password root yang bocor. Sekalian periksa ~/.ssh/authorized_keys.
5. Tutup pintu password. Jika akun Anda tidak pernah punya password, pemegang token bisa saja sudah mengaturnya lewat set_password. Masuk dengan kode lewat email dan ganti password-nya.

Mencegah langkah 5 tidak memakan biaya: atur sendiri password akun sekarang, maka set_password akan mengembalikan 409 bagi siapa pun sesudah Anda.

Persetujuan manusia

Yang diterapkan server:

• reinstall_vps, reset_password, dan cancel_service dengan type: immediate mewajibkan confirm sama dengan hostname persis (DELETE juga berlaku untuk instal ulang dan reset).
• change_plan mewajibkan confirm: true.
• Pembatalan bawaan adalah end_of_period: server berjalan sampai akhir periode yang sudah dibayar, dan undo_cancel membatalkannya.
• Batas laju per akun: instal ulang 4/menit, reset password 6/menit, daya 20/menit, pesanan 20/menit. Cukup untuk mencegah loop melakukannya lima puluh kali, tidak cukup untuk menghentikan satu panggilan yang salah.

Pahami dengan jelas apa itu confirm. Ia mencegah agen bertindak atas perintah "bersihkan itu". Ia tidak menghentikan penyerang, karena hostname hanya sejauh satu panggilan get_vps_status. Persetujuan yang sebenarnya ada di klien MCP Anda. Sebagian besar klien bisa bertanya sebelum setiap panggilan tool: biarkan tingkat 0 dan 1 berjalan bebas, buat tingkat 3 selalu bertanya. Di klien yang punya izin per tool, seperti settings.json milik Claude Code (server terdaftar sebagai 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"]
  }
}

Tambahkan juga satu baris ke instruksi agen. Sendirian itu bukan kontrol keamanan, tetapi mengurangi salah paham (biarkan dalam bahasa Inggris, model memahaminya sama baiknya):

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.

Jika agen masuk dengan kode email alih-alih memegang token berumur panjang, lihat login agen lewat MCP.

Audit: apa yang bisa Anda lihat sesudahnya

• Daftar token (GET /auth/tokens, atau Pengaturan → Token API untuk agen): nama, dibuat, kedaluwarsa, last_used_at. Inilah alasan memberi nama token per agen.
• Riwayat layanan (dasbor, halaman server): aksi daya, instal ulang, reset password, ganti paket, pembayaran, masing-masing dengan waktu dan pelaku: Anda, support, atau otomatis. Riwayat ini tidak memberi tahu token atau penerima delegasi mana yang bertindak, hanya bahwa aksinya datang dari sisi Anda.
• Invoice dan saldo: setiap potongan dan pengembalian dana.
• list_delegations: siapa punya akses ke apa, dan sampai kapan.

Celah di riwayat layanan itu adalah batas jujur audit di sisi server saat ini. Jika Anda perlu tahu agen mana melakukan apa, catat setiap panggilan tool beserta argumennya (tanpa rahasia) di sisi agen.

Setelan yang akan kami pakai

Untuk agen yang mengurus satu server produksi:

1. Akun terpisah untuk agen, saldo nol, server didelegasikan dengan expires_days: 90.
2. Token pemilik tetap di tangan Anda, tidak ada di konfigurasi agen mana pun.
3. Backup di server itu, karena penerima delegasi bisa menginstal ulang.
4. Tool tingkat 3 diatur ke "ask" atau "deny" di klien.
5. Token agen di file 600, diperbarui sebelum kedaluwarsa.

Untuk agen yang harus memesan server atau menjalankan sandbox, delegasi tidak cukup karena ia butuh saldo. Di situ saldo adalah batas Anda: isi per tugas, beri nama token, dan cek last_used_at seminggu sekali. Jika token baca-saja akan mengubah cara Anda menjalankan agen, sampaikan ke kami lewat support: masukan seperti itulah yang menentukan apa yang kami bangun berikutnya.