ความลับที่ไม่ควรหลุดออกไป

ครั้งหนึ่งเราเปิด log ของ daemon ตัวหนึ่ง (โปรแกรมที่รันค้างอยู่เบื้องหลังตลอดเวลา) บนเครื่อง เห็นว่ามีค่า secret ปนอยู่ในนั้น เลยกรองทิ้งก่อนด้วยคำสั่งสั้น ๆ ที่จับ pattern KEY= กับ TOKEN= แล้วแทนที่ด้วยคำว่า redacted คิดว่าเรียบร้อยแล้ว

แต่พอข้อความออกมา ค่า key จริงสองตัวกลับโผล่เต็ม ๆ อยู่ใน transcript ตัวที่หลุดชื่อ ANTHROPIC_API_KEY_FALLBACK= กับ CLAUDE_CODE_OAUTH_TOKEN_BAD= เพราะชื่อลงท้ายด้วย _FALLBACK= กับ _BAD= ไม่ได้ลงท้ายด้วย KEY= หรือ TOKEN= ตรง ๆ pattern เลยจับไม่โดนสักตัว

ความลับไม่ได้หลุดไปหา hacker ที่ไหน หลุดเข้า transcript ของเราเองนี่แหละ ที่ที่ตอนนั้นไม่ได้นับว่าเป็น "ข้างนอก" แต่จริง ๆ นี่คือข้างนอก secret ที่พิมพ์ลง log ไปแล้ว ต้องถือว่าหลุดทันที แล้วก็ต้องเปลี่ยน key ใหม่

บทเรียนของเรื่องนี้ไม่ได้อยู่ที่ sed เขียนพลาด อยู่ที่ ข้อมูลมักรั่วตรงรอยต่อที่เราลืมติดป้าย ต่างหาก ไม่ใช่ตรงจุดที่เราเฝ้าระวังอยู่แล้ว

ช่วงที่ 1ด่านป้องกัน 3 ชั้น: ความรู้เข้ามาได้ แต่ความลับห้ามออก

AI ที่เราใช้กันทุกวันนี้ ฐานความรู้อยู่บนคลาวด์ของคนอื่น คุณถามอะไรไป โมเดลก็ตอบกลับมาจากความรู้กว้าง ๆ ของโลก ตรงนี้ไม่มีปัญหา ความรู้สาธารณะเอาเข้ามาใช้ได้เต็มที่

ปัญหาเริ่มตอนข้อมูลเดินทางย้อนกลับ พอคุณส่งข้อมูลส่วนตัวออกไป โมเดลไม่ได้แค่อ่านเพื่อตอบเฉย ๆ ข้อมูลก้อนนั้นออกจากเครื่องคุณไปอยู่ในระบบของคนอื่นเรียบร้อยแล้ว แล้วจะรู้ได้ยังไงว่าอะไรส่งออกไปได้ อะไรห้าม วิธีที่เราใช้คือแบ่งข้อมูลออกเป็น 3 ชั้น

• ชั้นนอกสุดคือคลาวด์ ความรู้ของโลกที่โมเดลมีอยู่แล้ว ถามเรื่องทั่วไปได้สบาย ไม่มีอะไรของคุณอยู่ในนั้น
• ชั้นกลางคือข้อมูลงานที่แชร์ได้ เอกสารสาธารณะ บริบทโปรเจกต์ที่เปิดเผยได้อยู่แล้ว ถ้าออกไปข้างนอกก็ยังพอรับได้
• ชั้นในสุดคือความลับ ข้อมูลการเงิน ข้อมูลสุขภาพ ข้อมูลลูกค้า credential ทั้งหลาย ชั้นนี้มีกฎข้อเดียว ห้ามออกไปชั้นนอกเด็ดขาด

หลักของด่านนี้คือข้อมูลเดินทางทางเดียว ความรู้จากชั้นนอกเอาเข้ามาช่วยงานคุณได้เต็มที่ แต่ของในชั้นในห้ามออกไปข้างนอก พอวางกฎทิศทางไว้แบบนี้ คำถามยาก ๆ อย่าง "อันนี้ป้อนให้ AI ได้ไหม" ก็กลายเป็นคำถามง่ายขึ้นเยอะ เหลือแค่ถามว่าของชิ้นนี้อยู่ชั้นไหน

ช่วงที่ 2จุดรั่วที่คุณไม่ทันคิด

จุดที่เห็นชัดที่สุดคือการก๊อปข้อความลับไปแปะในแชต AI ตรง ๆ อันนี้ทุกคนพอจะระวังกันอยู่แล้ว แต่จุดที่เนียนกว่านั้นคือพวกขั้นตอน "ประมวลผลให้อัตโนมัติ" ที่เรามองไม่เห็น

ยกตัวอย่างใกล้ตัวเราเอง ระบบความจำของ agent ที่เราใช้อยู่จริงชื่อ Graphiti เวลาบันทึกงานหนึ่งก้อน จะมีโมเดลตัวเล็กคอยอ่านเนื้อหาดิบของก้อนนั้นเพื่อสกัดเอาข้อเท็จจริงออกมา ขั้นตอน "อ่านเพื่อสกัด" นี่แหละคือจุดที่ข้อมูลออกนอกเครื่อง (egress) และในสแต็กที่เราใช้อยู่จริง โมเดลตัวเล็กที่ทำหน้าที่อ่านนี้ก็รันอยู่บนคลาวด์ เนื้อหาดิบของคุณก็ออกไปตั้งแต่ตอนนั้นเลย ทั้งที่คุณแค่สั่งให้ "จำ" เฉย ๆ ไม่ได้ตั้งใจส่งอะไรขึ้นไป เพราะแบบนี้ เราถึงนับเรื่อง "โมเดลตัวไหนเป็นคนอ่าน อ่านอยู่ที่ไหน" เป็นเรื่องระดับชั้นใน

จุดสุดท้ายคือพวก log กับ transcript เหมือนเรื่อง key ที่หลุดตอนต้น ข้อมูลไม่ได้รั่วไปหาคนร้าย แต่ไหลไปกองในที่ที่เราไม่เคยจัดว่าเป็นชั้นนอก ทั้งที่จริงตรงนั้นก็คือชั้นนอก ใครเข้าถึง log ได้ ก็เห็นของในชั้นในของคุณหมด

ช่วงที่ 3ทำให้เป็นด่านจริง ไม่ใช่แค่ความตั้งใจ

การตัดสินตามสัญชาตญาณพาไป ไม่นับว่าเป็นด่านป้องกัน ของที่ทำให้กลายเป็นของจริงมีสามอย่าง

1. แยกข้อมูลตามชั้นตั้งแต่ตอนออกแบบ ไม่ใช่มาแยกทีหลัง ตอนทำระบบที่เก็บข้อมูลส่วนบุคคลจริง ๆ เราเรียนมาแล้วว่าการแยกข้อมูลตามวัตถุประสงค์ ต้องเป็นโครงสร้างตั้งแต่วันแรก เพราะข้อมูลแต่ละแบบมีกฎไม่เหมือนกัน บางอย่างลบได้ทันทีที่เจ้าของถอนความยินยอม บางอย่างกฎหมายสั่งให้เก็บไว้ 5 ถึง 7 ปี ถ้าเอามากองรวมโต๊ะเดียว พอต้องลบทีก็พังทั้งกอง
2. ตั้งค่าให้ fail-closed ถ้าพิสูจน์ไม่ได้ว่าข้อมูลก้อนนี้จะไปจบที่ไหน ให้ถือว่ามันจะออกไปชั้นนอกไว้ก่อน แล้วกั้นไว้ ไม่ใช่ปล่อยผ่านเพราะ "ยังไม่เห็นว่าจะมีปัญหา" กฎเดียวกับเรื่องสิทธิ์การเข้าถึง คือถ้ายืนยันไม่ได้ว่าใครมีสิทธิ์ ให้ปฏิเสธไว้ก่อน ปลอดภัยกว่าเดาแล้วเปิดให้
3. กรองข้อมูลจาก "ตัวตน" ของมัน ไม่ใช่จากหน้าตา ย้อนกลับไปเรื่อง key ที่หลุด รากของปัญหาคือเรากรองจากรูปแบบตัวอักษร KEY= แทนที่จะกรองจากความหมายว่า "ตัวแปรนี้คือความลับ" พอจัดประเภทของจากสิ่งที่มันเป็นจริง ๆ ชื่อแปลก ๆ อย่าง _FALLBACK ก็หลุดตาข่ายไปไม่ได้

ส่วนวิธีต่อสายจริง ๆ ให้ด่านป้องกัน 3 ชั้นทำงานอัตโนมัติในระบบ เป็นงาน implementation อีกชั้นที่เราขอเก็บไว้ก่อน แต่หลักการทั้งสามข้อข้างบนเอาไปใช้ได้เลยวันนี้ ไม่ต้องรอเครื่องมือพิเศษอะไร

ช่วงที่ 4คำถามเดียวที่ใช้ได้กับทุกเครื่องมือ

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