ข้ามไปยังเนื้อหาหลัก
APIS

ทำความเข้าใจว่าใครกำลังเรียกใช้ API ของคุณ

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

ขอสิทธิ์เข้าถึงก่อนใครสำรวจวิธีการทำงาน
example-app.test · ผลลัพธ์ของ actor

POST /api/v1/orders

เอเจนต์basis: inferred

หลักฐาน

ทราฟฟิกจาก API key ที่ไม่มีบริบทเบราว์เซอร์และมีรูปแบบคำขออัตโนมัติ

นโยบายของคุณ: ขอ credential ที่เข้มงวดกว่าก่อนสร้างคำสั่งซื้อ

API key ไม่ใช่ตัวตน และตัวตนก็ไม่ใช่สิทธิ์อนุญาต

ทราฟฟิกส่วนใหญ่ของ API มาพร้อม credential ที่บอกว่า account ใดเป็นผู้จ่าย ไม่ได้บอกว่า client ใดเป็นผู้เรียกหรือใครเป็นผู้สั่ง บาง client เซ็น request ของตน บางรายเพียงประกาศชื่อ และอีกหลายรายไม่บอกอะไรเลย

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

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

Proof of Actor ตอบคำถามแรก ส่วนสแต็กของคุณดูแลอีกสองข้อ

ทีม API ทำอะไรกับบริบทของ actor

  • ระบุไคลเอนต์ที่ลงนามแล้ว

    ตรวจสอบลายเซ็นของคำขอกับคีย์ที่เผยแพร่ และดูว่าคำขอนั้นเป็นของผู้ปฏิบัติงานรายใด

  • ให้ถือว่า declaration เป็น declaration

    บันทึกชื่อไคลเอนต์ที่ประกาศเอง และแยกออกจากข้อมูลประจำตัวที่ Verified

  • นโยบายต่อเส้นทาง

    อนุญาตการอ่านที่มีผลกระทบต่ำได้อย่างเสรี และขอข้อมูลเพิ่มสำหรับการเขียนและ endpoint ที่มีผลกระทบสูง

  • ดูผู้เรียกใช้งานทุกราย

    ทำความเข้าใจว่า client ใดใช้ endpoint ใด รวมถึง endpoint ที่เป็น Unknown

  • แยก credentials ออกต่างหาก

    API keys และ OAuth ยังคงเป็นตัวตัดสินการเข้าถึง ส่วนบริบทของ actor จะเพิ่มข้อมูลว่าใครเป็นผู้เรียก

  • แผนสำหรับ Unknown

    กำหนดว่าเมื่อ caller ไม่ให้หลักฐานที่ใช้งานได้จะเกิดอะไรขึ้น ราย route

01 · ตรวจจับ

หลักฐานจากทุก request

การเชื่อมต่อฝั่งเซิร์ฟเวอร์, edge และ HTTP API จะอ่านลายเซ็นคำขอ, รายละเอียดไคลเอนต์ที่แจ้งไว้ และบริบทคำขอ แล้วระบุฐานของแต่ละรายการ

  • ตรวจสอบ HTTP message signatures เทียบกับคีย์ที่เผยแพร่แล้ว
  • ชื่อ client ที่ประกาศไว้ซึ่งบันทึกเป็นการประกาศ
  • ขอข้อมูลบริบทของคำขอจากเซิร์ฟเวอร์, gateway หรือ edge ของคุณ
สัญญาณ · คำขอล่าสุดตามแหล่งที่มา
  • ลายเซ็นของคำขอvalid · sample-crawler.exampleverified
  • คำประกาศของไคลเอนต์"research-assistant/2.1"declared
  • การโต้ตอบในเบราว์เซอร์pointer + keyboard eventsinferred
  • ไม่มี signals ที่รองรับroute not instrumentedunknown

02 · ทำความเข้าใจ

รู้ว่าใครใช้ endpoint ใด

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

  • ผู้เรียกตามเส้นทางและผู้ปฏิบัติงาน
  • หลักฐานเบื้องหลังการจัดประเภทแต่ละรายการ
  • อัตรา Unknown ต่อ endpoint
ทราฟฟิกตาม route · 7 days
  • /dashboardไม่ทราบ 7%
  • /api/v1/catalogไม่ทราบ 15%
  • /support/ticketsไม่ทราบ 8%
  • /signupไม่ทราบ 21%
มนุษย์มนุษย์ + AIเอเจนต์ไม่ทราบ

03 · กำหนดเส้นทาง

การควบคุมที่สอดคล้องกับระดับผลกระทบ

เขียนนโยบายระดับ route: การตอบกลับแบบมีโครงสร้างสำหรับ agent ที่ Verified, ขีดจำกัดมาตรฐานสำหรับไคลเอนต์ที่ Declared, และข้อมูลรับรองที่เข้มงวดยิ่งขึ้นสำหรับการกระทำที่มีผลกระทบสูง

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

ตัวอย่างการตัดสินใจ

จาก request สู่ผลลัพธ์และการตัดสินใจของคุณ

  • Agent ที่ Verified อ่านแคตตาล็อกของคุณ

    คำขอ

    GET /api/v1/catalog

    ผลลัพธ์

    เอเจนต์basis: verified

    การตัดสินใจของคุณ

    อนุญาตด้วย rate limit สำหรับเอเจนต์และการตอบกลับแบบมีโครงสร้าง

  • ไคลเอนต์อัตโนมัติทำการสั่งซื้อ

    คำขอ

    POST /api/v1/orders

    ผลลัพธ์

    เอเจนต์basis: inferred

    การตัดสินใจของคุณ

    ขอ credential ที่เข้มงวดกว่าของแอปก่อนสร้างคำสั่งซื้อ

  • ไคลเอนต์ที่ไม่มีหลักฐาน

    คำขอ

    GET /api/v1/catalog

    ผลลัพธ์

    ไม่ทราบbasis: unknown

    การตัดสินใจของคุณ

    เส้นทางแบบอ่านอย่างเดียว: allow พร้อม rate limit ค่าเริ่มต้น

เปิดใช้งานโดยลดความเสี่ยง

ทีมเริ่มต้นในโหมดสังเกตการณ์และค่อย ๆ เดินหน้าไปทีละ route

  1. 01

    สังเกตทุก route

    เพิ่ม middleware หรือ HTTP API ไว้หน้าของ API ของคุณ ลายเซ็น คำประกาศ และผู้เรียกที่เป็น Unknown จะถูกบันทึกแยกตาม route

  2. 02

    ดูตัวอย่างนโยบายของ route

    ตรวจดูว่า agent rate limits หรือ step-up credentials จะทำอะไรกับทราฟฟิกจริงก่อนที่จะมีผลบังคับใช้

  3. 03

    บังคับใช้ตามผลกระทบ

    เปิดการอ่านไว้ ปรับให้การเขียนเข้มงวดขึ้น และให้ API keys และ OAuth เป็นผู้ควบคุมการเข้าถึง

ทำงานร่วมกับสแตกของคุณ

  • ทีมผู้ก่อตั้ง

    มิดเดิลแวร์ของเว็บเซิร์ฟเวอร์ (Node.js)

    ฝั่งเซิร์ฟเวอร์

    สัญญาณระดับคำขอสำหรับแอปที่เรนเดอร์ฝั่งเซิร์ฟเวอร์และ APIs

  • ทีมผู้ก่อตั้ง

    Next.js

    ฝั่งเซิร์ฟเวอร์และ edge

    Middleware สำหรับ page และ API routes

  • ทีมผู้ก่อตั้ง

    สคริปต์ของเบราว์เซอร์

    เฉพาะสัญญาณจากเบราว์เซอร์

    สัญญาณการโต้ตอบจากเซสชันของเบราว์เซอร์ ควบคู่กับการผสานการทำงานฝั่งเซิร์ฟเวอร์

  • ทีมผู้ก่อตั้ง

    Cloudflare และ edge runtimes

    Edge

    สัญญาณที่ edge ก่อนที่คำขอจะไปถึงต้นทางของคุณ

  • ทีมผู้ก่อตั้ง

    API HTTP ทั่วไป

    ทุกสแต็ก

    ส่งบริบทของคำขอไปยัง API และรับผลลัพธ์พร้อมเหตุผลฐาน

  • ทีมผู้ก่อตั้ง

    เซิร์ฟเวอร์ MCP

    MCP

    บริบทของตัวกระทำสำหรับการเรียกใช้เครื่องมือ MCP

  • แผนงาน

    WordPress

    ปลั๊กอิน

    ปลั๊กอินสำหรับเว็บไซต์ WordPress

  • แผนงาน

    มือถือเนทีฟ

    iOS และ Android

    Native iOS และ Android SDKs

การผสานการทำงานจะส่งมอบแบบลงมือทำร่วมกับแต่ละทีมผู้ก่อตั้งระหว่างการ onboarding หากใช้ stack อื่น บอกเราเมื่อคุณสมัคร

เรียนรู้เพิ่มเติม

อ่าน Detection & Limitations

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

ลูกค้าจำเป็นต้องลงนามใน requests ของตนหรือไม่

ไม่ใช่ Signed requests ให้ evidence ที่แข็งแรงที่สุด แต่ Proof of Actor ยังบันทึก declarations และ inferences โดยแต่ละรายการจะถูกติดป้ายตามฐานของมัน และรายงาน Unknown เมื่อมีข้อมูลไม่เพียงพอ

ลายเซ็นที่ถูกต้องหมายความว่า client ได้รับอนุญาตให้ดำเนินการหรือไม่

ไม่ใช่ มันแสดงว่า request นั้นถูกเซ็นด้วย key ที่เชื่อมกับ identifier ที่เผยแพร่แล้ว สิ่งที่ operator นั้นทำได้หรือไม่จะถูกตัดสินโดย authorization และ policy ของคุณ

มันใช้แทน API keys หรือ OAuth หรือไม่

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

เราตั้งกฎที่ต่างกันต่อ endpoint ได้ไหม

ใช่ นโยบายเขียนแยกตาม route ดังนั้น endpoints แบบอ่านอย่างเดียวและการเขียนที่มีผลกระทบสูงจึงสามารถปฏิบัติแตกต่างกันได้

มีค่าใช้จ่ายเท่าไร

ทีมผู้พัฒนาผู้ก่อตั้งที่ได้รับคัดเลือกสามารถรับสิทธิ์ใช้ฟรีได้นานสูงสุด 12 เดือน ภายใต้ขีดจำกัดการใช้งานที่ตกลงกัน

รู้ว่าใครกำลังเรียก API ของคุณ

เข้าร่วม Proof of Actor founding developer program

ขอสิทธิ์เข้าถึงก่อนใครศูนย์นักพัฒนา

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