ข้ามไปยังเนื้อหาหลัก
วิธีการทำงาน

Proof of Actor ทำงานอย่างไร

เส้นทางแบบยึดหลักฐานเป็นอันดับแรก ตั้งแต่การโต้ตอบที่เข้ามาจนถึงการตัดสินใจของแอปพลิเคชัน

สมัครขอ Early Accessดู Detection & Limits
policy · example-app.test
  • /api/v1/catalogenforceเอเจนต์อนุญาต · API แบบมีโครงสร้าง
  • /support/ticketsenforceมนุษย์ + AIอนุญาต · ติดป้ายว่าใช้ Human + AI
  • /account/*previewไม่ทราบคงการตรวจสอบเดิมไว้
  • /api/v1/orderspreviewเอเจนต์ต้องใช้ข้อมูลยืนยันตัวตนที่เข้มงวดกว่า

จาก interaction สู่การตัดสินใจ

  1. 01คำขอหรือเหตุการณ์ของแอปพลิเคชันการดูหน้าเว็บ, การเรียก API, การเรียกเครื่องมือ MCP หรือการกระทำภายในแอป
  2. 02สัญญาณจากการเชื่อมต่อที่รองรับเฉพาะสิ่งที่การผสานรวมนั้นสังเกตได้ในบริบทนั้น
  3. 03การทำให้หลักฐานเป็นมาตรฐานและการจำแนกประเภทสัญญาณถูกตรวจสอบ ติดป้ายกำกับตามฐาน และรวมเข้าด้วยกัน
  4. 04ผลลัพธ์ของตัวกระทำพร้อมฐานข้อมูลและความไม่แน่นอนHuman, Human + AI, Agent หรือ Unknown พร้อมทั้งสิ่งที่เป็นฐานรองรับ
  5. 05dashboard และ analyticsแนวโน้ม route และหลักฐานสำหรับทีมของคุณใช้พิจารณา
  6. 06การตัดสินใจของแอปพลิเคชันคุณเองสังเกตเท่านั้น หรือใช้นโยบายที่คุณเลือกไว้
สำหรับนักพัฒนา

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

โหมด observation เป็นค่าเริ่มต้น

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

ประเภทของหลักฐาน

หลักฐานที่มีอยู่ขึ้นอยู่กับ integration และบริบท การตรวจสอบของแต่ละ workflow จะตกลงร่วมกับทีมระหว่าง onboarding และรายละเอียดภายในของสัญญาณจะถูกเก็บเป็นความลับเพื่อให้เลียนแบบได้ยากขึ้น

  • ลายเซ็นของคำขอ

    ลายเซ็นเข้ารหัสจากไคลเอนต์อัตโนมัติที่เผยแพร่คีย์ของตน

  • การประกาศ

    ไคลเอนต์ที่ระบุว่าตัวเองเป็น Agent หรือการเปิดเผยการใช้ความช่วยเหลือจาก AI ภายในแอปของคุณ

  • สัญญาณการโต้ตอบ

    สัญญาณจากตัวเก็บข้อมูลเบราว์เซอร์ที่อนุมัติ บนหน้าที่มันทำงานอยู่

  • บริบทของคำขอ

    ส่วนหัวและรายละเอียดโปรโตคอลที่มีให้สำหรับการผสานใช้งานฝั่งเซิร์ฟเวอร์

ตัวตนของ agent ไม่ใช่การอนุญาต

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

สิ่งนี้ไม่ได้แสดงว่าใครเป็นผู้สั่ง agent, ว่ามีบุคคลมอบสิทธิ์ให้มันหรือไม่, ตัวตนทางกฎหมายที่อยู่เบื้องหลังมัน หรือว่าการกระทำนั้นปลอดภัยหรือไม่ นั่นเป็นคำถามคนละส่วนที่แอปพลิเคชันของคุณตอบด้วย authentication, authorization และ policy ของตัวเอง

สามคำถามแยกกัน
  • ใครกำลังเรียกProof of Actor: signature, declaration หรือ inference
  • ข้อมูลรับรองใดคีย์ API, OAuth token หรือเซสชันของคุณ
  • มันอาจทำอะไรได้บ้างการอนุญาตและนโยบายของคุณ

การตัดสินใจด้าน routing เข้ามาอย่างไร

แอปพลิเคชันของคุณเรียกใช้ Proof of Actor รับผลลัพธ์ และใช้กฎของตัวเอง คุณเลือกได้ต่อ route และต่อระดับความเสี่ยงว่าการผสานรวมจะ fail open หรือไม่ (คำขอดำเนินต่อไปเหมือนที่เป็นหากไม่มี Proof of Actor) หรือ fail closed (ใช้การตรวจสอบที่เข้มงวดเดิมของคุณ)

  • หมดเวลา API

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

  • ไม่มี telemetry

    หากตัวเก็บข้อมูลในเบราว์เซอร์ไม่ได้ทำงานหรือสัญญาณใดขาดหาย ผลลัพธ์จะแสดงตามนั้น หลักฐานที่ขาดหายทำให้สิ่งที่กล่าวได้ลดลง และจะไม่ถูกมองว่าน่าสงสัย

  • การจัดประเภทแบบ Unknown

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

  • หลักฐานล้าสมัย

    หลักฐานมีเวลาและขอบเขต ผลลัพธ์จากช่วงต้นของ session ไม่ควรถูกนำมาใช้ซ้ำสำหรับการกระทำที่อ่อนไหวมากขึ้นในภายหลังโดยไม่มีการตรวจสอบใหม่

workflow การผสานการทำงานในช่วงเบต้า

  1. 01สมัครบอกเราเกี่ยวกับแอปและการโต้ตอบที่คุณต้องการทำความเข้าใจ
  2. 02ขอบเขตตกลงเรื่องการผสานรวม เส้นทาง ข้อจำกัดการใช้งาน และการจัดการข้อมูล
  3. 03ผสานการทำงานในโหมดสังเกตไม่มีการเปลี่ยนแปลงวิธีที่ app ของคุณตอบสนอง
  4. 04ตรวจสอบความถูกต้องเปรียบเทียบผลลัพธ์กับ ground truth ที่คุณรู้จัก: coverage, อัตรา unknown, false positives, latency
  5. 05ตัดสินใจเปิดใช้นโยบายเฉพาะในจุดที่หลักฐานสนับสนุนเท่านั้น

สิ่งที่เราวัดผลร่วมกับทีมผู้ก่อตั้ง

coverage, อัตรา unknown, false positives เมื่อเทียบกับผลลัพธ์ที่ทราบ และ latency ที่เพิ่มขึ้น ในแต่ละบริบทที่รองรับ

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

สมัครเข้าร่วมโปรแกรม Founding Developer

สมัครขอ Early Accessดู Detection & Limits

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