RBAC ที่เข้ากันได้กับ AI
ทำไมการควบคุมการเข้าถึงแบบดั้งเดิมจึงล้มเหลวเมื่อ AI agents ทำงานแทนผู้ใช้ และวิธีที่ Edison Watch บังคับใช้ขอบเขตข้อมูลโดยติดตามกลุ่มผู้รับต้นทาง
ฟีเจอร์ Alpha: RBAC ที่เข้ากันได้กับ AI อยู่ในระหว่างการพัฒนาอย่างแข็งขัน ฟีเจอร์และ API อาจมีการเปลี่ยนแปลง สำหรับการวิเคราะห์เต็มรูปแบบ ดูที่ Agentic AI Disrupts Traditional Data Security Posture
การเรียกเครื่องมือ MCP ไม่มีตัวตนการเข้าถึงของ backend เมื่อ agent อ่านเอกสาร Google Drive การตอบกลับมีเนื้อหาของไฟล์แต่ไม่มี ใครได้รับอนุญาตให้ดู เมื่อ agent ส่งอีเมลในภายหลัง การเรียกมีผู้รับแต่ไม่มีอะไรเชื่อมโยงกลับไปยังรายการการเข้าถึงของเอกสารต้นทาง RBAC แบบดั้งเดิมหยุดที่การยืนยันตัวตน - ไม่เคยติดตามว่า กลุ่มผู้รับปลายทาง เป็นส่วนย่อยของ กลุ่มผู้รับต้นทาง หรือไม่
ปัญหา
Agent ที่เชื่อมต่อกับ Google Drive และ Gmail สามารถ อ่าน เอกสารที่แชร์กับผู้ใช้ A และ B จากนั้น ส่ง เนื้อหาไปยังผู้ใช้ C จากมุมมองของผู้ให้บริการตัวตน ไม่มีการละเมิดเกิดขึ้น - ข้อมูลรับรองของ Alice เข้าถึงไฟล์ของ Alice และส่งอีเมลของ Alice แต่ข้อมูลไปถึงคนที่อยู่นอกรายการการเข้าถึงเดิม
สาเหตุหลัก: การเรียกเครื่องมือ MCP ไม่ส่งต่อรายการควบคุมการเข้าถึงของข้อมูลที่ส่งคืน เซสชันของ agent ทำให้ทุกอย่างแบนลงเป็นบริบทเดียวโดยไม่มีความทรงจำว่าใครได้รับอนุญาตให้ดูอะไร
ทำไมนี่เป็นภัยคุกคามเฉพาะ AI
แอปพลิเคชันแบบดั้งเดิมบังคับใช้ RBAC ที่ชั้น API - แต่ละคำขอถูกจำกัดขอบเขตเป็นหนึ่งผู้ใช้ หนึ่งทรัพยากร หนึ่งการกระทำ AI agents ทำลายโมเดลนี้เพราะ:
- การสะสมบริบท - agent อ่านจากหลายแหล่งในหนึ่งเซสชัน ผสมข้อมูลที่มีการควบคุมการเข้าถึงเข้าไปในหน้าต่างบริบทเดียว
- การไหลของข้อมูลโดยปริยาย - เมื่อ agent สรุปข้อมูลจากแหล่ง A ลงในข้อความที่ส่งผ่านเครื่องมือ B ไม่มีการ "คัดลอก" อย่างชัดเจนให้ DLP ตรวจจับ
- การยุบรวมตัวตน - agent ทำหน้าที่เป็นผู้ใช้หนึ่งคนแต่จัดการข้อมูลที่มีขอบเขตการเข้าถึงหลายระดับ
วิธีที่ Edison Watch แก้ปัญหานี้
Edison Watch ขยาย Lethal Trifecta ด้วย การติดตามต้นทางและปลายทางของข้อมูล เพื่อบังคับให้ผู้รับเป็นส่วนย่อยที่เข้มงวดของผู้ที่มีสิทธิ์อ่านข้อมูลต้นทาง
การติดตามต้นทาง - เมื่อ agent อ่านจากแหล่ง (Drive, Confluence, OneDrive) Edison จะบันทึกรายการการเข้าถึงของทรัพยากรนั้น: ใครสามารถดูข้อมูลนี้ได้
การตรวจสอบปลายทาง - เมื่อ agent พยายามส่งข้อมูล (อีเมล ข้อความ Slack แชร์ไฟล์) Edison จะหาชุดผู้รับและตรวจสอบ: ผู้รับทุกคนอยู่ในรายการการเข้าถึงเดิมหรือไม่? ถ้าไม่ การกระทำจะถูกบล็อก
การบังคับใช้ส่วนย่อย - กฎนั้นง่าย: ผู้รับ ⊆ ผู้อ่านต้นทาง ถ้าผู้ใช้ C ไม่อยู่ในรายการการเข้าถึงของเอกสารที่ agent อ่าน การส่งจะถูกปฏิเสธ - แม้ว่า Alice เองจะมีสิทธิ์ส่งอีเมลถึง C
สิ่งนี้ไปไกลกว่า Lethal Trifecta มาตรฐาน (ที่ตั้งค่าสถานะหมวดหมู่ความเสี่ยงแบบกว้าง) โดยทำการตัดสินใจที่แม่นยำ ต่อการกระทำ บนพื้นฐานของตัวตนจริงที่เกี่ยวข้อง