MCP ガードレール：AI エージェントに安全な権限を

MCP トークンは、API がくっついたアカウントのパスワードです。エージェントに渡せば、疲れ知らずで、指示したページは何でも読み、コンテキストの最後の指示どおりに正確に動くユーザーが 1 人増えます。たいていはそれで十分です。このページは、そうでないときの話です。

以下の内容はすべて、ページ上部の日付に本番サーバーで確認しました。ツール一覧は https://mcp.eqvps.com/mcp の tools/list から、制限は API そのものから取っています。初めての方は、先に MCP クライアントの接続 と API トークン を読んでから戻ってきてください。

脅威モデル：実際に何がまずいのか

私たちがよく見る順に 3 つあります。

1. エージェントが誤解する。 「テスト機を片付けて」が、別のサーバーの再インストールになる。悪意はなく、モデルが指示の抜けを勝手に補っただけです。
2. プロンプトインジェクション。 エージェントがあなたの書いていない文章（README、サポートの返信、スクレイピングしたページ）を読み、その文章が何かをしろと指示する。エージェントがフル権限のトークンを持っていれば、注入された指示も同じ権限を持ちます。
3. トークンが漏れる。 シェル履歴、公開リポジトリ、共有の MCP 設定、ログの 1 行に紛れ込みます。

MCP サーバーが確認するのは、トークンが有効か、そしてサーバーがそのアカウントのもの（または委任されたもの）かだけです。あなたの本当の意図はわかりません。以下のガードレールはすべて、ひとつの問いに答えるためのものです。指示が間違っていたら、被害は最大でどこまで広がるか。

MCP ツール全一覧（リスク段階別）

顧客トークンには 45 個のツール が見えます（MCP サーバー 1.6.0）。リセラートークン（rk_…）には別枠のリセラー用ツール 30 個が見え、ここにあるツールは一つも見えません。つまりエンドポイント全体では 75 個です。クライアントが tools/list で受け取るのは自分の分だけです。

このページはツールをリスク別に分類しています。各ツールのパラメータと呼び出し例はパラメータリファレンスに、30 のリセラーツールを含む全ツールの 1 行説明は完全なリストにあります。

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 の 3 つ。既存サーバーの更新料も同じ残高から引かれます。

エージェントは支払いの依頼を作れますが、支払うことはできません。topup_balance と pay_invoice が返すのは暗号資産の支払いリンクで、背後にウォレットがなければリンクは何もしません。出金用のエンドポイントもありません。残高のお金はあなたのアカウント内でサービスを買うことにしか使えず、外へは出せません。即時解約の返金も残高に戻ります。

ひとつ注意点があります。しかも重要です。エージェントを抑えるために残高を極端に少なくすると、あなた自身のサーバーの更新が失敗し始め、猶予期間に入ってしまいます。私たちの目安は、すでに動いているものの更新 1 回分に、エージェントの現在の作業予算を足した額です。計算方法は エージェント予算ガイド で解説しています。また、エージェントに資金入りの専用ウォレットを持たせるなら、そのウォレットが 2 つ目の上限になり、そちらも監視が必要です。

最小権限：読み取り専用トークンは（まだ）ない

率直に言うと、顧客トークンはどれもダッシュボード上のアカウントと同じ権限を持ちます。トークンの名前と有効期間は設定できますが、スコープは設定できません。

現時点でいちばん絞り込めるのは 委任 です。残高ゼロの専用アカウントをエージェントに用意し、サーバーを 1 台委任します。

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 です。スクリーンショット付きの手順は アクセスの委任 と ドキュメントのアクセス項目 を参照してください。

左列の最後の 2 行に注目してください。委任先はあなたのお金を使えませんが、そのサーバーを消すことはできます。エージェントが再インストールできるサーバーでは、必ずバックアップを有効にしてください。

トークンの管理

エージェントごとに 1 つ、名前付きで。 ダッシュボード → 設定 → エージェント向け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 回だけです。有効期間は 1〜1825 日、指定しなければ 365 日。エージェント用なら私たちは 90 日にします。

自分だけが読めるファイルに保存してください。 リポジトリにも、プロンプトにも、あちこちコピーするシェル変数にも置かないこと。

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 で設定したかもしれません。メールのコードでログインして、パスワードを変更してください。

手順 5 の予防はタダです。今のうちに自分でアカウントのパスワードを設定しておけば、以後 set_password は誰に対しても 409 を返します。

人による承認

サーバーが強制していること：

• reinstall_vps、reset_password、type: immediate の cancel_service は、confirm に正確なホスト名が必要（再インストールとリセットは DELETE も可）。
• change_plan には confirm: true が必要。
• 解約のデフォルトは end_of_period。サーバーは支払い済み期間の終わりまで動き、undo_cancel で元に戻せます。
• アカウントごとのレート制限：再インストール毎分 4 回、パスワードリセット毎分 6 回、電源操作毎分 20 回、注文毎分 20 回。ループに陥ったエージェントが同じことを 50 回やるのは防げますが、1 回の誤った呼び出しは止められません。

confirm の正体ははっきりさせておきましょう。エージェントが「そこを片付けて」で動いてしまうのを防ぐものです。攻撃者は止められません。ホスト名は get_vps_status を 1 回呼べば手に入るからです。本当の承認は 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"]
  }
}

エージェントへの指示にも 1 行加えておきましょう。それだけではセキュリティ対策になりませんが、「誤解」のケースは減ります（英語のままで構いません。モデルは同じように理解します）。

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 台を管理するエージェントなら：

1. エージェント専用のアカウント、残高ゼロ、サーバーは expires_days: 90 で委任。
2. 所有者トークンは手元に置き、どのエージェントの設定にも入れない。
3. そのサーバーではバックアップを有効に。委任先は再インストールできるため。
4. クライアントでは段階 3 のツールを "ask" か "deny" に。
5. エージェントのトークンは権限 600 のファイルに置き、期限前に更新する。

サーバーを注文したりサンドボックスを動かしたりする必要があるエージェントには、委任では足りません。残高が必要だからです。その場合は残高が上限になります。作業ごとにチャージし、トークンに名前を付け、週に一度 last_used_at を確認してください。読み取り専用トークンがあればエージェントの使い方が変わるという方は、サポート で教えてください。次に何を作るかは、まさにそうした声で決まります。