คำจำกัดความ
พื้นฐานของหลักฐานในผลลัพธ์ของ actor อธิบายชนิดของหลักฐานที่อยู่เบื้องหลัง Proof of Actor ใช้ค่า 4 ค่า:
- verified: มีการตรวจสอบเชิงเข้ารหัสหรือการตรวจสอบอื่นที่ยืนยันได้ และผ่านการตรวจสอบ
- declared: actor หรือ application ระบุไว้เอง
- inferred: สรุปจากสัญญาณด้านพฤติกรรมหรือบริบท
- unknown: มีหลักฐานไม่เพียงพอสำหรับการตัดสิน
แต่ละผลลัพธ์จะมีทั้ง class (Human, Human + AI, Agent หรือ Unknown ตามที่อธิบายใน taxonomie ของเราสำหรับทราฟฟิกของ application) และ basis อยู่ด้วย "Agent, verified" กับ "Agent, inferred" เป็นผลลัพธ์คนละแบบ และควรจัดการต่างกัน
ทำไม basis จึงสำคัญ
หากไม่มี basis การจัดประเภทจะซ่อนว่าน้ำหนักของผลลัพธ์นั้นรับภาระได้มากแค่ไหน dashboard ที่แสดง "Agent" สำหรับ request ที่ลงลายเซ็นแล้ว และ "Agent" สำหรับการคาดเดาจากเวลาในการ request จะชักนำให้ทีมใช้ policy เดียวกันกับทั้งสองกรณี โดยเฉพาะใน application ที่อ่อนไหวด้านความปลอดภัย inference ไม่ควรถูกมองเหมือนการยืนยันทางเข้ารหัส
การแยก class ออกจาก basis ช่วยให้ policy สอดคล้องกับความเข้มของหลักฐาน:
- route แบบอ่านอย่างเดียวอาจอนุญาตผลลัพธ์แบบ Agent ได้ทุกกรณี
- route ที่มีผลกระทบสูงกว่าอาจมองเฉพาะ agent ที่ verified ว่าเป็นผู้ปฏิบัติการที่ทราบแล้ว และกำหนดให้ทุกคนที่เหลือต้องมีข้อมูลรับรองที่เข้มงวดกว่า
รายละเอียดของทั้ง 4 ค่า
Verified
มีการตรวจสอบแล้วและผ่าน ตัวอย่างที่ชัดที่สุดคือ HTTP message signature (RFC 9421) ที่ตรวจสอบได้กับ key ซึ่งเผยแพร่โดยผู้ดำเนินการของ agent หลักฐานแบบ verified พิสูจน์เฉพาะการตรวจนั้น และไม่มากไปกว่านั้น: signature ที่ถูกต้องบอกได้ว่า key ใดเป็นผู้ลงนาม request แต่ไม่ได้บอกว่าการกระทำนั้น authorized
Declared
มีการระบุไว้เอง client ที่ระบุตัวเองว่าเป็น agent, ชื่อของ MCP client หรือการเปิดเผยการช่วยงานของ AI ภายใน application ของคุณเอง ล้วนเป็นการประกาศ ข้อมูลเหล่านี้มีประโยชน์ มักจะตรงจริง และบางครั้งก็ไม่จริง user-agent spoofing เป็นตัวอย่างคลาสสิกของการประกาศที่ไม่จริง ส่วนหัว User-Agent ถูกออกแบบให้เป็นการรายงานด้วยตนเอง
Inferred
ระบบใช้เหตุผลจากสัญญาณต่างๆ: รูปแบบการโต้ตอบใน browser session, เวลาในการ request, การขาด context ของ browser, รายละเอียดของ protocol การอนุมานอาจผิดได้ นั่นคือเหตุผลที่ต้องติดป้ายกำกับว่าเป็น inference เสมอ และเหตุใดการตัดสินใจที่มีผลต่อคนจึงไม่ควรอาศัยสิ่งนี้เพียงอย่างเดียว
Unknown
หลักฐานไม่เพียงพอสำหรับการตัดสิน สถานะนี้สอดคล้องกับ Unknown classification และควรถูกแมปไปยัง fallback ที่ชัดเจนใน policy ของคุณ บทความของเราเรื่อง ทำไม Unknown จึงเป็นผลลัพธ์ที่ถูกต้องเมื่อจัดประเภททราฟฟิกของ AI อธิบายเหตุผลไว้
Basis เทียบกับคะแนนความเชื่อมั่น
หลายระบบย่อหลักฐานให้เหลือเพียงตัวเลขเดียว คะแนนจะซ่อนว่ามันมาจากการตรวจแบบเข้ารหัสหรือจาก heuristic และเปอร์เซ็นต์ที่ไม่ได้ปรับเทียบจะสื่อถึงความแม่นยำที่ไม่มีอยู่จริง ชุด basis ที่มีชื่อเรียกชัดเจนไม่กี่แบบจะทำให้เข้าใจเหตุผลได้ง่ายกว่า ตรวจสอบได้ง่ายกว่า และนำไปใช้ผิดได้ยากกว่า
ความเข้าใจผิดที่พบบ่อย
"Declared แปลว่าน่าเชื่อถือไม่ได้" การประกาศมักถูกต้อง และในบางคำถาม เช่น การเปิดเผยการช่วยงานของ AI ก็เป็นหลักฐานเพียงอย่างเดียวที่มีอยู่ เพียงแต่ไม่ควรถูกนำไปปฏิบัติราวกับเป็นการยืนยัน
"Verified แปลว่าปลอดภัย" การยืนยันเกี่ยวกับตัวตนของผู้ลงนาม ไม่ใช่เจตนาหรือสิทธิ์อนุญาต
พื้นฐานของหลักฐานใน Proof of Actor
ทุกผลลัพธ์ของ Proof of Actor จะระบุ basis ของตัวเองพร้อมสรุปหลักฐานที่มนุษย์อ่านเข้าใจได้ policy ทำงานใน application ของคุณ และสามารถใช้ทั้ง class และ basis ร่วมกันได้ ดู Detection & Limitations หรือ สมัครเพื่อเข้าถึงก่อนใคร
แหล่งที่มา
- RFC 9421: HTTP Message Signatures: แหล่งอ้างอิงที่ชัดที่สุดสำหรับหลักฐานแบบ verified
- RFC 9110: HTTP Semantics, User-Agent: ตัวระบุที่รายงานด้วยตนเองและเป็น declared