การเปรียบเทียบ

Proof of Actor เทียบกับการป้องกันบอตของ API: key บอกว่าใครเป็นผู้จ่าย แต่บริบทของ actor บอกว่าใครเป็นผู้กระทำ

API gateway, กฎบอตของ WAF, API keys และ rate limits ช่วยให้ API ของคุณพร้อมใช้งานและตรวจสอบได้ แต่ไม่ได้ถูกสร้างมาเพื่อบอกว่าคำขอหนึ่งมาจากคนที่ใช้งานแอป, คนที่ทำงานร่วมกับผู้ช่วย AI, หรือ agent อัตโนมัติ นี่คือวิธีที่การจัดการบอตสำหรับ API เปรียบเทียบกับ Proof of Actor และวิธีที่ทั้งสองส่วนทำงานร่วมกัน.

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

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

คำตอบสั้น

การจัดการบอตสำหรับ API ปกป้อง endpoint ของคุณ: gateway ยืนยันตัวตนของ key, กฎบอตของ WAF กรองทราฟฟิกที่เป็นการละเมิด และ rate limits จำกัดปริมาณการใช้งาน Proof of Actor เพิ่มชั้นอีกแบบหนึ่ง โดยบอก API ของคุณว่าผู้เรียกแต่ละรายเป็น Human, Human + AI, Agent หรือ Unknown พร้อมหลักฐานที่รองรับ เพื่อให้โค้ดของคุณตอบสนองได้อย่างเหมาะสมกับแต่ละราย ทีมส่วนใหญ่มักใช้ทั้งสองอย่างร่วมกัน.

API เคยมีโมเดลทราฟฟิกที่เรียบง่าย นักพัฒนาลงทะเบียน รับ key เขียน integration แล้ว integration นั้นก็เรียก endpoint ของคุณตามรอบเวลาหรือเมื่อผู้ใช้คลิกบางอย่าง การจัดการบอตสำหรับ API เติบโตขึ้นจากโมเดลนั้น: ยืนยันตัวตนของ key, จำกัดปริมาณ, กรองทราฟฟิกที่เห็นได้ชัดว่าเป็นการละเมิด และทำให้บริการพร้อมใช้งานสำหรับคนอื่นต่อไป

โมเดลนั้นยังคงใช้ได้ และเครื่องมือที่สร้างขึ้นเพื่อรองรับมันก็ยังสำคัญ สิ่งที่เปลี่ยนไปคือใครอยู่เบื้องหลังการเรียกใช้งาน key API เดียวกันนี้ตอนนี้อาจพาคำขอจากคนที่ใช้แอปของลูกค้าคุณ, คนที่ขอให้ AI assistant ทำงานแทน, และ agent อัตโนมัติที่ทำงานหลายขั้นตอนข้ามคืน การควบคุมที่คุณมีอยู่มองเห็นเพียง key เดียวและอัตราคำขอหนึ่งแบบ แต่การตัดสินใจด้านผลิตภัณฑ์, ซัพพอร์ต และนโยบายมักต้องการข้อมูลมากกว่านั้น

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

เวอร์ชันสั้น

	การป้องกันบอตสำหรับ API	Proof of Actor
คำถามหลัก	คำขอนี้อนุญาต, ยืนยันตัวตนแล้ว และอยู่ภายในขอบเขตหรือไม่?	ใครหรืออะไรเป็นผู้กระทำ และมีหลักฐานอะไร?
ชั้นที่ใช้โดยทั่วไป	API gateway, กฎบอตของ WAF, API keys, rate limits	การจำแนก actor ภายใน API หรือ MCP server ของคุณ
ระบุได้	บัญชีหรือ integration ที่เป็นเจ้าของ key	actor เบื้องหลังคำขอแต่ละรายการ: Human, Human + AI, Agent หรือ Unknown
ผลลัพธ์	allow, reject, throttle; บางครั้งเป็น bot score	class พร้อม basis: Verified, Declared, Inferred หรือ Unknown
ทราฟฟิกที่ไม่ชัดเจน	มักอนุญาตถ้า key ใช้ได้ หรือถูกปฏิเสธด้วย rule	Unknown พร้อม fallback ที่คุณเลือกแยกตาม route
ใครเป็นผู้ตัดสินการตอบสนอง	การตั้งค่าของ gateway และ WAF	โค้ดของแอปพลิเคชันคุณ
ค่าเริ่มต้นเมื่อเริ่มใช้	enforcement	observation; ไม่มีอะไรเปลี่ยนจนกว่าคุณจะเพิ่ม policy
เหมาะที่สุดกับ	ความพร้อมใช้งาน, การกรองการละเมิด, โควตา, ความรับผิดชอบ	การตอบสนองต่อ actor แต่ละแบบอย่างเหมาะสม และการทำความเข้าใจการใช้งาน API

ส่วนต่อไปจะอธิบายแต่ละส่วน

สิ่งที่การป้องกันบอตของ API ทำได้ดี

ควรระบุให้ชัดว่าชั้นแต่ละชั้นทำงานอะไร เพราะ Proof of Actor ถูกออกแบบมาให้อยู่เคียงข้างชั้นเหล่านี้ ไม่ใช่แทนที่ชั้นใดชั้นหนึ่ง

API gateway

gateway คือประตูหน้าของ API ของคุณ มันยุติการเชื่อมต่อ, ยืนยันตัวตนด้วย API keys หรือ tokens, ส่งคำขอไปยัง service ที่ถูกต้อง, บังคับใช้โควตา และมักบันทึกการใช้งานเพื่อการคิดค่าบริการและการวิเคราะห์ มันตอบคำถามว่า "ผู้เรียกนี้ได้รับอนุญาตให้เข้ามาหรือไม่ และต้องเข้าทางประตูไหน" ได้อย่างรวดเร็วและสม่ำเสมอในทุก endpoint

กฎบอตของ WAF

web application firewall ที่มีกฎบอตจะตรวจสอบทราฟฟิกเพื่อหารูปแบบการโจมตีที่รู้จักและการทำงานอัตโนมัติที่เป็นการละเมิด มันสามารถกรองความพยายามแบบ injection, บล็อกทราฟฟิกจากแหล่งที่มีประวัติการละเมิด และ challenge หรือทิ้งคำขอที่ดูเหมือนการ scraping หรือการโจมตี credential มันคือการป้องกันที่ดีที่สุดของคุณต่อทราฟฟิกที่ไม่ควรเข้าถึงโค้ดของคุณตั้งแต่แรก

API keys และ tokens

keys และ tokens ทำให้คุณตรวจสอบความรับผิดชอบได้ ทุกคำขอจะถูกจับคู่กับบัญชี คุณจึงรู้ว่า integration ใดเป็นผู้เรียก, สามารถเพิกถอนการเข้าถึงได้ และระบุการใช้งานได้ tokens แบบ scoped ยังไปต่อได้อีกขั้นและจำกัดว่าผู้เรียกทำอะไรได้บ้าง

Rate limits

rate limits ปกป้องความพร้อมใช้งาน มันป้องกันไม่ให้ integration หนึ่งใช้กำลังการประมวลผลที่ควรแบ่งให้ทุกคน และช่วยชะลอการโจมตีแบบ brute-force และ enumeration ขีดจำกัดแบบต่อ key และต่อ route เป็นการควบคุมมาตรฐานที่มีประสิทธิภาพ

เมื่อรวมกันแล้ว ชั้นเหล่านี้ตอบคำถามด้านการป้องกันและความรับผิดชอบได้ดีมาก จงเก็บไว้

คำถามที่ชั้นเหล่านี้ไม่ได้ถูกสร้างมาเพื่อตอบ

ไม่มีชั้นใดในนั้นถูกออกแบบมาเพื่อบอกคุณว่า actor แบบใด อยู่เบื้องหลังคำขอที่ยืนยันตัวตนแล้ว key ที่ถูกต้องบอกว่าบัญชีใดเป็นเจ้าของ integration แต่มันไม่ได้บอกว่า:

การเรียกเฉพาะครั้งนี้มาจากคนที่แตะปุ่มในแอปของลูกค้าคุณหรือไม่,
คนหนึ่งขอให้ AI assistant ดำเนินการแทนหรือไม่,
agent อัตโนมัติเป็นผู้เรียกในฐานะหนึ่งขั้นตอนของงานที่ยาวกว่า หรือไม่,
หรือไม่มีใครรู้ได้เลย

ความแตกต่างนี้สำคัญมากขึ้นทุกเดือน API ที่ให้บริการ integration ของ CRM, เครื่องมือจัดตารางงาน หรือแพลตฟอร์มนักพัฒนา จะได้รับทราฟฟิกของ agent ผ่าน key เดียวกันกับที่ใช้รองรับแอปที่ขับเคลื่อนโดยมนุษย์ หากคุณต้องการให้ agent ได้รับการตอบกลับแบบมีโครงสร้าง, ต้องการการยืนยันสำหรับการเขียนที่มีผลกระทบสูงซึ่งขับเคลื่อนโดย agent, ต้องการติดป้าย submissions ที่มี AI ช่วย, หรือเพียงต้องการวัดว่า API ของคุณถูกใช้งานโดย agent มากแค่ไหน คุณก็ต้องมีบริบทของ actor

สิ่งที่ Proof of Actor เพิ่มให้กับ API

Proof of Actor ส่งกลับหนึ่งในสี่ class สำหรับการโต้ตอบแต่ละครั้ง:

Human: สัญญาณที่สังเกตได้บ่งชี้ว่าเป็นการโต้ตอบที่ขับเคลื่อนโดยมนุษย์
Human + AI: บุคคลเป็นผู้กำกับการโต้ตอบโดยมีความช่วยเหลือจาก AI ซึ่งถูกประกาศไว้หรือสังเกตได้ผ่าน integration ที่รองรับ
Agent: การโต้ตอบที่มาจากระบบอัตโนมัติหรือ agent
Unknown: หลักฐานไม่เพียงพอที่จะสรุปได้อย่างน่าเชื่อถือ

ผลลัพธ์ทุกครั้งยังระบุ evidence basis ด้วย:

Verified: เช่น HTTP Message Signature (RFC 9421) ที่ตรวจสอบเทียบกับ key ที่เผยแพร่ไว้
Declared: client หรือแอปของคุณระบุไว้
Inferred: สัญญาณเชิงพฤติกรรมหรือเชิงบริบท ที่ระบุชัดว่าเป็นการอนุมาน
Unknown: ไม่มี basis ที่เชื่อถือได้

สำหรับ API แล้ว basis แบบ Verified มีประโยชน์มากเป็นพิเศษ agent ที่ลงนามในคำขอของตนสามารถตรวจสอบเทียบกับ key ที่เผยแพร่ไว้ได้ ซึ่งเป็นแนวทางเบื้องหลังงาน IETF Web Bot Auth อ่านคำอธิบายใน Web Bot Auth สำหรับทีมผลิตภัณฑ์ เพื่อดูพื้นหลัง และคู่มือ การยืนยันคำขอ agent ที่ลงนามแล้ว สำหรับด้านการนำไปใช้

มีข้อจำกัดหนึ่งที่สำคัญ ลายเซ็นที่ถูกต้องพิสูจน์ได้ว่า key ใดเป็นผู้ลงนามในคำขอ แต่มันไม่ได้พิสูจน์ว่า agent มีสิทธิ์ดำเนินการ การอนุญาตยังคงอยู่ใน access control ของ API ของคุณเอง รายการ agent authorization อธิบายความแตกต่างนี้

คะแนนและ key เทียบกับหลักฐานของ actor

ผลิตภัณฑ์ป้องกันบอตบางตัวแนบ score ให้กับแต่ละคำขอ score มีประสิทธิภาพสำหรับการตัดสินใจแบบ block แต่นำไปใช้กับการตัดสินใจด้านผลิตภัณฑ์ของ API ได้น้อยกว่า เพราะมันไม่ได้บอกว่าคำขอที่ถูกต้องตามสิทธิ์นั้นมาจากมนุษย์หรือ agent และไม่ได้แยกข้อเท็จจริงที่ยืนยันได้ออกจากการอนุมาน

API keys มีข้อจำกัดตรงข้ามกัน มันแม่นยำเรื่องความเป็นเจ้าของ แต่เงียบในเรื่อง actor key ของลูกค้าหนึ่งรายสามารถพาทั้งสี่ class ได้ภายในชั่วโมงเดียว

Proof of Actor ทำให้ทั้งสองความแตกต่างยังมองเห็นได้ API ของคุณจะเห็นบัญชีจาก key, เห็น actor class จาก Proof of Actor และเห็น basis ที่รองรับมัน แต่ละชั้นตอบคำถามที่มันถนัด

แต่ละส่วนทำงานที่ไหน

gateway และ WAF ทำงานที่ edge ของเครือข่ายของคุณหรืออยู่หน้าบริการของคุณ ตำแหน่งนั้นเหมาะสำหรับการป้องกันและโควตา

Proof of Actor ทำงานในที่ที่ตรรกะของ API ของคุณอยู่ ทีม Founding สามารถผสานผ่าน Node.js middleware, Next.js, edge layer ที่คุณควบคุม, generic HTTP API หรือ integration สำหรับ MCP server ดู integrations สำหรับรายการทั้งหมด เพราะมันทำงานภายในแอปพลิเคชันของคุณ จึงใช้สิ่งที่ API ของคุณรู้ได้: route, workflow, ว่าลูกค้าประกาศตัวเองหรือไม่ และว่าลายเซ็นตรวจสอบผ่านหรือไม่

การตัดสินใจเรื่อง routing อยู่ในโค้ดของคุณ

Proof of Actor ไม่บล็อกอะไรโดยค่าเริ่มต้น มันเริ่มใน observation mode ดังนั้นการติดตั้งจึงไม่เปลี่ยนวิธีที่ API ของคุณตอบสนอง คุณจะเห็นสัดส่วนของ actor ตาม endpoint, ตรวจสอบหลักฐานของผลลัพธ์รายรายการ และเฝ้าดูอัตรา Unknown

เมื่อคุณพร้อม คุณเขียน policy ที่นิยามโดยแอปพลิเคชันแยกตาม route, actor class และ basis ผลลัพธ์ที่ใช้กันทั่วไปคือ:

Allow: ให้บริการคำขอตามปกติ
Adapt: ส่งคืน response ที่มีโครงสร้างหรือถูกลดทอนสำหรับ verified agent
Challenge: ต้องมีขั้นตอนยืนยันเพิ่ม เช่น ให้มนุษย์อนุมัติการเขียนที่มีผลกระทบสูง
Review: เข้าคิวการกระทำเพื่อให้คนตรวจสอบ
Rate-limit: ใช้ขีดจำกัดที่เข้มกว่าให้กับ class และ basis เฉพาะบน route เฉพาะ

คุณสามารถ preview policy กับทราฟฟิกจริงก่อนบังคับใช้ แล้วค่อยบังคับใช้ทีละ route คู่มือเรื่อง การนำ policy ที่รับรู้ actor ไปใช้จริงอย่างปลอดภัย ครอบคลุมกระบวนการ และ การปกป้องการกระทำที่มีความอ่อนไหวโดยไม่บล็อก agent แสดงรูปแบบที่ใช้บ่อย

การจัดการ API callers ที่เป็น Unknown

ทุก API ได้รับทราฟฟิกที่ไม่สามารถจำแนกได้อย่างมั่นใจ ด้วยการควบคุมแบบดั้งเดิม key ที่ใช้ได้มักหมายความว่าคำขอผ่าน และ key ที่ใช้ไม่ได้หมายความว่าคำขอไม่ผ่าน ไม่มีอะไรอยู่ระหว่างกลาง

Proof of Actor ให้ผลลัพธ์ Unknown อย่างชัดเจน และให้คุณเลือก fallback แยกตาม route ได้ endpoint แคตตาล็อกแบบอ่านอย่างเดียวอาจเปิดไว้ได้ การเปลี่ยนข้อมูลบัญชีอาจคงการตรวจที่เข้มงวดแบบเดิมไว้ การส่งออกข้อมูลจำนวนมากอาจส่งไป review ดู การจัดการทราฟฟิก Unknown และ ทราฟฟิกอัตโนมัติที่ไม่ทราบที่มา สำหรับรายละเอียด

วิธีที่ทั้งหมดทำงานร่วมกัน

การตั้งค่า API ที่แข็งแรงที่สุดจะใช้แต่ละชั้นในงานของตัวเอง:

ที่ edge WAF กรองทราฟฟิกที่เป็นการละเมิดและรูปแบบที่ผิดปกติ
ที่ gateway key ถูกยืนยันตัวตน, บังคับใช้โควตา และบันทึกการใช้งาน
ภายใน API Proof of Actor จำแนกคำขอแต่ละรายการที่ผ่านเข้ามาและระบุ basis ของมัน
ใน handler ของคุณ policy ใช้ class และ basis เพื่อเลือกการตอบสนอง: จัดการตามปกติสำหรับการเรียกที่ขับเคลื่อนโดยมนุษย์, response ที่มีโครงสร้างสำหรับ verified agent, ขั้นตอนยืนยันสำหรับการเขียนที่มีผลกระทบสูงซึ่งขับเคลื่อนโดย agent, หรือ fallback สำหรับ Unknown
ในการวิเคราะห์ข้อมูล ทีมของคุณจะเห็นว่า endpoint และ workflow ใดถูกใช้โดย actor class ใด พร้อมกับข้อมูลบัญชีจาก gateway

ไม่มีส่วนใดในสแตกนี้ซ้ำซ้อน gateway รู้จักบัญชี, WAF รู้จักรูปแบบภัยคุกคาม, และ Proof of Actor รู้จัก actor

ควรให้ความสำคัญกับอะไรเมื่อใด

ให้ความสำคัญกับ การป้องกันบอตสำหรับ API ก่อน เมื่อปัญหาหลักของคุณคือการละเมิด, ความพร้อมใช้งาน หรือการใช้งานที่ไม่ถูกคิดค่า: การโจมตี credential ต่อ auth endpoint, การ scraping ที่ดุดัน, หรือ integration หนึ่งที่ดึงทรัพยากรจนอีกหลายตัวช้าลง

ให้ความสำคัญกับ Proof of Actor เมื่อคำถามหลักของคุณเกี่ยวกับผู้เรียกคือ: ทราฟฟิก API ของคุณมีสัดส่วนที่ขับเคลื่อนโดย agent มากแค่ไหน, agent ใดเรียก endpoint ใด, การใช้งานที่ขับเคลื่อนโดยมนุษย์กับโดย agent ต่างกันตรงไหน, และ route ใดต้องมี policy ที่รับรู้ actor หน้า APIs use case และ AI agent identification for APIs มีรายละเอียดลึกกว่านี้

ทีมส่วนใหญ่ที่รัน API บน production ต้องการคำตอบทั้งสองแบบ

เริ่มต้นใช้งาน

Proof of Actor อยู่ใน private beta ทีม Founding Developer ที่ได้รับเลือกสามารถรับสิทธิ์ใช้งานฟรีได้นานสูงสุด 12 เดือนภายใต้ขอบเขตการใช้งานที่ตกลงกัน โดยไม่มีการเรียกเก็บเงินอัตโนมัติ สมัครขอสิทธิ์เข้าถึงก่อนใคร และบอกเราว่า API และผู้เรียกที่คุณอยากทำความเข้าใจคืออะไร

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

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

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

Proof of Actor แทน API gateway หรือ WAF ของฉันหรือไม่?

ไม่ใช่ gateway ของคุณยังคงยืนยันตัวตนของ key และบังคับใช้โควตา ส่วน WAF ของคุณก็ยังกรองทราฟฟิกที่เป็นการละเมิด Proof of Actor ทำงานภายใน API ของคุณและเพิ่มบริบทของ actor ให้กับคำขอที่ผ่านเข้ามา จงใช้การควบคุมเดิมต่อไป.

ถ้าผู้เรียกทุกคนมี API key อยู่แล้ว ทำไมฉันยังต้องมีบริบทของ actor?

API key ระบุบัญชีที่เป็นเจ้าของการเชื่อมต่อ แต่ไม่ได้บอกว่าคำขอหนึ่งเกิดจากคนที่คลิกในแอปของลูกค้า, คนที่ใช้ AI assistant, หรือ agent อัตโนมัติที่กำลังทำงาน Proof of Actor จะรายงานสิ่งนั้นพร้อม basis ของมัน.

Proof of Actor ยืนยันได้หรือไม่ว่า agent ตัวไหนกำลังเรียก API ของฉัน?

เมื่อ client ลงนามคำขอด้วย HTTP Message Signatures (RFC 9421) และเผยแพร่ key ของตน Proof of Actor จะตรวจสอบลายเซ็นและรายงานว่า basis เป็น Verified ลายเซ็นที่ถูกต้องพิสูจน์ได้ว่า key ใดเป็นผู้ลงนามในคำขอ แต่ไม่ได้พิสูจน์ว่า agent นั้นมีสิทธิ์ดำเนินการ ดังนั้นการอนุญาตจึงยังอยู่ในโค้ดของคุณ.

Proof of Actor จะเริ่ม rate-limiting หรือบล็อกราฟฟิกของ API ของฉันหรือไม่?

ไม่ มันเริ่มต้นในโหมด observation และไม่บล็อกอะไรโดยค่าเริ่มต้น rate-limit เป็นหนึ่งในผลลัพธ์ที่คุณเลือกได้ใน policy แยกตาม route, actor class และ basis และการบังคับใช้อยู่ในโค้ดของคุณเอง.

ฉันจะเพิ่ม Proof of Actor เข้าไปใน API ได้อย่างไร?

ทีม Founding สามารถใช้ Node.js middleware, Next.js, edge integration หรือ generic HTTP API ได้ ส่วน MCP server มี integration ของตัวเอง ดูรายละเอียดได้ที่หน้า integrations.

จะเกิดอะไรขึ้นกับผู้เรียกที่คุณไม่สามารถจำแนกได้?

ระบบจะรายงานเป็น Unknown ซึ่งเป็นผลลัพธ์ระดับแรก คุณเป็นผู้เลือก fallback สำหรับแต่ละ route เช่น allow บน endpoint แบบอ่านอย่างเดียว และคงการตรวจที่เข้มงวดไว้บน write endpoint.

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

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

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

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