เจาะประเด็น
AI Security
DPACT กรอบคิดที่บอกว่า AI Agent ต้องมี "ขอบเขตอำนาจ" ไม่ใช่ปล่อยสิทธิ์ลอยๆ
เมื่อ AI ไม่ใช่แค่ตอบคำถาม แต่ลงมือทำแทนเราได้ คำถามเรื่องตัวตนและสิทธิ์จึงกลายเป็นเรื่องที่ต้องออกแบบตั้งแต่ต้น
ทีมข่าว เอไอไทย.com
⏱ อ่าน 4 นาที
AI Agent ที่ลงมือทำได้ ยิ่งมีอำนาจมากเท่าไร ช่องโหว่ที่ตามมาก็ยิ่งน่ากลัวเท่านั้น
เรื่องนี้ฟังดูเป็นประเด็นเทคนิคที่คนทั่วไปอาจข้ามผ่านไป แต่มันคือคำถามใหญ่ที่วงการ AI กำลังต้องตอบให้ได้ก่อนที่ Agent จะกลายเป็นของสามัญในทุกองค์กร นั่นคือ เมื่อ AI ไม่ได้แค่ตอบคำถาม แต่สามารถสั่งงาน เรียกข้อมูล หรือตัดสินใจแทนมนุษย์ได้จริง แล้วเราจะรู้ได้ยังไงว่ามันคือ "ตัวตน" อะไร และมันมีสิทธิ์ทำอะไรได้แค่ไหน
Sahil Agarwal ผู้พูดในพอดแคสต์ตอนนี้ของ InfoQ หยิบเอาปัญหาเรื่อง identity (ตัวตน) และ authorization (การให้สิทธิ์) ขึ้นมาแกะตรงๆ เขาบอกว่ากลไกแบบเดิมที่เราใช้กันอยู่ โดยเฉพาะการเข้าถึงด้วย token แบบง่ายๆ มันไม่พอสำหรับโลกของ AI Agent อีกต่อไป เพราะมันเปิดช่องให้ Agent ทำอะไรเกินขอบเขตที่ควรจะทำได้
ปัญหาที่ Agarwal ชี้คือ Agent ในปัจจุบันมักถูกให้สิทธิ์แบบกว้างๆ ผ่าน token ที่ผูกกับบัญชีหรือระบบใดระบบหนึ่ง พอ Agent ทำงานอัตโนมัติต่อเนื่อง มันก็สามารถใช้สิทธิ์นั้นเกินความจำเป็นได้โดยที่มนุษย์ไม่ทันรู้ตัว ซึ่งนี่คือช่องโหว่ที่อันตรายกว่าการที่ AI "ตอบผิด" มากนัก เพราะมันกระทบถึงความปลอดภัยของข้อมูลและระบบโดยตรง
เขาจึงเสนอกรอบคิดที่ชื่อว่า DPACT ซึ่งย่อมาจาก Delegation, Policy, Auditability, Context และ Time เป็นแนวทางที่บอกว่า Agent ไม่ควรได้สิทธิ์แบบ "ทั้งหมดหรือไม่มีเลย" แต่ควรได้ "อำนาจที่ถูกมอบหมายอย่างมีขอบเขต" หรือที่เขาเรียกว่า bounded, delegated authority
กรอบ DPACT นี้ไม่ได้เป็นแค่คำสวยๆ แต่เป็นโครงที่บอกว่าเราควรออกแบบระบบ Agent อย่างไรให้ตรวจสอบได้และควบคุมได้จริง ลองแยกออกมาดูทีละตัว
Delegation (การมอบหมาย)
Agent ไม่ควรมีสิทธิ์โดยกำเนิด แต่ต้องได้รับสิทธิ์ที่ถูกมอบหมายมาจากมนุษย์หรือระบบที่ชัดเจน
Policy (นโยบาย)
ต้องมีกฎเกณฑ์กำกับว่า Agent ทำอะไรได้หรือไม่ได้ เพื่อไม่ให้มันตัดสินใจเกินกรอบที่องค์กรกำหนด
Auditability (การตรวจสอบย้อนหลัง)
ทุกการกระทำของ Agent ต้องตามรอยได้ว่าใครสั่ง ทำอะไร เมื่อไหร่ เพื่อให้ตรวจสอบได้เมื่อเกิดปัญหา
Context (บริบท)
สิทธิ์ของ Agent ต้องขึ้นอยู่กับสถานการณ์ งานหนึ่งอาจให้สิทธิ์กว้าง อีกงานต้องจำกัด เพื่อความปลอดภัย
Time (เวลา)
สิทธิ์ควรมีอายุ หมดเขตได้ ไม่ใช่ให้ค้างอยู่ตลอดไป เพราะความเสี่ยงเปลี่ยนไปตามเวลา
ทั้งหมดนี้ Agarwal วางไว้เป็นพิมพ์เขียวสำหรับสร้างระบบ Agent ที่มีความรับผิดชอบและมี guardrail กำกับ ไม่ใช่ปล่อยให้มันทำงานลอยๆ แล้วค่อยตามแก้ทีหลัง
ถ้ามองในมุมของคนทำธุรกิจหรือคนที่กำลังจะเอา AI Agent เข้ามาใช้ในองค์กร DPACT ไม่ใช่เรื่องไกลตัวเลย เพราะทุกวันนี้ Agent เริ่มถูกฝังเข้าไปใน workflow จริง ทั้งตอบลูกค้า จัดการข้อมูล หรือสั่งงานระบบหลังบ้าน ถ้าไม่มีกรอบแบบนี้ตั้งแต่ต้น วันที่เกิดปัญหาก็จะไม่รู้ด้วยซ้ำว่าใครควรรับผิดชอบ
และที่สำคัญคือ เรื่องนี้ไม่ใช่แค่โจทย์ของทีม security แต่เป็นโจทย์ของคนออกแบบผลิตภัณฑ์และคนบริหารด้วย เพราะมันเกี่ยวกับว่าเราจะไว้ใจให้ AI ทำอะไรแทนเราได้แค่ไหน และเราจะพิสูจน์ได้ยังไงว่ามันทำตามที่สั่งจริง
DPACT อาจยังไม่ใช่คำตอบสุดท้ายของวงการ แต่การที่ Agarwal กล้าชี้ว่าโมเดล token-based แบบเดิมไม่พอสำหรับยุค Agent คือสัญญาณชัดว่าการออกแบบเรื่อง identity และ authorization ต้องถูกยกขึ้นมาเป็นวาระแรกๆ ไม่ใช่ของแถมทีหลัง ใครที่คิดจะปล่อย AI Agent ทำงานจริงโดยยังไม่คิดเรื่องนี้ เท่ากับเอาระบบไปเสี่ยงโดยไม่รู้ตัว
ที่มา: InfoQ AI/ML — อ่านต้นฉบับ
ความคิดเห็น 3
กำลังโหลดความคิดเห็น...