ตัวตน สิทธิ์ และบันทึกตรวจสอบเอเจนต์ AI: แยกผู้สั่ง ผู้ลงมือ และผลลัพธ์
จัดทำบันทึกงานเอเจนต์ที่ตรวจตามได้ แยกตัวตน ขอบเขตสิทธิ์ การอนุมัติ และผลจริง พร้อมตัวอย่าง Microsoft Entra งาน Android และวิธีตรวจปลายทางก่อนลองซ้ำ
- บันทึกงานให้เชื่อมผู้เริ่มคำขอ ตัวตนที่ลงมือ ข้อมูลอ้างอิงการเชื่อมต่อ ขอบเขต การอนุมัติ และผลจริง โดยไม่เก็บรหัสผ่านหรือโทเคน
- ใน Microsoft Entra สิทธิ์ทำแทนผู้ใช้กับสิทธิ์ของแอปที่ผู้ดูแลให้เป็นคนละแบบ เลือกสิทธิ์ตามทรัพยากรและงาน ไม่ถือว่าการยินยอมเชื่อมต่ออนุมัติทุกการกระทำ
- ใช้หลักฐานตัวตนและการเข้าสู่ระบบประกอบหลักฐานจากแอปปลายทาง แยกสำเร็จ ถูกปฏิเสธ รออนุมัติ และผลไม่แน่ชัด ไม่ใช้การเข้าสู่ระบบสำเร็จแทนหลักฐานว่างานเสร็จ
- บน FoneClaw ให้ตรวจสิทธิ์ Android เครื่องมือ และนโยบายอนุมัติแยกจากข้อมูลรับรองโมเดล การถอนสิทธิ์หยุดการเข้าถึงในอนาคต แต่ไม่ย้อนคืนงานที่เขียนสำเร็จแล้ว
เริ่มจากบันทึกตัวอย่างที่ตรวจตามได้
การจัดการ ตัวตน สิทธิ์ และบันทึกตรวจสอบเอเจนต์ AI ควรเริ่มจากงานหนึ่งรายการที่ผู้ตรวจติดตามได้ว่าใครขอ ใครลงมือ ใช้การเชื่อมต่อใด ได้รับอนุญาตให้ทำอะไร และเกิดผลใดจริง ไม่เริ่มจากเก็บบทสนทนาทั้งหมดแล้วถือว่าเป็นหลักฐานครบถ้วน เพราะคำสั่ง แผน การอนุมัติ และการดำเนินการเป็นคนละเหตุการณ์
ตัวอย่างสมมติสำหรับจัดทำบันทึกด้วยตนเอง ไม่ใช่ข้อมูลส่งออกจากผลิตภัณฑ์: พนักงานขอให้เอเจนต์อ่านเอกสารงานที่ระบุ แล้วเตรียมร่างคำตอบให้ตรวจ โดยยังไม่ส่งถึงใคร ตารางห้าช่องนี้รวมผู้เริ่มคำขอกับตัวตนที่ลงมือไว้ในช่องเดียว แต่ยังต้องระบุแยกกันภายในช่อง รหัสตัวอย่างใช้เชื่อมข้อมูล ไม่ใช่รหัสที่ระบบใดรับรองว่าจะสร้างให้
| ช่องบันทึก | ตัวอย่างข้อมูลที่ควรเชื่อมได้ |
|---|---|
| ผู้เริ่มคำขอและตัวตนที่ลงมือ | พนักงาน ก เป็นผู้ขอใน REQ-001; เอเจนต์ร่างงาน A เป็นตัวตนที่ใช้ดำเนินการ; หัวหน้าทีม ข เป็นผู้อนุมัติ ไม่ใช่ผู้ลงมือ |
| ข้อมูลอ้างอิงการเชื่อมต่อ | DOC-READ-01 อ้างถึงการเชื่อมต่อที่ใช้ โดยไม่บันทึกรหัสผ่าน API key หรือโทเคน |
| ขอบเขต | อ่าน DOC-42 และเตรียมร่างสำหรับตรวจ ไม่มีสิทธิ์ส่งข้อความหรือแก้เอกสารต้นฉบับ |
| การอนุมัติ | หัวหน้าทีม ข อนุมัติการอ่านเอกสารที่ระบุ เวลา 14:00 น.; ไม่ได้อนุมัติการส่งร่าง และไม่เพิ่มสิทธิ์ให้เกินขอบเขตของการเชื่อมต่อ |
| หลักฐานและผล | REQ-001 เชื่อมกับ ACT-001 สำหรับการอ่าน และ ACT-002 สำหรับการเตรียมร่าง; บันทึกเวลา สถานะ และข้อมูลอ้างอิงผล เช่น DRAFT-01 เมื่อมีหลักฐานว่าร่างถูกสร้างจริง |
แยกการอ่านกับการสร้างร่างเป็นสองขั้น แม้อยู่ในคำขอเดียว หากอ่านเอกสารผ่านแต่ร่างไม่ถูกสร้าง ให้บันทึกผลสำเร็จเฉพาะการอ่าน ไม่ปิดทั้งคำขอเป็นสำเร็จ หากมีเพียงข้อความเสนอร่างในบทสนทนา ให้ระบุปลายทางนั้นตามจริง ไม่เขียนว่าได้บันทึกร่างในระบบอีเมลแล้วโดยยังไม่ได้ตรวจ
ชื่อเอเจนต์ในบทสนทนาเป็นป้ายเรียก ไม่ใช่หลักฐานว่าระบบปลายทางยอมรับตัวตนนั้น ข้อมูลรับรองใช้ยืนยันการเชื่อมต่อ สิทธิ์กำหนดสิ่งที่ทำได้ และการอนุมัติครอบคลุมงานที่ระบุเท่านั้น ผู้ตรวจควรเปิดข้อมูลอ้างอิงและตรวจผลได้ตามสิทธิ์ของตน โดยไม่ต้องคัดลอกเอกสารทั้งฉบับหรือเก็บโทเคนลงในบันทึก
กำหนดตัวตนและขอบเขตสิทธิ์ในองค์กร
เมื่อเอเจนต์เข้าถึงข้อมูลขององค์กร ให้เริ่มจากทรัพยากรที่จะใช้และตัวตนที่ระบบปลายทางเห็นจริง เอกสารการกำหนดสิทธิ์ Microsoft Entra Agent ID แยกสิทธิ์แบบทำแทนผู้ใช้ ซึ่งทำงานในนามผู้ใช้ที่เกี่ยวข้อง ออกจากสิทธิ์แบบแอปที่ผู้ดูแลระบบอนุญาตให้ตัวตนแอปใช้ได้โดยไม่ต้องมีผู้ใช้ลงชื่อเข้าใช้ในแต่ละครั้ง ขอบเขตและข้อจำกัดนี้เป็นของ Microsoft Entra ไม่ใช่พฤติกรรมที่ควรสมมติว่าเอเจนต์ทุกระบบมีเหมือนกัน
งานอ่านเอกสารหนึ่งรายการไม่ควรเริ่มด้วยสิทธิ์เขียนหรือบทบาทผู้ดูแลระบบที่กว้างกว่าเป้าหมาย Entra มีข้อจำกัดสำหรับบทบาทและสิทธิ์ API ที่มีอำนาจสูง จึงต้องตรวจว่าสิทธิ์ที่ต้องการใช้ได้กับตัวตนนั้นหรือไม่ ไม่เลือกตัวตนผู้ดูแลเพื่อเลี่ยงข้อจำกัดเมื่อสิทธิ์อ่านเฉพาะทรัพยากรก็เพียงพอ
| ส่วนที่ต้องเลือก | คำถามก่อนให้สิทธิ์ |
|---|---|
| ทรัพยากร Azure | ต้องทำงานกับทรัพยากรใด และบทบาทที่ให้ครอบคลุมเกินงานหรือไม่ |
| ไดเรกทอรี | งานต้องจัดการข้อมูลไดเรกทอรีจริงหรือเพียงเข้าถึงแอปหนึ่งตัว |
| Microsoft Graph | ต้องอ่านหรือเขียนข้อมูลชนิดใด ผ่านสิทธิ์ทำแทนผู้ใช้หรือสิทธิ์ของแอป |
| การอนุมัติงาน | ใครอนุมัติการกระทำครั้งนี้ และอนุมัติถึงขั้นใด |
ผู้เริ่มคำขอ ตัวตนที่ใช้เข้าถึงบริการ และผู้อนุมัติอาจเป็นคนละฝ่ายกัน เช่น พนักงานขอร่างคำตอบ เอเจนต์ใช้สิทธิ์อ่านข้อมูล และหัวหน้าทีมอนุมัติการใช้เอกสารในงานนั้น การยินยอมให้สิทธิ์ผ่าน OAuth ไม่ได้หมายความว่าหัวหน้าทีมอนุมัติการส่งทุกครั้ง API key ก็เป็นข้อมูลรับรองการเชื่อมต่อ ไม่ใช่ระบบกำกับเจ้าของตัวตน ขอบเขตงาน และผู้อนุมัติครบชุด
ระบุเจ้าของตัวตน ผู้รับผิดชอบการเชื่อมต่อ และผู้สนับสนุนงานตามรูปแบบที่องค์กรใช้ พร้อมรอบทบทวนหรือวันสิ้นสุดเมื่อมีนโยบายกำหนด หากหน้าที่เปลี่ยน ให้ตรวจสิทธิ์อีกครั้ง ไม่เก็บขอบเขตเดิมไว้เพียงเพราะการเชื่อมต่อยังทำงาน บทความ ความปลอดภัยของ AI Agent สำหรับองค์กร: วิธีประเมิน Phone AI Agent แบบโลคัล ช่วยขยายคำถามด้านการกำกับดูแลก่อนนำเอเจนต์เข้าถึงข้อมูลและบัญชีงาน
แยกหลักฐานตัวตนออกจากผลของงาน
คู่มือบันทึกการเข้าสู่ระบบและการตรวจสอบของ Microsoft Entra Agent ID อธิบายข้อมูลอย่าง agentType และ blueprintId เพื่อเชื่อมเหตุการณ์กับเอเจนต์และต้นแบบที่เกี่ยวข้อง กิจกรรมของต้นแบบปรากฏเป็นเหตุการณ์ของแอป ตัวตนเอเจนต์เป็นเหตุการณ์ของ service principal และบัญชีผู้ใช้ของเอเจนต์เป็นเหตุการณ์ของผู้ใช้
ผู้มีสิทธิ์อย่างน้อยระดับ Reports Reader สามารถไปที่ Entra ID แล้วเปิดส่วนการตรวจสอบและสถานะระบบ ตามด้วยบันทึกการเข้าสู่ระบบ และใช้ตัวกรองเอเจนต์ตามที่ระบบแสดง ตัวอย่างการเรียกข้อมูลบันทึกเอเจนต์ผ่าน Microsoft Graph ในเอกสารใช้ /beta จึงควรตรวจเงื่อนไขของช่องทางนั้นก่อนนำไปใช้ ไม่ถือว่ารูปแบบตัวอย่างเป็นสัญญาการใช้งานเดียวกันทุกระบบ
หลักฐานเหล่านี้ช่วยตอบว่าตัวตนใดเข้าสู่ระบบและมีเหตุการณ์ด้านตัวตนอะไรเกิดขึ้น แต่การเข้าสู่ระบบสำเร็จไม่ได้พิสูจน์ว่า DOC-42 ถูกอ่าน ร่างถูกสร้าง หรือข้อความถูกส่ง ผู้ตรวจต้องเทียบกับผลจากแอปที่ทำงานจริง ไม่คาดว่าทุกการกระทำทางธุรกิจจะมีรายละเอียดครบในบันทึกการเข้าสู่ระบบ
- เริ่มจากรหัสคำขอและขั้นการกระทำ เช่น REQ-001 กับ ACT-001 ในบันทึกที่จัดทำ
- ตรวจตัวตนที่ลงมือ ทรัพยากรเป้าหมาย และช่วงเวลาที่เกี่ยวข้อง โดยระบุเขตเวลาหากหลักฐานใช้คนละเขตเวลา
- เทียบกับเหตุการณ์ของแอปปลายทาง เช่น การอ่านเอกสาร การสร้างร่าง หรือรายการที่ถูกเขียน พร้อมรหัสอ้างอิงที่มีจริง
- แยกผลแต่ละขั้นและระบุช่องว่างของหลักฐาน หากยังไม่มีหลักฐานปลายทาง ให้คงผลว่าไม่ทราบหรือยังรอตรวจ
หากไม่มีรหัสร่วมระหว่างสองระบบ ให้บันทึกวิธีที่ใช้เทียบและข้อจำกัดของการจับคู่ เวลาใกล้กันอย่างเดียวอาจยังไม่พอแยกคำขอหลายรายการ ไม่ควรสร้างรหัสอ้างอิงขึ้นแล้วทำให้ดูเหมือนปลายทางส่งกลับมา หากมีการลองใหม่หลังเครือข่ายขาด ให้ตรวจรายการปลายทางก่อนสรุปว่างานเดิมไม่เกิดขึ้น
สิทธิ์อ่านบันทึกและระยะเวลาเก็บควรเป็นไปตามนโยบายองค์กร เก็บตัวระบุ สถานะ และข้อมูลอ้างอิงผลเท่าที่จำเป็น แทนเก็บเนื้อหาอ่อนไหวทั้งหมด ข้อมูลภายนอกที่เอเจนต์อ่านต้องพิจารณาความน่าเชื่อถือแยกจากสิทธิ์เข้าถึง; บทความ การวางยาความจำผู้ช่วย AI บนมือถือ: ตรวจ Ask AI และกู้คำแนะนำ อธิบายกรณีที่เนื้อหาหรือความจำอาจชักนำคำแนะนำผิดทาง
บันทึกผลสี่แบบโดยไม่สรุปเกินหลักฐาน
ตัวอย่างต่อไปนี้เป็นแนวทางเขียนบันทึกสมมติ ไม่ใช่ผลทดสอบหรือรูปแบบข้อมูลที่ผลิตภัณฑ์ส่งออก แต่ละรายการต้องแยกสิทธิ์ที่มี การอนุมัติงานครั้งนี้ การพยายามดำเนินการ และสิ่งที่สังเกตได้จริง หากหลักฐานไม่ครบ ให้ระบุความไม่แน่ชัดแทนเติมสถานะสำเร็จ
อ่านสำเร็จ: ยืนยันเฉพาะขอบเขตที่อ่าน
สำหรับ REQ-101 ผู้ขอให้เอเจนต์ A อ่าน DOC-42 ผ่านการเชื่อมต่อ DOC-READ-01 ที่มีสิทธิ์อ่าน บันทึกการอนุมัติตามนโยบายที่ใช้ แล้วระบุว่า ACT-101 มีหลักฐานจากแอปปลายทางว่าการอ่านสำเร็จ หากยังไม่มีหลักฐานการสร้างร่าง ให้ปิดเฉพาะขั้นอ่าน ไม่เขียนว่าอ่านและตอบกลับครบแล้ว ผลสำเร็จนี้ไม่ได้ขยายสิทธิ์ไปยังเอกสารอื่นหรือการส่งข้อความ
รออนุมัติ: ยังไม่ถือว่าเกิดการเขียน
สำหรับ REQ-102 ระบบเตรียมรายละเอียดการสร้างรายการ แต่ยังรอผู้มีอำนาจตัดสินใจ บันทึกทรัพยากรที่จะเขียน ขอบเขตที่รองรับ และผู้ที่ต้องอนุมัติ พร้อมสถานะว่า “รออนุมัติ ยังไม่มีหลักฐานการเริ่มเขียน” ไม่ใช้สถานะเตรียมพร้อมแทนสำเร็จ และไม่ใช้การยินยอมเชื่อมต่อครั้งก่อนข้ามขั้นตัดสินใจที่นโยบายนี้กำหนด
ถูกปฏิเสธ: ระบุว่าหยุดที่ชั้นใด
สำหรับ REQ-103 ตัวตนมีสิทธิ์อ่าน แต่คำขอต้องการเขียน หรือผู้อนุมัติปฏิเสธการกระทำ ให้ระบุสาเหตุและขั้นที่หยุด ไม่รวมเป็นคำว่า “ล้มเหลว” โดยไม่บอกชั้น จากนั้นตรวจปลายทาง หากไม่พบรายการเปลี่ยนแปลงในขอบเขตที่ตรวจ ให้บันทึกเช่นนั้น แทนรับรองว่าไม่มีผลใดเกิดขึ้นทั้งระบบ หากยังเข้าถึงหลักฐานปลายทางไม่ได้ ให้แยกข้อจำกัดนี้ไว้
เขียนแล้วผลไม่แน่ชัด: ตรวจปลายทางก่อนลองซ้ำ
สำหรับ REQ-104 ได้รับอนุมัติและเริ่มคำขอเขียนแล้ว แต่การเชื่อมต่อขาดก่อนรับผล ให้บันทึกว่า “ทราบว่ามีการเริ่มคำขอ แต่ยังไม่ยืนยันผลปลายทาง” ไม่เปลี่ยนเป็นไม่สำเร็จโดยอัตโนมัติ ตรวจรายการที่อาจถูกสร้างจากรหัสอ้างอิงหรือรายละเอียดที่มี หากพบหนึ่งรายการ ให้ตรวจเนื้อหาและเวลา หากพบหลายรายการ ให้แยกแต่ละผลก่อนแก้ไข หากยังตรวจไม่ได้ ให้หยุดการลองซ้ำที่อาจสร้างผลซ้ำ
ทั้งสี่แบบควรมีขั้นถัดไปชัดเจน: งานอ่านที่ยืนยันแล้วไปต่อได้ตามขอบเขต งานรออนุมัติต้องรอการตัดสินใจ งานถูกปฏิเสธต้องแก้เหตุที่ปฏิเสธโดยไม่ขยายสิทธิ์เกินจำเป็น และงานผลไม่แน่ชัดต้องตรวจปลายทาง การอนุมัติไม่ใช่การดำเนินการ และการเริ่มดำเนินการไม่ใช่หลักฐานว่างานเสร็จ
ใช้คำถามเดียวกันกับงานบนโทรศัพท์
บน FoneClaw เราใช้กรอบห้าช่องนี้เป็นรายการตรวจด้วยตนเองสำหรับงาน Android ไม่ใช่รูปแบบบันทึกตรวจสอบที่แอปส่งออกหรือการเชื่อมต่อกับ Microsoft Entra ตัวอย่างที่เริ่มได้โดยไม่เปลี่ยนการตั้งค่าคือขออ่านสถานะแบตเตอรี่และโหมดประหยัดพลังงาน เครื่องมือ device_battery_status ส่งสถานะกลับมาโดยไม่แก้ค่าบนเครื่อง ผู้ใช้จดว่าใครขออ่าน เครื่องมือเปิดใช้อยู่หรือไม่ นโยบายอนุมัติขณะนั้นเป็นอย่างไร และได้ผลใดกลับมา
- ตรวจสิทธิ์ Android แยกจากการเปิดใช้เครื่องมือใน FoneClaw
- ตรวจโหมดอนุมัติรวมและการตั้งค่ารายเครื่องมือ ซึ่งกำหนดพฤติกรรมจริงร่วมกับขอบเขตงาน
- อ้างอิงผู้ให้บริการหรือการตั้งค่าโมเดล โดยไม่คัดลอกข้อมูลรับรองลงในบันทึก
- เทียบผลเครื่องมือกับสถานะหรือแอปปลายทางเมื่อทำได้ โดยจดเวลาที่อ่านข้อมูล
เครื่องมืออ่านแบตเตอรี่มีความเสี่ยงต่ำและค่าการอนุมัติเริ่มต้นแบบอัตโนมัติ แต่ควรบันทึกการตั้งค่าที่มีผลจริง ไม่เขียนว่าผู้ใช้กดยืนยันถ้าไม่มีขั้นนั้นเกิดขึ้น โมเดลที่เลือกช่วยตีความและวางแผน ส่วนเครื่องมือที่เปิดใช้ดำเนินงานตามสิทธิ์ของเครื่อง ข้อมูลรับรองโมเดลไม่ได้ให้สิทธิ์อ่านหรือเขียน Android แทนการควบคุมเหล่านี้
งานสร้างนัดหมายต่างออกไป: calendar_create_event มีผลต่อปฏิทินและมีค่าการอนุมัติเริ่มต้นให้ขออนุมัติ โดยต้องดูนโยบายที่มีผลจริงด้วย ตัวอย่างคำขอที่เสนอคือสร้างนัดวันที่ 12 ตุลาคม 2026 เวลา 09:00–09:30 น. ตามเขตเวลาเครื่อง และเตือนก่อน 10 นาที หากผู้ใช้ยังไม่ได้ระบุเวลาสิ้นสุดหรือการเตือน ให้สอบถามส่วนที่ขาดก่อนลงมือ ไม่เติมเองเพื่อให้คำขอดูครบ
หลังสร้าง ให้ใช้เวลา actualStart และ actualEnd จากผลเครื่องมือเป็นเวลาที่สร้างจริง แล้วเปิดตรวจรายการในปฏิทินปลายทาง รวมถึงชื่อ วัน เวลา และการเตือน ไม่ถือว่ารายการบน Android ต้องตรงกับปฏิทินคลาวด์ทุกบัญชีโดยอัตโนมัติ หากคำตอบขาดหาย ให้ตรวจรายการเดิมก่อนสร้างซ้ำ และบันทึกปลายทางที่ตรวจจริง
รายละเอียดเครื่องมือและการควบคุมของเราอยู่ที่ ฟีเจอร์ FoneClaw สำหรับงานบน Android หากงานหนึ่งอาศัยหลายเครื่องมือ บทความ ความปลอดภัยของสกิล AI agent: ทำไม phone agent ต้องตรวจสิทธิ์ขณะทำงาน ช่วยตรวจขอบเขตแต่ละขั้น หากใช้โมเดลออนไลน์ บริบทงานที่เลือกอาจถูกส่งไปประมวลผลกับผู้ให้บริการ บันทึกการกระทำบนโทรศัพท์จึงไม่ได้ยืนยันว่าข้อมูลทั้งหมดอยู่บนเครื่อง
ลองปฏิเสธงานและถอนสิทธิ์ที่ไม่ใช้
การตรวจแบบไม่กระทบข้อมูลทำได้โดยจดการตั้งค่าเดิมแล้วปิดเครื่องมืออ่านสถานะแบตเตอรี่ชั่วคราว จากนั้นขอสถานะเดิมอีกครั้งโดยไม่อนุญาตให้เปลี่ยนไปใช้ทางอื่น นี่เป็นการทดลองที่เสนอให้ทำบนอุปกรณ์ของตน ไม่ใช่รายงานผลทดสอบ เกณฑ์ที่ต้องตรวจคือเครื่องมือที่ปิดไม่ถูกใช้ในคำขอใหม่ และระบบแจ้งข้อจำกัดหรือไม่สามารถให้ข้อมูลใหม่จากเครื่องมือนั้นได้
อย่าใช้ค่าจากบทสนทนาก่อนหน้าเป็นหลักฐานว่าการอ่านครั้งใหม่สำเร็จ บันทึกข้อความที่แสดง สถานะเครื่องมือ และความไม่แน่ชัดถ้ามี พร้อมตรวจว่าไม่ได้เปลี่ยนการตั้งค่าเครื่องโดยคำขอนี้ เมื่อเสร็จแล้วจึงเปิดเครื่องมือกลับเฉพาะกรณีที่ยังต้องใช้ และเก็บว่าได้คืนการตั้งค่าใดแล้ว
ในระบบองค์กร ให้ทบทวนตัวตน การมอบสิทธิ์ และการเชื่อมต่อที่ไม่ใช้งาน หากข้อมูลรับรองถูกเปิดเผย ให้เปลี่ยนหรือเพิกถอนตามระบบที่เกี่ยวข้อง แล้วตรวจคำขอใหม่ว่าถูกปฏิเสธตามขอบเขตที่ถอน อย่าสรุปว่าการถอนจุดเดียวครอบคลุมทุกเส้นทาง หากยังมีการเชื่อมต่อหรือตัวตนอีกชุดที่เข้าถึงทรัพยากรเดียวกันได้
การถอนสิทธิ์มีเป้าหมายหยุดการเข้าถึงในอนาคต ไม่ได้ลบร่าง นัดหมาย หรือข้อมูลที่เขียนสำเร็จไปแล้ว หากต้องย้อนผลเดิม ให้ตรวจรายการปลายทางและดำเนินการแก้ไขหรือลบเป็นงานแยกที่มีสิทธิ์และการอนุมัติของตัวเอง โดยเก็บข้อมูลอ้างอิงที่จำเป็นก่อนแก้ ไม่ลองสร้างซ้ำเพียงเพราะคำตอบของงานก่อนหน้าหายไป
- ระบุสิทธิ์หรือการเชื่อมต่อที่จะถอนและเจ้าของที่รับผิดชอบ
- บันทึกการตั้งค่าที่เปลี่ยนและเวลาที่ดำเนินการ โดยไม่เก็บความลับ
- ตรวจการเข้าถึงใหม่ด้วยงานที่ปลอดภัยและตรงขอบเขตที่ถอน
- ตรวจผลเดิมในแอปปลายทาง แยกสิ่งที่เกิดแล้วออกจากสิ่งที่ยังไม่เกิด
- ทบทวนผู้เข้าถึงบันทึกและระยะเวลาเก็บตามนโยบายของตน
บทสนทนาบนโทรศัพท์หรือรายการที่ผู้ใช้จดช่วยตรวจงานได้ แต่ไม่ใช่หลักฐานที่รับรองว่าแก้ไขไม่ได้ เกณฑ์สุดท้ายคือผู้ตรวจระบุได้ว่าใครเริ่ม ใครลงมือ ใช้สิทธิ์ใด ใครอนุมัติ เกิดผลอะไรจริง และส่วนใดยังตรวจไม่ครบ ก่อนตัดสินใจทำขั้นถัดไป