𝗧𝗵𝗲 𝗦𝗮𝗳𝗲𝘀𝘁 𝗕𝗼𝘂𝗻𝗱𝗮𝗿𝘆 𝗜𝘀 𝗧𝗵𝗲 𝗢𝗻𝗲 𝗧𝗵𝗲 𝗔𝗴𝗲𝗻𝘁 𝗖𝗮𝗻'𝘁 𝗥𝗲𝗮𝗰𝗵 𝗔𝗰𝗿𝗼𝘀𝘀

หาก AI agent ต้องดูแลโครงสร้างพื้นฐานให้กับหลายองค์กร ความปลอดภัยจะกลายเป็นฝันร้ายทันที

อันตรายไม่ได้อยู่ที่การที่เอเจนต์ทำความผิดพลาดที่ชาญฉลาด แต่อยู่ที่การที่เอเจนต์ทำเรื่องธรรมดาๆ ให้กับผิดคน

การเขียน ticket หรือการหมุนเวียน secret ให้กับลูกค้า B แทนที่จะเป็นลูกค้า A ถือเป็นการละเมิดข้อมูล (breach) คุณไม่สามารถ "ปะ" รอยรั่วของการละเมิดได้ แต่คุณต้องเปิดเผยมันออกมา

คนส่วนใหญ่พยายามแก้ปัญหานี้ด้วยการกำหนดสิทธิ์ (permissions) พวกเขาจะสร้างรายการสิ่งที่เอเจนต์สามารถเข้าถึงได้ และตรวจสอบทุกการกระทำเทียบกับรายการนั้น

วิธีนี้ล้มเหลว เพราะการกำหนดสิทธิ์ตั้งอยู่บนสมมติฐานว่าทรัพยากรนั้นมีตัวตนอยู่จริง แล้วคุณค่อยสั่งปฏิเสธ หากกฎของคุณมีบั๊กหรือมีกรณีที่ตกหล่น เอเจนต์ก็จะเข้าถึงข้อมูลที่ผิดพลาดได้

ผมใช้โมเดลที่ต่างออกไป ผมทำให้ข้อมูลที่ผิดพลาด "ไม่มีตัวตนอยู่เลย" ในเชิงโครงสร้าง

ในเซสชัน (session) ของลูกค้า A ทรัพยากรของลูกค้า B จะไม่มีตัวตนอยู่เลย Credentials จะไม่ถูกโหลดขึ้นมา Endpoints ก็ไม่อยู่ในแผนผัง เมื่อไม่มีอะไรให้ร้องขอ ก็ไม่มีอะไรให้ต้องปฏิเสธ

กฎเกณฑ์อาจมีบั๊ก แต่โครงสร้างทางกายภาพของระบบนั้นไม่มี

ผมเรียนรู้เรื่องนี้ด้วยบทเรียนที่ราคาแพง ผมเคยคิดว่าแค่มี secrets manager ก็เพียงพอแล้ว ผมเคยคิดว่าการแยก secrets ออกจากกันจะช่วยแยก tenant ออกจากกันได้ แต่ผมคิดผิด

Secrets manager ช่วยแยกความลับออกจากกัน แต่ไม่ได้แยก endpoints ออกจากกัน เอเจนต์อาจจะมี token ที่ถูกต้องสำหรับลูกค้า A แต่ยังคงส่งคำขอไปยังที่อยู่ของลูกค้า B ได้ หากที่อยู่นั้นอยู่ในไฟล์กำหนดค่า (configuration)

รอยรั่วไม่ได้อยู่ที่ความลับ แต่อยู่ที่การกำหนดเส้นทาง (routing)

ผมแก้ไขเรื่องนี้ด้วยการผูกทรัพยากรทุกอย่างเข้าด้วยกันเป็นหนึ่งเรคคอร์ด (record): • Resource • Endpoint • Credential • Owning tenant

คุณไม่สามารถเข้าถึงที่อยู่ได้หากไม่เข้าถึงเจ้าของ Library ที่ส่งข้อมูลจะปฏิเสธการทำงานหาก tenant ไม่ตรงกับ session คุณไม่สามารถใช้วิธี hardcode เพื่อเลี่ยงเรื่องนี้ได้ เพราะที่อยู่จะมีตัวตนขึ้นมาก็ต่อเมื่อมันถูกเชื่อมติดกับเจ้าของของมันเท่านั้น

ผมใช้การป้องกันสามชั้น:

  • การแยกเชิงโครงสร้าง (Structural isolation) เพื่อไม่ให้ข้อมูลที่ผิดพลาดมีตัวตนอยู่
  • การบล็อกการข้ามขั้นตอน (Bypass block) เพื่อไม่ให้เอเจนต์ใช้เครื่องมือดิบ (raw tools) เพื่อข้ามการตรวจสอบ
  • การจำกัดขอบเขตการส่งข้อมูลออก (Egress scoping) เพื่อให้เซสชันสามารถสื่อสารได้เฉพาะกับที่อยู่ที่ได้รับอนุญาตเท่านั้น

สิ่งนี้สร้างระบบที่ "fails closed" (ล้มเหลวแบบปิด)

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

แต่ขอบเขตของ tenant นั้นต่างออกไป หากเอเจนต์ไม่แน่ใจว่ากำลังแตะต้องข้อมูลของใคร มันต้องหยุดทันที

ความไม่แน่นอนในการกระทำนำไปสู่การเคลื่อนไหว ความไม่แน่นอนในความเป็นเจ้าของต้องนำไปสู่ความหยุดนิ่ง

อย่าสร้างระบบตรวจสอบที่คอยบอกว่า "ไม่" จงกำจัดรูปแบบที่จำเป็นต้องถูกตรวจสอบออกไป

ที่มา: https://dev.to/artemmatviychuk/the-safest-boundary-is-the-one-the-agent-cant-reach-across-20ad

ชุมชนแห่งการเรียนรู้ (ไม่บังคับ): https://t.me/GyaanSetuAi