เมื่อ AI Agent หรือ Automation เชื่อมระบบภายใน ความเสี่ยงไม่ได้มีเพียงคำตอบผิด แต่รวมถึงสิทธิ์ที่ใช้ทำงานด้วย บัญชีที่เข้าถึงทุกระบบหรือ Token ที่ถูกใส่ใน Prompt อาจทำให้ความเสียหายขยายเกินงานเดิม จึงควรจัดการตัวตนและความลับก่อนขยายการเชื่อมต่อ

รู้ว่าใครหรืออะไรถือสิทธิ์

PAM360 มีขอบเขตด้านการบริหารสิทธิ์สูงและการกำกับตัวตนที่ไม่ใช่คนตามข้อมูลผู้ผลิต องค์กรควรทำรายการบัญชี Service, เจ้าของ, งานที่ใช้ และระบบปลายทาง แยกบัญชีคนออกจากบัญชีงานอัตโนมัติ ไม่ใช้บัญชีร่วมโดยไม่มีเจ้าของและหลักฐานการเข้าถึง

ลดสิทธิ์และไม่ส่งความลับให้โมเดล

กำหนดเครื่องมือและคำสั่งที่อนุญาตตามงาน ให้ระบบเชื่อมต่อใช้ความลับผ่านวิธีที่อนุมัติ ไม่ใส่ Password หรือ API key ลง Prompt หรือบทความฐานความรู้ การหมุนความลับ การเข้าถึงชั่วคราว และการเชื่อมเครื่องมือจำเป็นต้องตรวจวิธีรองรับในรุ่นและระบบปลายทางจริง

ทดสอบทั้งการปฏิเสธและการหยุด

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

รายการตรวจสอบก่อนนำไปใช้

  • บัญชีอัตโนมัติทุกบัญชีมีเจ้าของและวัตถุประสงค์
  • แยกสิทธิ์อ่านจากสิทธิ์เปลี่ยนแปลง
  • ไม่มี Credential ใน Prompt, Log หรือฐานความรู้
  • มีวิธีเพิกถอน ทบทวนสิทธิ์ และตรวจเหตุเกินขอบเขต

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

PAM ทำให้คำตอบ AI ถูกต้องเสมอหรือไม่?

PAM ช่วยด้านสิทธิ์และการเข้าถึง แต่ต้องตรวจความถูกต้องของผล AI และกระบวนการทำงานแยกต่างหาก

ให้ Agent ใช้บัญชีผู้ดูแลหลักสะดวกกว่าได้ไหม?

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

ปรึกษา KTNBS และขอ Demo ตามโจทย์องค์กร ↗

แหล่งอ้างอิง