ข้ามไปยังเนื้อหาหลัก
ระบบอัตโนมัติที่ยืนยันแล้ว

ระบุคำขออัตโนมัติที่ยืนยันแล้ว

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

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

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

ไม่ใช่ทราฟฟิกอัตโนมัติทุกแบบที่จะเหมือนกัน

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

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

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

การลงนามในคำขอทำงานอย่างไร

แนวทางที่กำลังเกิดขึ้นสำหรับทราฟฟิกอัตโนมัติใช้ HTTP message signatures ซึ่งกำหนดมาตรฐานไว้ใน RFC 9421 โดยนิยามวิธีสร้าง เข้ารหัส และตรวจสอบลายเซ็นเหนือองค์ประกอบต่างๆ ของข้อความ HTTP ไคลเอนต์จะลงนามในส่วนที่เลือกของแต่ละคำขอด้วยคีย์ส่วนตัว และใส่ลายเซ็นพร้อมพารามิเตอร์ไว้ในส่วนหัว จากนั้นจึงเผยแพร่คีย์สาธารณะที่สอดคล้องกัน ณ ตำแหน่งที่เชื่อมกับตัวระบุที่ตนควบคุม ซึ่งโดยทั่วไปคือโดเมนของตน

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

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

ลายเซ็นที่ยืนยันแล้วพิสูจน์อะไร และไม่พิสูจน์อะไร

ความแตกต่างนี้คือส่วนที่สำคัญที่สุดของการจัดการคำขออัตโนมัติที่ยืนยันแล้วให้ดี

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

ลายเซ็นที่ถูกต้อง ไม่ได้พิสูจน์:

  • ว่าใครเป็นผู้สั่งเอเจนต์ หรือมีบุคคลใดร้องขอการกระทำนี้หรือไม่;
  • ว่ามีบุคคลมอบอำนาจให้เอเจนต์หรือไม่;
  • ตัวตนตามกฎหมายในโลกจริงที่อยู่เบื้องหลังผู้ดำเนินการ;
  • ว่าการกระทำที่ร้องขอนั้นปลอดภัยหรือได้รับอนุญาตในแอปพลิเคชันของคุณ

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

Proof of Actor จัดการคำขออัตโนมัติที่ยืนยันแล้วอย่างไร

Detect

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

Understand

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

Route

ใช้ฐานข้อมูลนั้นในนโยบายของคุณ รูปแบบที่ใช้บ่อยได้แก่:

  • มอบการตอบกลับที่มีโครงสร้างให้เอเจนต์ที่ยืนยันแล้วบนเส้นทางอ่านอย่างเดียว เช่น API หรือหน้าในรูปแบบ Markdown
  • เพิ่ม rate limit สำหรับโอเปอเรเตอร์ที่ยืนยันแล้วและคุณรู้จัก ขณะที่คงขีดจำกัดมาตรฐานไว้สำหรับไคลเอนต์ที่ประกาศแล้ว
  • ใช้การอนุญาตเดิมของคุณกับทุกเส้นทางเขียน ไม่ว่าลายเซ็นจะบอกอะไร
  • กำหนดทางเลือกสำรองที่ชัดเจนสำหรับผู้เรียกใช้งานที่ไม่ได้ลงนามและ Unknown ในแต่ละเส้นทาง

นโยบายเป็นผู้ตัดสินใจ Proof of Actor เป็นผู้จัดหาหลักฐานให้

ทำไมส่วนหัว user-agent จึงไม่พอ

สตริง user-agent คือการประกาศ ใครก็ส่งค่าใดก็ได้ และ user-agent spoofing ก็ไม่ต้องใช้ทักษะมาก นั่นจึงเป็นเหตุผลที่ผู้ดำเนินการครอว์เลอร์เผยแพร่การตรวจสอบของตนเอง Google อธิบายการค้นหา reverse และ forward DNS รวมถึงช่วง IP ที่เผยแพร่ไว้สำหรับ การยืนยัน Googlebot Bing อธิบายการตรวจสอบ DNS สำหรับ การยืนยัน Bingbot และ OpenAI เผยแพร่ไฟล์ช่วง IP สำหรับ crawler และ user agents ของตนแต่ละตัว Proof of Actor มองการอ้าง user-agent เป็นหลักฐานแบบประกาศ ไม่เคยถือว่าเป็นการยืนยัน นั่นหมายความว่าไคลเอนต์ที่อ้างว่าเป็นครอว์เลอร์ที่มีชื่อเสียงแต่ไม่มีลายเซ็นที่ถูกต้อง จะถูกรายงานด้วยฐานข้อมูลแบบประกาศแล้วหรืออนุมาน และนโยบายของคุณสามารถปฏิบัติต่อมันต่างจากไคลเอนต์ที่พิสูจน์ตัวตนแล้วได้

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

หลักฐานตัวตน ข้อมูลรับรอง และการอนุญาต

ในแอปพลิเคชันใดก็ตามที่ให้บริการไคลเอนต์อัตโนมัติ มีสามชั้นที่ทำงานร่วมกัน:

  1. หลักฐานตัวตน: คำขอนี้ใครเป็นผู้ลงนาม คำตอบนี้มาจากลายเซ็นที่ยืนยันแล้ว
  2. ข้อมูลรับรอง: บัญชีใดเป็นผู้รับผิดชอบ คำตอบนี้มาจาก API key, token หรือ session ของคุณ
  3. การอนุญาต: ผู้เรียกใช้งานรายนี้ทำสิ่งนี้ได้หรือไม่ คำตอบนี้มาจากโมเดลสิทธิ์ของคุณ

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

เหมาะกับตรงไหน

Proof of Actor วางตัวอยู่ข้างเกตเวย์ การยืนยันตัวตน และการจำกัดอัตรา การผสานใช้งานทำงานเป็น middleware ฝั่งเซิร์ฟเวอร์ ที่ edge ใน MCP server ของคุณ หรือผ่านการผสาน HTTP แบบทั่วไป โดยเราจะช่วยลงรายละเอียดร่วมกับแต่ละทีมผู้ก่อตั้ง หากทราฟฟิกของคุณส่วนใหญ่เป็น APIs และเครื่องมือ กรณีการใช้งาน APIs และ MCP Servers จะแสดงรูปแบบที่สำคัญที่สุด

เริ่มในโหมดสังเกตการณ์

การผสานใช้งานทุกครั้งเริ่มในโหมดสังเกตการณ์ ผลลัพธ์จะถูกบันทึกไว้โดยไม่เปลี่ยนวิธีที่แอปพลิเคชันของคุณตอบสนอง เพื่อให้คุณเห็นว่าทราฟฟิกอัตโนมัติของคุณส่วนใดที่ยืนยันแล้ว โอเปอเรเตอร์รายใดกำลังลงนาม และอัตรา Unknown สูงที่สุดที่ไหน นโยบายจะตามมาในภายหลัง ทีละเส้นทาง เมื่อหลักฐานรองรับ How It Works จะอธิบายโฟลว์ทั้งหมด

รายละเอียดเชิงปฏิบัติที่ทำให้การยืนยันเชื่อถือได้

การตรวจสอบลายเซ็นจะดีได้เท่ากับรายละเอียดรอบข้างไม่มากกว่านั้น แนวปฏิบัติไม่กี่ข้อทำให้คำขออัตโนมัติที่ยืนยันแล้วเชื่อถือได้ในการใช้งานจริง

ตรวจสอบความใหม่

RFC 9421 กำหนดพารามิเตอร์ลายเซ็น created และ expires และคำขอที่ลงนามมักจะมีสิ่งเหล่านี้ Reject ลายเซ็นที่อยู่นอกช่วงเวลาสั้นๆ เพื่อไม่ให้คำขอที่ถูกดักจับไปถูกนำมาใช้ซ้ำภายหลัง

แคชคีย์อย่างเหมาะสม

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

ลงนามในส่วนที่ถูกต้องของคำขอ

ลายเซ็นที่ครอบคลุมแค่เวลาเพียงอย่างเดียวพิสูจน์อะไรได้น้อยมาก ตรวจให้แน่ใจว่าส่วนประกอบที่ถูกลงนามรวม method, path และ host เพื่อให้ลายเซ็นผูกกับคำขอที่แอปพลิเคชันของคุณได้รับจริง

บันทึกหลักฐานไว้

เก็บ key identifier, ตัวระบุที่เผยแพร่ และผลลัพธ์ไว้กับคำขอที่ยืนยันแล้วแต่ละรายการ เมื่อมีเรื่องผิดปกติเกิดขึ้น ทีมของคุณจะเห็นได้ชัดเจนว่าไคลเอนต์ใดลงนามอะไรและเมื่อใด

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

เข้าร่วมโครงการนักพัฒนาผู้ก่อตั้ง

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

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

แหล่งที่มา

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

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 ยังจัดประเภทได้ โดยใช้หลักฐานแบบ declared และ inferred เมื่อมีข้อมูลเพียงพอ และรายงาน Unknown เมื่อหลักฐานยังไม่มากพอ ทุกผลลัพธ์จะระบุฐานของตนไว้

สตริง user-agent ใช้ยืนยันไคลเอนต์ได้ไหม?

ไม่ได้ สตริง user-agent ปลอมแปลงได้ง่าย จึงนับเป็นการประกาศ ไม่ใช่การยืนยัน สิ่งที่ทำให้คำขอสามารถตรวจสอบได้คือลายเซ็นเข้ารหัส

ฉันจะเริ่มอย่างไร?

สมัครขอเข้าถึงก่อน ทีมผู้ก่อตั้งจะเริ่มในโหมดสังเกตการณ์ และทีมที่ได้รับคัดเลือกสามารถรับสิทธิ์ใช้งานฟรีได้นานสูงสุด 12 months ภายใต้ขอบเขตการใช้งานที่ตกลงกันไว้

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

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

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

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