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

Proof of Actor เทียบกับ allowlist ของ user agent: ชื่อคือคำกล่าวอ้าง ไม่ใช่หลักฐาน

การ allowlist ด้วยสตริง User-Agent ตั้งค่าได้เร็วและเข้าใจได้ง่าย แต่ก็หลอกได้ง่ายเช่นกัน เพราะ header คือสิ่งที่ไคลเอนต์เลือกส่งมาเอง นี่คือสิ่งที่ allowlist ของ user agent บอกคุณจริงๆ ว่าอะไรได้บ้าง network check ช่วยตรงไหน และ Proof of Actor แยกแยะคำประกาศออกจากหลักฐานที่ยืนยันแล้วอย่างไร

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

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

คำตอบสั้น

allowlist ของ user agent เชื่อชื่อที่ไคลเอนต์ใส่มาใน User-Agent header และไคลเอนต์ใดก็พิมพ์ชื่อใดก็ได้ reverse DNS และช่วง IP ที่เผยแพร่ช่วยเพิ่มหลักฐานจริงสำหรับบางผู้ให้บริการ แต่ใช้ได้เฉพาะรายที่เผยแพร่ข้อมูลเหล่านั้นเท่านั้น Proof of Actor มอง header เป็นคำประกาศ ตรวจสอบลายเซ็นในจุดที่เอเจนต์ลงนามในคำขอของตน และรายงาน Unknown เมื่อหลักฐานยังบางพอที่จะสรุปไม่ได้ เพื่อให้โค้ดของคุณตัดสินใจโดยเห็นข้อเท็จจริงครบถ้วน

allowlist ของ user agent เป็นหนึ่งในแพตเทิร์นที่เก่าแก่ที่สุดบนเว็บ คุณเก็บรายชื่อ crawler และชื่อไคลเอนต์ที่คุณเชื่อถือไว้ เมื่อมีคำขอเข้ามาพร้อม User-Agent header ที่ตรงกัน คุณก็ปล่อยผ่าน ข้าม challenge หรือเสิร์ฟหน้าเวอร์ชันเบากว่า การตั้งค่านี้ใช้เวลาเพียงไม่กี่นาที และทุกคนในทีมเข้าใจได้ทันที

แพตเทิร์นนี้มีเหตุผลมากกว่าเดิมในยุคที่ผู้เยี่ยมชมอัตโนมัติหลักๆ มีเพียง search crawler ไม่กี่ตัวกับเครื่องมือมอนิเตอร์ไม่กี่ชุด แต่ปัจจุบัน เอเจนต์ AI ผู้ช่วย และไคลเอนต์อัตโนมัติเข้าถึงแอปพลิเคชันเพิ่มขึ้นอย่างต่อเนื่อง และหลายตัวก็ประกาศชื่อของตัวเอง บางชื่อเป็นของจริง บางชื่อถูกคัดลอกมา header ไม่สามารถบอกคุณได้ว่าอันไหน

Proof of Actor ใช้วิธีต่างออกไป มันมองสตริง User-Agent ว่าเป็นสิ่งที่มันเป็นจริงๆ คือคำประกาศ และแสดงมันเคียงกับหลักฐานที่แข็งแรงกว่าเมื่อมีหลักฐานนั้นอยู่ หน้านี้อธิบายข้อจำกัดของการ allowlist ตามชื่อ จุดที่ network-level check ช่วยได้ และลายเซ็นที่ตรวจสอบแล้วกับคลาส Unknown ที่ชัดเจนเปลี่ยนภาพรวมอย่างไร

สรุปสั้นๆ

	allowlist ของ user agent	Proof of Actor
หลักฐานหลัก	ชื่อใน User-Agent header	ลายเซ็น คำประกาศ และสัญญาณ โดยแต่ละอย่างมี basis กำกับ
ไคลเอนต์ปลอมได้ไหม	ได้ โดยส่งสตริงเดียวกัน	declared basis อ้างได้ แต่ verified basis ต้องมีคีย์ที่ใช้ลงนาม
ผลลัพธ์	อยู่ใน list หรือไม่	Human, Human + AI, Agent หรือ Unknown พร้อม basis
traffic ที่ไม่ชัดเจน	ถือว่าไม่อยู่ใน allowlist หรืออนุญาตโดยค่าเริ่มต้น	Unknown พร้อม fallback ที่คุณเลือกตาม route
คนที่ใช้ AI ช่วย	มองไม่เห็น ใช้เบราว์เซอร์ทั่วไป	เป็นคลาสที่แยกต่างหาก คือ Human + AI เมื่อมีการประกาศหรือสังเกตได้
การดูแลรักษา	ต้องอัปเดตรายชื่อเองเมื่อชื่อเปลี่ยน	คีย์ที่ผู้ดูแลเอเจนต์เผยแพร่ และนโยบายอยู่ในโค้ดของคุณ
ค่าเริ่มต้นตอนติดตั้ง	อะไรก็ตามที่ list อนุญาต	Observation ไม่มีอะไรเปลี่ยนจนกว่าคุณจะเพิ่ม policy
เหมาะที่สุดสำหรับ	routing ต้นทุนต่ำของไคลเอนต์ที่รู้จักและทำงานตามปกติ	บริบทของ actor แบบอิงหลักฐานสำหรับการตัดสินใจด้านผลิตภัณฑ์และนโยบาย

ส่วนที่เหลือของหน้านี้จะอธิบายแต่ละแถว

ทำไมการ allowlist ด้วย User-Agent จึงปลอมแปลงได้

User-Agent header ถูกกำหนดโดยไคลเอนต์ เบราว์เซอร์ตั้งค่า สคริปต์ตั้งค่า และเฟรมเวิร์กของเอเจนต์ก็ตั้งค่า ไม่มีอะไรใน HTTP ที่ตรวจว่าค่านั้นจริงหรือไม่ ถ้า allowlist ของคุณเชื่อสตริงนี้ ใครก็ตามที่คัดลอกสตริงนั้นได้ก็จะได้รับการปฏิบัติแบบเดียวกัน

สิ่งนี้เรียกว่า user agent spoofing และพบได้บ่อยด้วยเหตุผลง่ายๆ คือมันแทบไม่ต้องเสียอะไรเลย scraper ที่อยากหลีกเลี่ยง challenge แค่ยืมชื่อของ crawler ที่คุณเชื่อถือ ไคลเอนต์ที่ทำงานผิดปกติอาจอ้างว่าเป็นผู้ช่วยยอดนิยม เครื่องมือที่ถูกต้องตามกฎหมายก็อาจส่งสตริงเบราว์เซอร์ทั่วไปเพราะค่าเริ่มต้นของไลบรารีเป็นเช่นนั้น

ผลลัพธ์คือ allowlist ของ user agent มีโหมดล้มเหลวสองแบบ:

เชื่อผิด: ไคลเอนต์ที่ไม่น่าเชื่อถืออ้างชื่อที่เชื่อถือได้และผ่านไป
สงสัยผิด: ไคลเอนต์ที่ถูกต้องส่งสตริงที่ไม่คาดคิดหรือทั่วไปเกินไปและไม่ผ่าน

header เพียงอย่างเดียวมองไม่เห็นความล้มเหลวทั้งสองแบบ นั่นคือข้อจำกัดหลัก และการดูแลรายการให้ดีขึ้นเท่าไรก็ไม่ลบข้อจำกัดนี้ออกไป

ทั้งหมดนี้ไม่ได้หมายความว่าคุณควรเพิกเฉยต่อสตริง User-Agent crawler และเอเจนต์ที่ทำงานตามปกติจะประกาศตัวเองอย่างซื่อสัตย์ และชื่อนั้นเป็นสัญญาณที่มีประโยชน์สำหรับ routing การวิเคราะห์ และการแก้ไขปัญหา มันบอกคุณว่าไคลเอนต์บอกว่าตัวเองคืออะไร

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

reverse DNS และรายการ IP: มาตรการบางส่วน

หลายทีมเพิ่มความแข็งแรงให้ allowlist ด้วย network check ซึ่งช่วยได้ และควรเข้าใจให้ชัดเจน

การยืนยัน reverse DNS

ผู้ให้บริการ crawler บางรายอธิบายกระบวนการยืนยันไว้: ค้นหา hostname สำหรับ IP address ของคำขอ ตรวจว่าเป็นโดเมนของผู้ให้บริการนั้น แล้วค้นหา hostname นั้นและยืนยันว่ามัน resolve กลับไปยัง IP เดิม หากการไปกลับนี้สำเร็จ คุณจะมีหลักฐานจริงว่าคำขอมาจากโครงสร้างพื้นฐานของผู้ให้บริการนั้น

ข้อจำกัดคือใช้ได้ในทางปฏิบัติเท่านั้นกับผู้ให้บริการที่อธิบายและรองรับวิธีนี้ มันเพิ่ม DNS lookup ที่คุณต้องแคช และมันบอกคุณเรื่องเครือข่าย ไม่ได้บอกว่า product หรือเอเจนต์ใดเป็นผู้ส่งคำขอบนเครือข่ายนั้น

ช่วง IP ที่เผยแพร่

ผู้ให้บริการบางรายเผยแพร่ช่วง IP ที่ไคลเอนต์อัตโนมัติของตนใช้ การจับคู่คำขอกับช่วงเหล่านั้นทำได้รวดเร็วและให้หลักฐานคล้าย reverse DNS ยังมีการหารือของ IETF อย่างต่อเนื่องเกี่ยวกับรูปแบบมาตรฐานสำหรับการเผยแพร่ช่วงเหล่านี้ แต่ ณ เดือนพฤศจิกายน 2026 ยังไม่มีมาตรฐานที่ลงตัว และความครอบคลุมขึ้นอยู่กับว่าผู้ให้บริการแต่ละรายเลือกเผยแพร่หรือไม่

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

network check รวมกันให้ผลอะไร

reverse DNS และรายการ IP เปลี่ยนคำประกาศบางส่วนให้กลายเป็นสิ่งที่แข็งแรงกว่า สำหรับกลุ่มผู้ให้บริการที่รู้จักบางราย มันไม่ครอบคลุมหางยาวของเอเจนต์และเครื่องมือทั้งหมด และไม่ช่วยอะไรกับคนที่ทำงานร่วมกับ AI เลย มันเป็นมาตรการบางส่วน: ควรใช้ แต่ยังไม่พอด้วยตัวเอง

ลายเซ็นเทียบกับคำประกาศ

หลักฐานที่แข็งแรงกว่าคือลายเซ็นเข้ารหัส ด้วย HTTP Message Signatures ซึ่งกำหนดไว้ใน RFC 9421 ไคลเอนต์จะลงนามส่วนที่เลือกของแต่ละคำขอด้วย private key ผู้ตรวจสอบดึง public key ที่ผู้ให้บริการเผยแพร่มา และตรวจสอบลายเซ็น หากตรวจผ่าน คำขอนั้นถูกลงนามโดยผู้ถือคีย์นั้น และส่วนที่ลงนามไม่ได้ถูกแก้ไขระหว่างทาง

working group Web Bot Auth ของ IETF กำลังทำให้วิธีที่ไคลเอนต์อัตโนมัติใช้ลายเซ็นเหล่านี้และเผยแพร่คีย์ของตนเป็นมาตรฐาน คู่มือ Web Bot Auth สำหรับทีมผลิตภัณฑ์ ของเราอธิบายสถานะปัจจุบันไว้

Proof of Actor ใช้ลายเซ็นที่ถูกต้องเป็นหลักฐานแบบ Verified สตริง User-Agent client hint หรือคำอธิบายตัวเองใน body ของคำขอถือเป็น Declared สัญญาณด้านพฤติกรรมและบริบทถือเป็น Inferred และจะมีป้ายกำกับเช่นนั้น ทุกผลลัพธ์ระบุชัดว่าพึ่งพา basis ใด เพื่อให้ทีมของคุณไม่สับสนระหว่างคำกล่าวอ้างกับการตรวจสอบ ดูรายการ evidence basis สำหรับนิยามทั้งหมด

มีข้อจำกัดหนึ่งที่ใช้กับหลักฐานที่ verified ด้วย ลายเซ็นที่ถูกต้องพิสูจน์ได้ว่าใช้คีย์ใดลงนามในคำขอ แต่มันไม่ได้พิสูจน์ว่าเอเจนต์ได้รับอนุญาตให้ทำสิ่งที่กำลังขอ นั่นเป็นคำถามเรื่อง agent authorization และยังอยู่ในแอปพลิเคชันของคุณ

จัดการ Unknown แทนการเดา

allowlist บังคับให้ทุกคำขออยู่ในหนึ่งในสองกลุ่ม: อยู่ใน list หรือไม่อยู่ ในทางปฏิบัติ นั่นหมายความว่า traffic ที่ไม่ชัดเจนจะได้รับค่าเริ่มต้นของคุณ และค่าเริ่มต้นนั้นมักถูกกำหนดครั้งเดียวสำหรับทั้งเว็บไซต์

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

บนหน้าเอกสารสาธารณะหรือหน้า marketing ให้อนุญาต
บน search หรือ listing endpoint ให้อนุญาตพร้อม rate limit ปกติของคุณ
บนการเปลี่ยนแปลงบัญชี ให้ใช้การตรวจสอบเดิมของคุณ
บนการกระทำที่มีผลกระทบสูง ให้ส่งไป review หรือขอ signal ที่แข็งแรงกว่า

คู่มือ handling Unknown traffic และรายการ unknown classification จะอธิบายแพตเทิร์นเหล่านี้ การติดตามอัตรา Unknown ของคุณเมื่อเวลาผ่านไปยังบอกได้ด้วยว่ามี traffic เท่าไรที่ยังอาศัยหลักฐานอ่อนอยู่

แล้วคนที่ใช้ AI ช่วยล่ะ?

allowlist ของ user agent ไม่มีอะไรจะพูดเกี่ยวกับคนที่ใช้ผู้ช่วย AI ภายในเบราว์เซอร์ทั่วไปของตน User-Agent ของพวกเขาคือสตริงเบราว์เซอร์ปกติ แต่หลายผลิตภัณฑ์อยากรับรู้การโต้ตอบแบบนั้น เช่น เพื่อระบุว่าการส่งข้อมูลถูกร่างโดย AI หรือเข้าใจว่าผู้ใช้ที่มี AI ช่วยเคลื่อนผ่าน onboarding อย่างไร

Proof of Actor รายงานการโต้ตอบเหล่านี้เป็น Human + AI เมื่อมีการประกาศหรือสังเกตได้ผ่านการผสานรวมที่รองรับ มันไม่เดาจากรูปแบบการเขียนเพียงอย่างเดียว อ่านเพิ่มเติมใน AI-assisted interaction

เปลี่ยนจาก allowlist ไปสู่นโยบายที่อิงหลักฐาน

คุณไม่จำเป็นต้องลบ allowlist ทิ้งในวันแรก เส้นทางที่ปลอดภัยมีลักษณะดังนี้:

ติดตั้งในโหมด observation Proof of Actor ไม่เปลี่ยนอะไรเลย allowlist ของคุณยังทำงานต่อไป
เปรียบเทียบ สำหรับแต่ละ route ดูว่าคำขอที่อยู่ใน allowlist ใดมี verified evidence คำขอใดมีเพียงคำประกาศ และคำขอใดลงเอยเป็น Unknown
พรีวิว policy ร่าง policy ที่ปฏิบัติต่อ verified agents, declared agents และ Unknown แตกต่างกัน แล้วดูผลต่อ traffic จริงล่วงหน้า
บังคับใช้ทีละ route เริ่มจาก route ที่ชื่อปลอมจะสร้างผลกระทบมากที่สุด
คง allowlist ไว้เป็นสัญญาณ ชื่อยังคงมีประโยชน์สำหรับ routing และการวิเคราะห์ แต่ตอนนี้มองเห็น basis ของมันแล้ว

คู่มือ rolling out actor-aware policies safely ครอบคลุมแต่ละขั้นตอน และ verified automated requests อธิบายว่าไคลเอนต์ที่ลงนามแล้วเข้ากับระบบอย่างไร

เมื่อ allowlist ก็เพียงพอแล้ว

สำหรับการ routing ที่ความเสี่ยงต่ำ เช่น การเสิร์ฟหน้าเวอร์ชันเบาให้ crawler ที่รู้จักบนเนื้อหาสาธารณะ allowlist ของ user agent มักเพียงพอ ต้นทุนของชื่อที่ถูกปลอมแปลงมีน้อย

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

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

Proof of Actor อยู่ใน private beta ทีม founding developer ที่ได้รับเลือกสามารถรับสิทธิ์ใช้งานฟรีได้นานสูงสุด 12 เดือน ภายใต้ขอบเขตการใช้งานที่ตกลงร่วมกัน โดยไม่มีการเรียกเก็บเงินอัตโนมัติ สมัคร Apply for early access และบอกเราว่าตอนนี้คุณ allowlist ไคลเอนต์ใดอยู่บ้าง และ route ใดที่คุณต้องการปกป้องด้วยหลักฐานที่ดีกว่า

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

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

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

allowlist ของ user agent ไม่มีประโยชน์เลยหรือ?

ไม่ใช่ มันเป็นคำประกาศที่มีประโยชน์จากไคลเอนต์ที่ทำงานตามปกติ และเป็นวิธีต้นทุนต่ำในการ route crawler ที่รู้จัก ปัญหาคือการมองว่ามันเป็นหลักฐาน หากดูแค่ allowlist อย่างเดียว ไม่ควรปล่อยให้การกระทำที่อ่อนไหวผ่านได้

การยืนยัน reverse DNS ช่วยแก้ปัญหา user agent spoofing ได้ไหม?

ช่วยได้สำหรับผู้ให้บริการที่อธิบายกระบวนการนี้ไว้ การ reverse lookup แล้วตามด้วย forward lookup ที่ตรงกันจะผูก IP address เข้ากับโดเมนของผู้ให้บริการนั้น ใช้ได้เฉพาะกับผู้ให้บริการที่รองรับวิธีนี้ และไม่ได้บอกอะไรเกี่ยวกับ traffic จากที่อยู่ cloud ร่วมกันหรือที่อยู่ residential

Proof of Actor จัดการกับ User-Agent header อย่างไร?

มองว่าเป็นคำประกาศ มันเป็นส่วนหนึ่งของผลลัพธ์ในฐานะ declared basis ไม่ใช่ verified basis verified basis ต้องมีหลักฐาน เช่น HTTP Message Signature ที่ตรวจสอบกับคีย์ที่เผยแพร่แล้ว

ลายเซ็นที่ verified พิสูจน์อะไร?

พิสูจน์ได้ว่าใช้คีย์ใดลงนามในคำขอ และส่วนที่ลงนามไม่ได้ถูกเปลี่ยนแปลงระหว่างทาง แต่มันไม่ได้พิสูจน์ว่าเอเจนต์มีสิทธิ์ทำการกระทำนั้น การอนุญาตยังอยู่ในแอปพลิเคชันของคุณ

ถ้าไคลเอนต์อ้างว่าเป็นเอเจนต์ที่รู้จัก แต่ตรวจสอบไม่ได้จะเกิดอะไรขึ้น?

Proof of Actor จะแสดงสิ่งที่หลักฐานรองรับ ซึ่งมักเป็นผลลัพธ์แบบ declared หรือ inferred หรือ Unknown นโยบายของคุณจะเป็นตัวเลือก fallback สำหรับ route นั้น แทนที่จะเชื่อชื่อที่อ้างมา

การเพิ่ม Proof of Actor จะเปลี่ยนพฤติกรรม allowlist เดิมของฉันไหม?

ไม่ มันเริ่มในโหมด observation คุณสามารถเปรียบเทียบผลลัพธ์กับการตัดสินใจของ allowlist บน traffic จริงได้ก่อนจะเปลี่ยนอะไร

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

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

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

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