ความหมายของคำศัพท์
การตรวจสอบทุกอย่างที่อยู่ในเส้นทางของ request อาจล้มเหลวจนไม่สามารถให้คำตอบได้: dependency หมดเวลา, signal หายไป, หรือดึง key ไม่ได้ Fail open หมายถึง request ดำเนินต่อไปเหมือนไม่มีการตรวจสอบนั้นอยู่ Fail closed หมายถึง request ใช้เส้นทางที่เข้มงวดกว่า: ถูกปฏิเสธ ถูก challenge หรือถูกส่งไปยัง control ที่แข็งแรงกว่าเดิมซึ่งมีอยู่แล้ว
โดยทั่วไป ไม่มีแบบใดที่ถูกต้องเสมอ การเลือกที่เหมาะสมขึ้นอยู่กับว่า route นั้นทำอะไร และการตัดสินใจที่ผิดมีต้นทุนเท่าไร
ทำไมจึงสำคัญสำหรับการตรวจ actor
การตรวจ actor เพิ่มบริบทให้กับ request: ว่าปฏิสัมพันธ์นั้นดูเป็น Human, Human + AI, Agent หรือ Unknown เมื่อบริบทนั้นไม่มีให้ใช้งาน application ก็ยังต้องตอบสนองอยู่ดี รูปแบบความล้มเหลวที่พบบ่อยมีสองแบบ:
- Fail closed โดยไม่ตั้งใจ timeout หรือ signal ที่หายไปถูกมองว่าน่าสงสัย และผู้ใช้จริงถูกบล็อกระหว่างที่ระบบขัดข้อง
- Fail open โดยไม่ตั้งใจใน action ที่อ่อนไหว ผลลัพธ์ที่หายไปถูกตีความเป็น Human อย่างเงียบๆ และ action ที่มีผลกระทบสูงดำเนินต่อไปด้วยการตรวจสอบที่น้อยกว่าที่ตั้งใจไว้
ทั้งสองกรณีเกิดจากการปล่อยให้การเลือกนั้นเป็นแบบนัยๆ วิธีแก้คือกำหนดให้ชัดเจนตามแต่ละ route บทความของเราเรื่อง การออกแบบ policy ระดับ app สำหรับมนุษย์และ AI agents อธิบายว่าพฤติกรรมเมื่อเกิดความล้มเหลวจะเข้ากับ policy แบบราย route ได้อย่างไร
วิธีเลือก
แนวทางที่ใช้งานได้จริงคือแบ่ง routes ตามระดับความเสี่ยง:
- ผลกระทบต่ำ (หน้า public, เอกสาร, routes แบบอ่านอย่างเดียวใน catalog): fail open ผลลัพธ์ actor ที่หายไปไม่ควรเปลี่ยนแปลงอะไร
- ผลกระทบปานกลาง (การสมัครใช้งาน, การส่งฟอร์ม, การค้นหาที่มีต้นทุน): โดยมาก fail open พร้อมบันทึก log หรือใช้การปรับเล็กน้อย เช่น rate limit มาตรฐาน
- ผลกระทบสูง (การเปลี่ยนแปลง account, การส่งออก data, action ที่ย้อนกลับไม่ได้): fail closed ไปยัง control ที่แข็งแรงกว่าเดิมซึ่งคุณใช้อยู่แล้ว เช่น การยืนยันตัวตนซ้ำหรือการยืนยันอีกครั้ง จุดประสงค์ไม่ใช่การบล็อก แต่คือย้อนกลับไปใช้การตรวจสอบที่คุณจะใช้ต่อให้ไม่มีระบบนี้
จากนั้นกำหนดพฤติกรรมเดียวกันสำหรับกรณีที่เกี่ยวข้อง:
- Timeout: การตรวจสอบไม่ตอบกลับทันเวลา
- Missing telemetry: integration ไม่ได้ทำงานหรือไม่มี signal
- Unknown: การตรวจสอบทำงานแล้ว แต่ evidence ไม่เพียงพอสำหรับการตัดสิน
- Stale evidence: ผลลัพธ์มาจากก่อนหน้าและไม่ควรถูกนำมาใช้ซ้ำกับ action ที่อ่อนไหวกว่า
ความเข้าใจผิดที่พบบ่อย
- "Fail closed ปลอดภัยกว่า" มันย้ายต้นทุนไปให้ผู้ใช้จริง สำหรับ routes ที่ผลกระทบต่ำ การ fail closed ระหว่างเกิด incident อาจสร้างความเสียหายมากกว่าความเสี่ยงที่มันป้องกัน
- "Unknown คือความล้มเหลว" Unknown เป็นผลลัพธ์ที่ถูกต้อง มันสมควรได้รับการจัดการเฉพาะของตัวเอง ซึ่งอาจตรงหรือไม่ตรงกับการจัดการ timeout ของคุณ
- "ผลลัพธ์ที่หายไปหมายถึง Human" อย่าอนุมาน actor class จากการไม่มี evidence
Proof of Actor จัดการเรื่องนี้อย่างไร
Proof of Actor จะไม่กำหนด Human ให้กับ timeout หรือผลลัพธ์ Unknown และการติดตั้งไม่ได้บล็อกอะไรทั้งสิ้น: ทีมเริ่มต้นใน observation mode พฤติกรรม fail open หรือ fail closed สำหรับแต่ละ route และแต่ละระดับความเสี่ยงเป็นการตัดสินใจของเจ้าของ application ซึ่งนำไปใช้ใน code ของคุณเองผ่าน Route วิธีนี้ช่วยให้การบังคับใช้คาดเดาได้ และทำให้คุณตรวจสอบผลลัพธ์ได้ก่อน policy ใดๆ จะเริ่มใช้งานจริง
อ่าน how routing decisions fit in หรือ apply for early access