Hàng rào an toàn MCP: quyền hạn an toàn cho AI agent

Token MCP là mật khẩu tài khoản của bạn được gắn thêm API. Đưa nó cho một agent và bạn có một người dùng không bao giờ mệt, đọc mọi trang bạn trỏ tới và làm đúng y những gì chỉ dẫn cuối cùng trong ngữ cảnh của nó nói. Phần lớn thời gian, đó là điều bạn muốn. Trang này nói về phần thời gian còn lại.

Mọi thứ dưới đây đã được kiểm tra trên máy chủ đang chạy vào ngày ghi ở đầu trang: danh sách công cụ lấy từ tools/list tại https://mcp.eqvps.com/mcp, các giới hạn lấy từ chính API. Nếu bạn mới bắt đầu, hãy đọc kết nối MCP client và API token trước, rồi quay lại.

Mô hình mối đe dọa: điều gì thực sự hay hỏng

Ba thứ, theo thứ tự chúng tôi hay gặp:

1. Agent hiểu sai. "Dọn máy test đi" biến thành cài lại nhầm máy chủ. Không có ác ý, chỉ là mô hình tự lấp chỗ trống trong chỉ dẫn.
2. Prompt injection. Agent đọc một đoạn văn bản không phải do bạn viết (README, câu trả lời từ support, một trang web) và đoạn đó bảo nó làm gì đó. Nếu agent giữ token toàn quyền, thì chỉ dẫn bị chèn vào cũng có toàn quyền.
3. Token bị lộ. Nó nằm trong lịch sử shell, một repo công khai, một cấu hình MCP dùng chung hoặc một dòng log.

Máy chủ MCP kiểm tra token có hợp lệ không và máy chủ có thuộc tài khoản đó (hoặc được ủy quyền cho nó) không. Nó không biết bạn thực sự muốn gì. Mỗi hàng rào bên dưới trả lời đúng một câu hỏi: nếu chỉ dẫn sai thì thiệt hại tối đa là bao nhiêu?

Toàn bộ công cụ MCP theo mức rủi ro

Token khách hàng thấy 45 công cụ (máy chủ MCP 1.6.0). Token đại lý (rk_…) thấy một bộ riêng gồm 30 công cụ đại lý và không thấy công cụ nào trong số này, nên endpoint có tổng cộng 75. Client của bạn chỉ nhận bộ của chính nó từ tools/list.

Trang này sắp xếp công cụ theo mức rủi ro. Tham số và ví dụ gọi của từng công cụ có trong tài liệu tham chiếu tham số; mọi công cụ trên một dòng, gồm 30 công cụ đại lý, có trong danh sách đầy đủ.

Chúng tôi chưa gửi kèm chú thích công cụ MCP (readOnlyHint, destructiveHint), nên client không tự phân loại được. Hãy tự cấu hình việc phê duyệt dựa trên các mức dưới đây.

Mức 0 — công khai, không cần token (5)

Mức 1 — đọc tài khoản, không có tác dụng phụ (15)

Mức 2 — thay đổi trạng thái, không tiêu gì (17)

Mức 3 — tiêu tiền, xóa dữ liệu hoặc cấp quyền (8)

Nhật ký thay đổi bộ công cụ

Phiên bản đang chạy là công khai: curl -s https://mcp.eqvps.com/healthz. Khi nó thay đổi, bảng này cũng thay đổi theo.

Số dư là trần chi tiêu

EQVPS là dịch vụ trả trước. Không có thẻ lưu sẵn, không có hạn mức tín dụng, không thể âm số dư: số tiền tối đa một agent có thể tiêu là số đang có trong số dư. Ba công cụ tiêu tiền: order_vps, change_plan và create_sandbox. Việc gia hạn các máy chủ hiện có cũng trừ vào cùng số dư đó.

Agent có thể tạo yêu cầu thanh toán, nhưng không thể tự trả. topup_balance và pay_invoice trả về một liên kết thanh toán crypto, và một liên kết chẳng làm được gì nếu không có ví đứng sau. Cũng không có endpoint rút tiền: tiền trong số dư chỉ mua được dịch vụ trong tài khoản của bạn, không chuyển ra ngoài được. Tiền hoàn khi hủy ngay cũng quay về số dư.

Có một lưu ý, và nó nghiêm túc. Nếu bạn để số dư quá thấp để kìm agent lại, chính các lần gia hạn của bạn sẽ bắt đầu thất bại và máy chủ rơi vào thời gian ân hạn. Quy tắc của chúng tôi: một chu kỳ gia hạn cho những gì đang chạy, cộng ngân sách cho công việc hiện tại của agent. Hướng dẫn ngân sách cho agent trình bày cách tính. Và nếu bạn đưa cho agent một ví riêng có tiền, chiếc ví đó trở thành trần thứ hai mà bạn cũng phải theo dõi.

Đặc quyền tối thiểu: (hiện) chưa có token chỉ đọc

Trả lời thẳng: mọi token khách hàng đều có quyền giống tài khoản trong bảng điều khiển. Tên và thời hạn của token thì chỉnh được, phạm vi quyền (scope) thì không.

Thứ hẹp nhất hiện có là ủy quyền. Bạn tạo cho agent một tài khoản riêng với số dư bằng không và ủy quyền cho nó một máy chủ:

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

Tương tự qua 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}'

Lời mời phải được chấp nhận khi đang đăng nhập bằng email đó (accept_delegation), và expires_days từ 1 đến 365. Hướng dẫn từng bước có ảnh chụp màn hình: ủy quyền truy cập và mục truy cập trong tài liệu.

Hãy để ý hai dòng cuối bên trái. Người được ủy quyền không tiêu được tiền của bạn, nhưng xóa được máy chủ đó. Hãy bật sao lưu trên mọi máy chủ mà agent có thể cài lại.

Giữ gìn token

Mỗi agent một token, có đặt tên. Tạo trong Bảng điều khiển → Cài đặt → API token cho agent, hoặc như sau:

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 chỉ hiện một lần. Thời hạn từ 1 đến 1825 ngày, mặc định 365 nếu bạn không chỉ định. Với agent, chúng tôi sẽ chọn 90.

Cất nó trong một tệp chỉ mình bạn đọc được, không để trong repo, không để trong prompt, không để trong biến shell bạn sao chép khắp nơi:

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   # kỳ vọng: -rw-------

Sau đó nạp nó vào dịch vụ của agent bằng EnvironmentFile= (systemd) hoặc set -a; . ~/.config/eqvps/agent.env; set +a.

Xoay vòng trước khi hết hạn. Công cụ refresh_token, hoặc POST /auth/tokens/{id}/refresh, cấp token mới cùng tên và thu hồi token cũ ngay lập tức. Nếu token được ghi cứng trong cấu hình MCP client, hãy cập nhật ngay sau đó, nếu không phiên tiếp theo sẽ nhận 401.

Kiểm tra ai đang dùng gì: GET /auth/tokens liệt kê mọi token kèm tên, hạn dùng và last_used_at. Một token bạn không nhận ra, hoặc một token vẫn được dùng sau khi bạn đã tắt agent, chính là tín hiệu cảnh báo.

Nếu token bị lộ

Theo thứ tự này:

1. Thu hồi nó. Bảng điều khiển → Cài đặt → API token cho agent → Thu hồi, hoặc curl -s -X DELETE -H "Authorization: Bearer $EQVPS_TOKEN" https://api.eqvps.com/api/v1/eqvps/auth/tokens/<id>. Nó ngừng hoạt động từ yêu cầu kế tiếp.
2. Tìm token mới mà bạn không tạo, và thu hồi luôn.
3. Rà soát phạm vi ảnh hưởng: lịch sử dịch vụ của từng máy chủ, hóa đơn và số dư, và list_delegations xem có quyền truy cập nào bạn không cấp.
4. Đổi mật khẩu root trên mọi máy chủ token đó nhìn thấy được. get_vps_status kèm reveal: true trao ra mật khẩu root, nên lộ token tức là lộ mật khẩu root. Tiện thể kiểm tra ~/.ssh/authorized_keys.
5. Đóng cửa mật khẩu. Nếu tài khoản của bạn chưa từng có mật khẩu, người giữ token có thể đã đặt một mật khẩu bằng set_password. Đăng nhập bằng mã gửi qua email và đổi mật khẩu.

Phòng bước 5 chẳng tốn gì: tự đặt mật khẩu tài khoản ngay bây giờ, và set_password sẽ trả về 409 cho bất kỳ ai đến sau bạn.

Con người phê duyệt

Những gì máy chủ áp dụng:

• reinstall_vps, reset_password và cancel_service với type: immediate yêu cầu confirm đúng chính xác hostname (DELETE cũng dùng được cho cài lại và đặt lại mật khẩu).
• change_plan yêu cầu confirm: true.
• Kiểu hủy mặc định là end_of_period: máy chủ chạy tới hết kỳ đã trả tiền, và undo_cancel hoàn tác được.
• Giới hạn tần suất theo tài khoản: cài lại 4/phút, đặt lại mật khẩu 6/phút, bật/tắt nguồn 20/phút, đặt mua 20/phút. Đủ để một vòng lặp không làm việc đó năm mươi lần, không đủ để chặn một lệnh gọi sai duy nhất.

Hãy hiểu rõ confirm là gì. Nó ngăn agent hành động theo câu "dọn chỗ đó đi". Nó không chặn được kẻ tấn công, vì hostname chỉ cách một lệnh get_vps_status. Phê duyệt thật sự nằm trong MCP client của bạn. Hầu hết client đều có thể hỏi trước mỗi lần gọi công cụ: để mức 0 và 1 chạy tự do, cho mức 3 luôn phải hỏi. Ở các client có phân quyền theo từng công cụ, như settings.json của Claude Code (máy chủ đăng ký với tên 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"]
  }
}

Hãy thêm một dòng vào chỉ dẫn của agent nữa. Tự nó không phải biện pháp bảo mật, nhưng giảm được các trường hợp hiểu nhầm (cứ để tiếng Anh, mô hình hiểu nó như nhau):

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.

Nếu agent đăng nhập bằng mã email thay vì giữ token dài hạn, hãy xem đăng nhập agent qua MCP.

Kiểm toán: sau đó bạn thấy được gì

• Danh sách token (GET /auth/tokens, hoặc Cài đặt → API token cho agent): tên, ngày tạo, hạn dùng, last_used_at. Đó là lý do nên đặt tên token theo từng agent.
• Lịch sử dịch vụ (bảng điều khiển, trang máy chủ): thao tác nguồn, cài lại, đặt lại mật khẩu, đổi gói, thanh toán, mỗi mục có thời gian và tác nhân: bạn, bộ phận hỗ trợ hoặc tự động. Nó không cho biết token hay người được ủy quyền nào đã thực hiện, chỉ cho biết thao tác đến từ phía bạn.
• Hóa đơn và số dư: từng khoản trừ và hoàn tiền.
• list_delegations: ai có quyền truy cập vào đâu, và tới khi nào.

Khoảng trống đó trong lịch sử dịch vụ là giới hạn thật thà của kiểm toán phía máy chủ hiện nay. Nếu bạn cần biết agent nào đã làm gì, hãy ghi log mọi lần gọi công cụ kèm tham số (bỏ các bí mật) ở phía agent.

Cách thiết lập chúng tôi sẽ chọn

Với một agent quản lý một máy chủ production:

1. Một tài khoản riêng cho agent, số dư bằng không, máy chủ được ủy quyền với expires_days: 90.
2. Token chủ sở hữu của bạn ở lại với bạn, không nằm trong bất kỳ cấu hình agent nào.
3. Bật sao lưu cho máy chủ đó, vì người được ủy quyền có thể cài lại.
4. Các công cụ mức 3 đặt ở "ask" hoặc "deny" trong client.
5. Token của agent nằm trong tệp quyền 600, được làm mới trước khi hết hạn.

Với agent cần đặt mua máy chủ hoặc chạy sandbox, ủy quyền là không đủ vì nó cần số dư. Khi đó số dư là trần của bạn: nạp theo từng việc, đặt tên token và xem last_used_at mỗi tuần một lần. Nếu một token chỉ đọc sẽ thay đổi cách bạn triển khai agent, hãy cho chúng tôi biết qua hỗ trợ: chính những phản hồi như vậy quyết định chúng tôi làm gì tiếp theo.