ข้ามไปยังเนื้อหาหลัก
การระบุตัวตนผู้เรียก MCP

รู้ว่าใครกำลังเรียก MCP server ของคุณ

MCP server ของคุณเปิดเผย tools ให้กับ AI clients ที่คุณไม่ได้ควบคุม Proof of Actor บอกคุณว่าอะไรอยู่เบื้องหลังแต่ละการเรียก หลักฐานใดรองรับผลลัพธ์นั้น และให้คุณตั้ง policy แยกตาม tool ได้

ขอสิทธิ์เข้าถึงก่อนใครสำรวจวิธีการทำงาน
Toshendra Sharma

โดย Toshendra Sharmaผู้ก่อตั้งและ CEO, AgentCredia · Updated November 13, 2026

tools ของคุณเปิดรับผู้เรียกที่คุณมองไม่เห็น

An MCP server ทำให้ผลิตภัณฑ์ของคุณใช้งานได้โดย AI clients มันเปิดเผย tools, resources และ prompts ที่ assistants และ agents สามารถค้นหาและเรียกใช้ได้ โดยใช้ข้อความ JSON-RPC 2.0 ระหว่าง hosts, clients และ servers ตามที่อธิบายไว้ใน Model Context Protocol specification นี่คือเหตุผลที่ทีมต่างๆ สร้างมันขึ้นมาโดยตรง เพราะมันนำผลิตภัณฑ์ของคุณไปอยู่ใน workflows ที่ AI agents กำลังทำงานอยู่แล้ว

แต่ก็หมายความว่า server ของคุณจะได้รับการเรียกจาก clients ที่คุณไม่ได้สร้างและไม่สามารถสังเกตได้โดยตรง tool เดียวอาจถูกเรียกโดย developer ที่กำลังทดสอบในเครื่อง โดย desktop assistant ที่ทำงานแทนบุคคลที่ลงชื่อเข้าใช้ โดย autonomous agent ที่รันงานยาวข้ามคืน หรือโดยบางอย่างที่กำลังตรวจสอบ server ของคุณเพื่อหาจุดอ่อน protocol บอกคุณว่า tool ใดถูกเรียก และมี arguments อะไรบ้าง แต่ไม่ได้บอกด้วยตัวเองว่ามี actor ประเภทใดอยู่เบื้องหลังการเรียก หรือคุณควรไว้วางใจมากแค่ไหน

การระบุตัวตนผู้เรียก MCP server เติมช่องว่างนั้น Proof of Actor เพิ่มผลลัพธ์ของ actor ที่อิงหลักฐานให้กับทุก tool call เพื่อให้ server ของคุณตัดสินใจได้อย่างมีข้อมูลว่าใครได้อะไร หากต้องการมองปัญหานี้ในภาพรวมที่ลึกขึ้น โปรดอ่าน who is calling your MCP server และดู MCP servers use case ว่าทีมต่างๆ นำไปใช้อย่างไร

หมายเหตุเกี่ยวกับคำศัพท์ "Caller identity" ยังมีความหมายที่เป็นที่รู้จักกันดีในโครงสร้างพื้นฐานคลาวด์อีกด้วย ตัวอย่างเช่น AWS STS GetCallerIdentity จะคืนรายละเอียดเกี่ยวกับ IAM user หรือ role ที่มี credential ใช้เรียก operation นั้น ซึ่งตอบคำถามว่า credential ของคลาวด์ใดเป็นผู้เรียก ส่วนการระบุตัวตนผู้เรียก MCP server บนหน้านี้ตอบคำถามที่ต่างออกไป คือ actor ประเภท Human, Human + AI, Agent หรือ Unknown ใดอยู่เบื้องหลัง tool call ไปยัง MCP server ของคุณ และหลักฐานใดรองรับคำตอบนั้น

อะไรทำให้ผู้เรียก MCP แตกต่าง

ผู้เรียก MCP แตกต่างจากผู้เยี่ยมชมผ่าน browser และจาก traditional API clients ในลักษณะที่สำคัญต่อ policy

  • แทบทั้งหมดเป็นแบบอัตโนมัติ คำถามจึงไม่ใช่ "มนุษย์หรือ bot" แต่เป็น "agent ใด ทำงานอย่างไร และมีหลักฐานอะไร"
  • มักทำงานแทนบุคคล assistant อาจเรียก tool ของคุณเพราะ user ขอให้ทำ หรืออาจทำงานแบบอิสระ กรณีเหล่านี้ควรได้รับการจัดการต่างกัน
  • มันประกาศตัวเอง MCP lifecycle specification ให้ client ส่งออบเจ็กต์ clientInfo ที่มี name และ version ในคำขอ initialize การประกาศนั้นให้บริบทที่มีประโยชน์ แต่ยังเป็นเพียงการประกาศ ไม่ใช่หลักฐาน
  • tools มีผลกระทบแตกต่างกันมาก tool สำหรับค้นหา และ tool สำหรับลบข้อมูล ไม่ควรถูกใช้ policy เดียวกัน

การระบุตัวตนผู้เรียก MCP ที่ดีต้องเคารพทั้งสี่ข้อ

Proof of Actor ระบุตัวตนผู้เรียก MCP อย่างไร

สัญญาณจาก server ของคุณ

การผสาน MCP ของคุณส่งบริบทที่มีให้กับ Proof of Actor สำหรับแต่ละการเรียก ได้แก่ รายละเอียดที่ client ประกาศไว้ บริบทของ transport และ request ลายเซ็นคำขอเชิงคริปโตกราฟีใดๆ ที่ client ส่งมา เช่น HTTP Message Signatures ที่กำหนดไว้ใน RFC 9421 และ tool ที่กำลังถูกเรียก สัญญาณแต่ละอย่างจะถูกระบุฉลากตามแหล่งที่มา

การจัดประเภทพร้อมฐานรองรับ

Proof of Actor ส่งกลับหนึ่งในสี่ class คือ Human, Human + AI, Agent หรือ Unknown พร้อมกับ basis ของผลลัพธ์:

  • verified เมื่อการตรวจสอบเชิงคริปโตกราฟี เช่น ลายเซ็นคำขอที่ตรวจสอบกับ public key ที่เผยแพร่ไว้ ผ่านแล้ว;
  • declared เมื่อ client หรือ application ของคุณเป็นผู้ระบุไว้ เช่น ชื่อ client ใน session;
  • inferred เมื่อผลลัพธ์อาศัยรูปแบบใน calls;
  • unknown เมื่อหลักฐานไม่เพียงพอที่จะสรุปได้

ชื่อ client ที่ประกาศไว้จะไม่ถูกนำเสนอเป็นการยืนยันอย่างเด็ดขาด เมื่อหลักฐานมีน้อย ผลลัพธ์จะเป็น Unknown แทนการคาดเดาแบบมั่นใจเกินไป และ server ของคุณจะรู้ชัดเจนว่ากำลังทำงานกับอะไร

ผลลัพธ์ที่ tools ของคุณนำไปใช้ได้

ผลลัพธ์ของ actor มาถึงพร้อมกับ tool call พร้อมให้ logic ของ server ใช้งานได้ ในโหมด observation คุณบันทึกมันไว้ เมื่อพร้อมแล้ว policy ระดับ tool ของคุณจึงค่อยทำงานกับมัน

ทีมของคุณได้อะไรบ้าง: Detect, Understand, Route

Detect

เก็บหลักฐานของผู้เรียกที่มีอยู่ในทุก tool call และแยกหลักฐาน verified, declared และ inferred ให้อยู่คนละส่วนกัน

Understand

ดูว่า client ใดเรียก tool ใด บ่อยแค่ไหน ด้วยหลักฐานแบบใด และสิ่งนั้นเปลี่ยนไปอย่างไรเมื่อเวลาผ่านไป สังเกต tools ที่ดึงดูดผู้เรียก Unknown เป็นส่วนใหญ่ clients ที่เปลี่ยนพฤติกรรม และสัดส่วนของ calls ที่มีตัวตนที่ตรวจสอบได้

Route

เขียน policy แยกตาม tool และตามระดับความเสี่ยง รูปแบบที่พบบ่อย:

  • tools ที่มีผลกระทบน้อย เช่น search หรือการค้นหาแบบอ่านอย่างเดียว: อนุญาตอย่างกว้างขวาง พร้อม rate limit มาตรฐาน
  • tools ที่มีผลกระทบปานกลาง เช่น การสร้าง draft: อนุญาตผู้เรียกที่ verified และ declared, rate-limit Unknown
  • tools ที่มีผลกระทบสูง เช่น การลบ data, การเปลี่ยน settings หรือการส่งข้อความแทน user: ต้องใช้ authorization ที่เข้มที่สุดของคุณ และเพิ่มการยืนยันหรือ review เมื่อผู้เรียกเป็น Unknown หรือทำงานโดยอัตโนมัติ

คู่มือ protecting sensitive actions without blocking agents แสดงวิธีออกแบบระดับเหล่านี้

หลักฐานตัวตน, credential และ authorization เป็นคนละเรื่องกัน

MCP security ทำงานได้ดีที่สุดเมื่อสามคำถามนี้ยังแยกจากกัน:

  1. หลักฐานตัวตน: client ประเภทใดเป็นผู้เรียก และอะไรเป็นข้อพิสูจน์ Proof of Actor ให้ส่วนนี้
  2. credentials: การเรียกนี้ใช้บัญชีหรือ token ใด Your MCP server's authentication เป็นผู้ให้ส่วนนี้ MCP authorization specification ทำให้ authorization เป็นสิ่งที่เลือกเปิดใช้ได้ และสำหรับ transports ที่ใช้ HTTP จะอ้างอิง OAuth 2.1 โดยให้ MCP server ทำหน้าที่เป็น resource server ที่ตรวจสอบ access tokens
  3. authorization: ผู้เรียกนี้สามารถใช้ tool นี้ พร้อม arguments เหล่านี้ สำหรับบัญชีนี้ได้หรือไม่ Permission model ของคุณเป็นผู้ให้ส่วนนี้

client ที่ได้รับการยอมรับไม่ได้หมายความว่าได้รับอนุญาตโดยอัตโนมัติ ลายเซ็นที่ถูกต้องไม่ได้แสดงว่าบุคคลที่อยู่เบื้องหลัง session ได้มอบอำนาจสำหรับการกระทำเฉพาะนี้แล้ว อ่านเพิ่มเติมเกี่ยวกับ delegated authority และ agent authorization Proof of Actor ให้บริบทที่ดีกว่าสำหรับคำถามแรก เพื่อให้คำตอบของคุณต่อคำถามที่สองและสามมีข้อมูลประกอบมากขึ้น

ทำไมไม่เชื่อชื่อ client ไปเลย?

เพราะ client ใดก็ส่งชื่อใดก็ได้ การมองชื่อที่ประกาศไว้ว่าเป็นหลักฐานเชิญชวนให้เกิดการปลอมแปลง: client ที่ไม่เป็นมิตรเพียงแค่คัดลอกชื่อของ assistant ยอดนิยม Proof of Actor บันทึกชื่อไว้เป็น declared evidence นำมารวมกับหลักฐานที่เข้มแข็งกว่าที่มี และบอกคุณว่าฐานของผลลัพธ์คืออะไร จากนั้น policy ของคุณจะให้ verified callers มีขอบเขตกว้างกว่าผู้เรียกที่เพียงแค่ประกาศตัวเอง และใช้ fallback แบบ Unknown ของคุณเมื่อไม่มีเงื่อนไขใดตรง

เริ่มในโหมด observation

การติดตั้ง Proof of Actor ใน MCP server ของคุณไม่เปลี่ยนวิธีที่ tool ใดตอบสนอง ผลลัพธ์จะถูกบันทึกไว้เพื่อให้คุณเห็นว่าใครเรียก tools ของคุณ หลักฐานมีความแข็งแรงแค่ไหน และ policy ใดจะช่วยได้ เมื่อคุณมั่นใจแล้ว ให้เปิด policy บน tool ที่มีผลกระทบสูงเพียงหนึ่งรายการ ดูผลลัพธ์ แล้วค่อยขยายออกไป How It Works อธิบาย flow ทั้งหมด และ Detection & Limitations อธิบายว่าหลักฐานแต่ละประเภทสามารถและไม่สามารถพิสูจน์อะไรได้บ้าง

สร้างมาสำหรับทีมที่ดูแล MCP servers และ APIs

Proof of Actor ทำงานอยู่ภายใน server ของคุณร่วมกับ authentication, rate limiting และ logging ที่มีอยู่แล้ว การผสานใช้งานจะส่งมอบแบบลงมือช่วยร่วมกับแต่ละ founding team เพื่อให้การตั้งค่าสอดคล้องกับ transport, hosting และการออกแบบ tool ของคุณ use cases MCP Servers และ APIs แสดงให้เห็นว่าวิธีเดียวกันนี้นำไปใช้ได้ทั่วทั้ง tools ของคุณและ API ของคุณ

คำถามที่ควรถามเกี่ยวกับทุก tool ที่คุณเปิดเผย

ก่อนเขียน policy ระดับ tool การทบทวนแต่ละ tool ที่ MCP server ของคุณเปิดเผยด้วย checklist สั้นๆ จะช่วยได้:

  • tool นี้เปลี่ยนอะไรได้บ้าง? tools แบบอ่านอย่างเดียว และ tools ที่แก้ไข data, ส่งข้อความ หรือมีผลต่อ billing ควรได้รับการจัดการต่างกัน
  • มันมีไว้สำหรับใคร? บาง tools มีไว้สำหรับ assistants ที่ทำงานแทนคนที่ลงชื่อเข้าใช้; บาง tools มีไว้สำหรับ workflows แบบอัตโนมัติ ผู้เรียกที่คาดไว้เป็นตัวกำหนด policy ที่เหมาะสม
  • ความผิดพลาดจะมีต้นทุนเท่าไร? ผลการค้นหาที่ผิดพลาดมีต้นทุนน้อย การลบที่ผิดพลาดไม่ใช่เช่นนั้น จัดระดับความเสี่ยงให้แต่ละ tool
  • ควรต้องใช้หลักฐานอะไร? ตัดสินใจว่าชื่อ client ที่ประกาศไว้เพียงพอหรือไม่ หรือ tool ควรต้องใช้ identity ที่ verified พร้อม authorization ที่เข้มที่สุดของคุณ
  • ถ้าเป็น Unknown จะเกิดอะไรขึ้น? เลือก fallback ที่ชัดเจนสำหรับแต่ละ tool: allow, rate-limit, ขอให้ user ยืนยัน หรือส่งไป review
  • คุณจะรู้ได้อย่างไรว่ามันทำงานอยู่? ตัดสินใจว่าคุณจะติดตามผลลัพธ์ใดในโหมด observation ก่อนที่จะบังคับใช้อะไรทั้งสิ้น

การตอบคำถามเหล่านี้ครั้งละหนึ่ง tool จะเปลี่ยนการระบุตัวตนผู้เรียกให้เป็นกฎที่ชัดเจนและทดสอบได้ และทำให้ง่ายต่อการอธิบายพฤติกรรมของ server ของคุณต่อ clients ที่ผสานใช้งานกับมัน

เข้าร่วม founding developer program

Proof of Actor อยู่ใน private beta ทีมพัฒนา founding ที่ได้รับเลือกสามารถรับสิทธิ์เข้าถึงฟรีได้นานสูงสุด 12 เดือน ภายใต้ขอบเขตการใช้งานที่ตกลงกันไว้ พร้อมการสนับสนุนโดยตรงจากวิศวกรของเราในขณะที่คุณออกแบบ policy ระดับ tool

หากคุณดูแล MCP server และอยากรู้ว่าใครกำลังเรียกมันอยู่ สมัครขอ early access บอกเราเกี่ยวกับ server ของคุณ, tools ที่คุณเปิดเผย และ calls ที่คุณให้ความสำคัญมากที่สุด

แหล่งอ้างอิง

สำหรับนักพัฒนา

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 หรือ Unknown
basis
ระดับความแข็งแรงของหลักฐาน: Verified, Declared, Inferred หรือ Unknown
evidence
สัญญาณที่อยู่เบื้องหลังผลลัพธ์ เพื่อให้ทีมของคุณเห็นเหตุผล

เริ่มในโหมด observation: บันทึกผลลัพธ์ไว้ข้าง log ของคุณ และไม่เปลี่ยนแปลงอะไรจนกว่าคุณจะเลือกนโยบาย อ่านคู่มือการเชื่อมต่อ Node.js

คำถามที่พบบ่อย

ทำไม MCP server จึงต้องมีการระบุตัวตนผู้เรียก?

MCP servers เปิดเผย tools ให้กับ AI clients ที่ทำงานแทนคนหรือทำงานโดยอัตโนมัติ การรู้ว่าผู้เรียกเป็น actor ประเภทใดอยู่เบื้องหลัง tool call จะช่วยให้คุณอนุญาต tools ที่มีผลกระทบน้อยได้อย่างเปิดกว้าง และกำหนดเงื่อนไขเพิ่มเติมสำหรับ tools ที่มีผลกระทบสูง

ชื่อ client ใน MCP session ถือเป็นการยืนยันตัวตนหรือไม่?

ไม่ใช่ ชื่อ client เป็นการประกาศโดย client เอง Proof of Actor บันทึกไว้เป็น declared evidence และแยกออกจากตัวตนที่ได้รับการยืนยันด้วยคริปโตกราฟี

การระบุตัวตนผู้เรียกแทนที่ MCP authorization หรือไม่?

ไม่ใช่ หลักฐานตัวตนของผู้เรียก credential ที่ใช้ และสิ่งที่ผู้เรียกได้รับอนุญาตให้ทำ เป็นคนละคำถามกัน Proof of Actor เพิ่มบริบทให้กับคำถามแรก และปล่อยให้ server ของคุณจัดการ authorization

Proof of Actor จะบล็อก tool calls หรือไม่?

เฉพาะเมื่อ policy ของคุณกำหนดไว้เท่านั้น การผสานใช้งานทุกแบบเริ่มต้นในโหมด observation และคุณจึงค่อยเปิดใช้ policy ระดับ tool เมื่อพร้อม

ฉันจะลองใช้งานได้อย่างไร?

สมัครขอ early access ทีม founding developer ที่ได้รับเลือกสามารถรับสิทธิ์ใช้งานฟรีได้นานสูงสุด 12 เดือน ภายใต้ขอบเขตการใช้งานที่ตกลงกันไว้ พร้อมการสนับสนุนการผสานใช้งานแบบลงมือช่วย

รู้ว่าใครกำลังใช้แอปของคุณ

private beta สำหรับกลุ่มเล็กๆ ของ founding developers

ขอสิทธิ์เข้าถึงก่อนใครดูราคา

อยากคุยก่อนหรือไม่ พูดคุยกับผู้ก่อตั้ง