Bỏ qua nội dung chính
XÁC ĐỊNH BÊN GỌI MCP

Biết ai đang gọi MCP server của bạn

MCP server của bạn cung cấp tool cho các client AI mà bạn không kiểm soát. Proof of Actor cho bạn biết điều gì đứng sau mỗi lệnh gọi, bằng chứng nào hỗ trợ kết quả đó, và cho phép bạn đặt chính sách theo từng tool.

Nhận quyền truy cập sớmKhám phá cách hoạt động
Toshendra Sharma

Bởi Toshendra SharmaNhà sáng lập và CEO, AgentCredia · Updated November 13, 2026

Công cụ của bạn mở cho những bên gọi mà bạn không thể nhìn thấy

Một MCP server làm cho sản phẩm của bạn có thể dùng được bởi các client AI. Nó cung cấp các tool, tài nguyên và prompt mà trợ lý và agent có thể khám phá và gọi, sử dụng các thông điệp JSON-RPC 2.0 giữa host, client và server như được mô tả trong đặc tả Model Context Protocol. Đó chính là lý do các nhóm xây dựng chúng: đưa sản phẩm của bạn vào trong các workflow nơi các agent AI đã đang làm việc.

Điều đó cũng có nghĩa là server của bạn nhận các lệnh gọi từ những client mà bạn không xây dựng và không thể quan sát trực tiếp. Một tool duy nhất có thể được gọi bởi một nhà phát triển đang thử nghiệm cục bộ, bởi một trợ lý máy tính để bàn hành động cho một người đã đăng nhập, bởi một agent tự trị đang chạy một tác vụ dài qua đêm, hoặc bởi thứ gì đó đang dò tìm điểm yếu trên server của bạn. Giao thức cho bạn biết tool nào đã được gọi và với đối số nào. Bản thân nó không cho bạn biết loại tác nhân nào đứng sau lệnh gọi, hoặc bạn nên tin cậy nó đến mức nào.

Xác định danh tính bên gọi MCP server lấp đầy khoảng trống đó. Proof of Actor thêm kết quả tác nhân dựa trên bằng chứng vào từng lệnh gọi tool, để server của bạn có thể đưa ra quyết định sáng suốt về ai nhận được gì. Để xem sâu hơn về vấn đề này, hãy đọc ai đang gọi MCP server của bạn, và xem trường hợp sử dụng MCP servers để biết các nhóm áp dụng nó như thế nào.

Lưu ý về thuật ngữ. "Caller identity" cũng có một nghĩa quen thuộc trong hạ tầng đám mây. Ví dụ, AWS STS GetCallerIdentity trả về chi tiết về IAM user hoặc role có credential được dùng để gọi operation. Điều đó trả lời câu hỏi credential đám mây nào đã thực hiện một lệnh gọi. Xác định danh tính bên gọi MCP server trên trang này trả lời một câu hỏi khác: loại tác nhân nào, Human, Human + AI, Agent hay Unknown, đứng sau một lệnh gọi tool tới MCP server của bạn, và bằng chứng nào hỗ trợ câu trả lời đó.

Điều gì làm cho bên gọi MCP khác biệt

Bên gọi MCP khác với người truy cập trình duyệt và với client API truyền thống ở những điểm quan trọng đối với chính sách.

  • Chúng hầu như luôn được tự động hóa. Câu hỏi không còn là "người hay bot?" mà là "agent nào, hành động ra sao, với bằng chứng gì?"
  • Chúng thường hành động thay cho một người. Một trợ lý có thể đang gọi tool của bạn vì người dùng yêu cầu, hoặc nó có thể đang hoạt động tự động. Những trường hợp đó cần được xử lý khác nhau.
  • Chúng tự mô tả về mình. Đặc tả vòng đời của MCP yêu cầu client gửi một đối tượng clientInfo với tên và phiên bản trong request initialize. Khai báo đó là ngữ cảnh hữu ích, nhưng nó là một tuyên bố, không phải bằng chứng.
  • Các tool khác nhau rất nhiều về mức độ ảnh hưởng. Một tool tìm kiếm và một tool xóa bản ghi không nên dùng chung một chính sách.

Xác định danh tính bên gọi MCP tốt cần tôn trọng cả bốn điều đó.

Proof of Actor xác định bên gọi MCP như thế nào

Tín hiệu từ server của bạn

Tích hợp MCP của bạn chuyển cho Proof of Actor ngữ cảnh sẵn có cho mỗi lệnh gọi: chi tiết do client khai báo, ngữ cảnh truyền tải và request, mọi chữ ký request mật mã mà client cung cấp, chẳng hạn như HTTP Message Signatures được định nghĩa trong RFC 9421, và tool đang được gọi. Mỗi tín hiệu được gắn nhãn theo nguồn gốc của nó.

Phân loại với cơ sở

Proof of Actor trả về một trong bốn lớp, Human, Human + AI, Agent hoặc Unknown, cùng với cơ sở của kết quả:

  • verified khi một kiểm tra mật mã, chẳng hạn như chữ ký request đối chiếu với một public key đã công bố, đã qua;
  • declared khi client hoặc ứng dụng của bạn đã tuyên bố điều đó, chẳng hạn như tên client trong phiên;
  • inferred khi kết quả dựa trên các mẫu trong lệnh gọi;
  • unknown khi bằng chứng không đủ để đưa ra kết luận.

Tên client được khai báo không bao giờ được trình bày như là xác minh. Khi bằng chứng quá mỏng, kết quả là Unknown thay vì một phỏng đoán tự tin, và server của bạn biết chính xác mình đang làm việc với điều gì.

Một kết quả mà tool của bạn có thể dùng

Kết quả tác nhân đi kèm với lệnh gọi tool, sẵn sàng cho logic của server bạn. Ở chế độ quan sát, bạn ghi nhận nó. Khi đã sẵn sàng, các chính sách ở cấp tool của bạn sẽ hành động dựa trên nó.

Nhóm của bạn nhận được gì: Detect, Understand, Route

Detect

Thu thập bằng chứng bên gọi có sẵn trên mọi lệnh gọi tool và giữ bằng chứng verified, declared và inferred tách biệt.

Understand

Xem client nào gọi tool nào, với tần suất bao nhiêu, với loại bằng chứng gì, và điều đó thay đổi theo thời gian ra sao. Phát hiện các tool chủ yếu thu hút bên gọi Unknown, các client thay đổi hành vi, và tỷ lệ lệnh gọi mang danh tính có thể xác minh.

Route

Viết chính sách theo từng tool và từng mức rủi ro. Các mẫu thường gặp:

  • Các tool ít ảnh hưởng như tìm kiếm hoặc tra cứu chỉ đọc: cho phép rộng rãi, với một giới hạn rate limit chuẩn.
  • Các tool có ảnh hưởng trung bình như tạo bản nháp: cho phép bên gọi verified và declared, rate-limit Unknown.
  • Các tool có ảnh hưởng cao như xóa dữ liệu, thay đổi cài đặt hoặc gửi tin nhắn thay mặt người dùng: yêu cầu ủy quyền mạnh nhất của bạn, và thêm bước xác nhận hoặc xem xét khi bên gọi là Unknown hoặc đang hoạt động tự động.

Hướng dẫn về bảo vệ các hành động nhạy cảm mà không chặn agent cho thấy cách thiết kế các mức này.

Bằng chứng danh tính, credential và ủy quyền là các phần riêng biệt

Bảo mật MCP hoạt động tốt nhất khi ba câu hỏi này vẫn tách biệt:

  1. Bằng chứng danh tính: client nào đang gọi, và điều gì chứng minh điều đó? Proof of Actor cung cấp điều này.
  2. Credential: lệnh gọi này đang được thực hiện với account hoặc token nào? Xác thực của MCP server bạn cung cấp điều này. Đặc tả ủy quyền của MCP khiến ủy quyền trở thành tùy chọn và, với các transport dựa trên HTTP, đặt nó trên OAuth 2.1, trong đó MCP server hoạt động như một resource server xác thực access token.
  3. Ủy quyền: bên gọi này có thể dùng tool này, với các đối số này, cho account này không? Mô hình quyền của bạn cung cấp điều này.

Một client đã được nhận diện không tự động là một client được ủy quyền. Một chữ ký hợp lệ không cho thấy người đứng sau phiên đã ủy quyền cho hành động cụ thể này. Đọc thêm về ủy quyền được giao phó và ủy quyền agent. Proof of Actor cung cấp cho server của bạn ngữ cảnh tốt hơn cho câu hỏi đầu tiên để câu trả lời của bạn cho câu hỏi thứ hai và thứ ba được thông tin đầy đủ hơn.

Vì sao không chỉ tin vào tên client?

Vì bất kỳ client nào cũng có thể gửi bất kỳ tên nào. Xem tên được khai báo như là bằng chứng sẽ mở cửa cho việc giả mạo: một client độc hại chỉ cần sao chép tên của một trợ lý phổ biến. Proof of Actor ghi nhận tên như bằng chứng khai báo, kết hợp nó với bất kỳ bằng chứng mạnh hơn nào tồn tại, và cho bạn biết cơ sở. Chính sách của bạn sau đó có thể cho bên gọi verified nhiều không gian hơn so với bên gọi chỉ tự khai báo, và áp dụng phương án dự phòng Unknown khi không có cái nào phù hợp.

Bắt đầu ở chế độ quan sát

Cài đặt Proof of Actor trong MCP server của bạn không thay đổi cách bất kỳ tool nào phản hồi. Kết quả được ghi lại để bạn có thể thấy ai đang gọi tool của bạn, bằng chứng mạnh đến đâu, và ở đâu thì chính sách sẽ hữu ích. Khi đã tự tin, hãy bật một chính sách trên một tool có ảnh hưởng cao duy nhất, theo dõi kết quả, rồi mở rộng. Cách hoạt động trình bày toàn bộ luồng, và Phát hiện và giới hạn giải thích mỗi loại bằng chứng có thể và không thể xác lập điều gì.

Được xây dựng cho các nhóm vận hành MCP server và APIs

Proof of Actor nằm bên trong server của bạn cùng với xác thực, rate limiting và logging hiện có. Các tích hợp được cung cấp thực hành cùng từng nhóm founding, để phần thiết lập phù hợp với transport, hosting và thiết kế tool của bạn. Các trường hợp sử dụng MCP Servers và APIs cho thấy cùng một cách tiếp cận áp dụng như thế nào trên các tool của bạn và API của bạn.

Những câu hỏi cần đặt ra cho mọi tool bạn công khai

Trước khi viết chính sách ở cấp tool, nên xem lại từng tool mà MCP server của bạn cung cấp với một danh sách kiểm tra ngắn:

  • Tool này có thể thay đổi điều gì? Các tool chỉ đọc và các tool sửa đổi dữ liệu, gửi tin nhắn hoặc ảnh hưởng đến thanh toán xứng đáng được xử lý khác nhau.
  • Nó dành cho ai? Một số tool tồn tại cho các trợ lý hành động thay mặt một người đã đăng nhập; những tool khác dành cho workflow tự động. Bên gọi dự kiến định hình chính sách phù hợp.
  • Một sai lầm sẽ tốn kém bao nhiêu? Một kết quả tìm kiếm sai thì ít tốn kém. Một lần xóa nhầm thì không. Hãy ánh xạ từng tool vào một mức rủi ro.
  • Nên yêu cầu bằng chứng gì? Quyết định xem một client được khai báo là đủ hay tool cần danh tính đã xác minh cộng với ủy quyền mạnh nhất của bạn.
  • Điều gì xảy ra với Unknown? Chọn một phương án dự phòng rõ ràng cho từng tool: cho phép, rate-limit, yêu cầu người dùng xác nhận, hoặc chuyển sang xem xét.
  • Làm sao bạn biết nó đang hoạt động? Quyết định những kết quả nào bạn sẽ theo dõi ở chế độ quan sát trước khi thực thi bất kỳ điều gì.

Trả lời những câu hỏi này một lần cho mỗi tool sẽ biến xác định danh tính bên gọi thành các quy tắc rõ ràng, có thể kiểm thử, và giúp bạn dễ giải thích hành vi của server cho các client tích hợp với nó.

Tham gia chương trình founding developer

Proof of Actor đang ở private beta. Các nhóm phát triển founding được chọn có thể nhận tối đa 12 tháng truy cập miễn phí, trong phạm vi mức sử dụng đã thỏa thuận, cùng hỗ trợ trực tiếp từ đội ngũ kỹ sư của chúng tôi khi bạn thiết kế chính sách ở cấp tool.

Nếu bạn vận hành một MCP server và muốn biết ai đang gọi nó, hãy đăng ký quyền truy cập sớm. Hãy cho chúng tôi biết về server của bạn, các tool bạn cung cấp và những lệnh gọi bạn quan tâm nhất.

Nguồn

DÀNH CHO NHÀ PHÁT TRIỂN

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record
{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}
class
Human, Human + AI, Agent hoặc Unknown.
basis
Bằng chứng mạnh đến mức nào: verified, declared, inferred hoặc unknown.
evidence
Các tín hiệu phía sau kết quả, để team của bạn thấy được lý do.

Bắt đầu ở chế độ quan sát: ghi kết quả cạnh logs của bạn và không thay đổi gì cho đến khi bạn chọn một chính sách. Đọc hướng dẫn tích hợp Node.js

Câu hỏi thường gặp

Vì sao một MCP server cần xác định danh tính bên gọi?

MCP server cung cấp tool cho các client AI hành động thay mặt con người hoặc chạy tự động. Biết loại bên gọi nào đứng sau một lệnh gọi tool cho phép bạn mở rộng quyền cho các tool ít ảnh hưởng và yêu cầu nhiều hơn cho các tool có ảnh hưởng cao.

Tên client trong một phiên MCP có phải là xác minh không?

Không. Tên client là một tuyên bố do client đưa ra. Proof of Actor ghi nhận nó là bằng chứng khai báo và giữ nó tách biệt với danh tính đã được xác minh bằng mật mã.

Xác định danh tính bên gọi có thay thế cho ủy quyền MCP không?

Không. Bằng chứng danh tính bên gọi, credential được dùng và những gì bên gọi được phép làm là các câu hỏi khác nhau. Proof of Actor bổ sung ngữ cảnh cho câu hỏi đầu tiên và để việc ủy quyền cho server của bạn quyết định.

Proof of Actor có chặn lệnh gọi tool không?

Chỉ khi chính sách của bạn yêu cầu như vậy. Mọi tích hợp đều bắt đầu ở chế độ quan sát, và bạn bật chính sách ở cấp tool khi đã sẵn sàng.

Tôi có thể dùng thử như thế nào?

Hãy đăng ký quyền truy cập sớm. Các nhóm founding developer được chọn có thể nhận tối đa 12 tháng miễn phí trong phạm vi mức sử dụng đã thỏa thuận, kèm hỗ trợ tích hợp thực hành.

Biết ai đang dùng app của bạn.

Private beta dành cho một nhóm nhỏ các nhà phát triển sáng lập.

Nhận quyền truy cập sớmXem giá

Bạn muốn trao đổi trước? Trao đổi với những người sáng lập