การทำ Sandbox Isolation สำหรับ AI Agent คือวิธีการรักษาความปลอดภัยโดยการจำกัด AI Agent ที่สามารถรันโค้ดหรือเครื่องมือต่างๆ ได้ด้วยตนเอง ให้อยู่ในสภาพแวดล้อมที่ถูกแยกส่วน (Isolated Environment) ซึ่งมีการจำกัดการเข้าถึงไฟล์ กระบวนการ (Process) และเครือข่าย เพื่อป้องกันการเข้าถึงข้อมูลภายในบริษัทหรือข้อมูลรับรอง (Credentials) โดยไม่ได้รับอนุญาต เนื่องจาก AI Agent สามารถตัดสินใจและดำเนินการได้ด้วยตนเอง การสั่งห้ามเพียงอย่างเดียวว่า "ห้ามทำอะไร" จึงไม่เพียงพอ แต่จำเป็นต้องจำกัดขอบเขตการทำงานผ่านตัวสภาพแวดล้อมเองด้วย

บทความนี้จัดทำขึ้นสำหรับเจ้าหน้าที่ฝ่ายระบบสารสนเทศ/ฝ่ายความปลอดภัยที่รับผิดชอบด้านการนำ AI Agent มาใช้งานในองค์กรญี่ปุ่น โดยจะอธิบายตั้งแต่เหตุผลที่จำเป็นต้องมีการแยกส่วน ไปจนถึงขั้นตอนการติดตั้ง 3 ขั้นตอน ได้แก่ สภาพแวดล้อมการทำงาน (Execution Environment), เครือข่าย (Network) และบันทึกการตรวจสอบ (Audit Log) เมื่ออ่านบทความนี้จบ คุณจะสามารถออกแบบได้ว่า "ควรปิดกั้นอะไร และที่เลเยอร์ไหน" สำหรับ AI Agent ขององค์กรคุณ

เอเจนต์อิสระ (Autonomous Agents) จะ "ตัดสินใจและดำเนินการด้วยตนเองภายในขอบเขตอำนาจที่มนุษย์กำหนดให้" ดังนั้นเมื่อเกิดการทำงานที่ไม่คาดคิด ความเสียหายที่เกิดขึ้นจึงมีขนาดใหญ่ ก่อนอื่น เราต้องทำความเข้าใจถึงภัยคุกคามเฉพาะของเอเจนต์อิสระ และเหตุผลว่าทำไมการควบคุมเพียงแค่ในระดับแอปพลิเคชัน (App Layer) ถึงไม่เพียงพอที่จะป้องกันได้

AI エージェントは、ツール実行・ファイル読み書き・外部通信といった強力な能力を組み合わせて動く。この能力が攻撃者や誤動作によって悪用されると、主に 3 つの脅威につながる。

• データ持ち出し: เอเจนต์ส่งเนื้อหาในไฟล์ภายในองค์กรหรือฐานข้อมูลที่สามารถเข้าถึงได้ออกไปยังภายนอก
• 認証情報の窃取: อ่าน API Key หรือ Token ที่อยู่ในตัวแปรสภาพแวดล้อม (Environment Variables) หรือไฟล์ตั้งค่า แล้วนำไปใช้โจมตีแบบเคลื่อนที่ในแนวราบ (Lateral Movement) ไปยังระบบอื่น
• 権限昇格: ใช้ช่องโหว่บนโฮสต์ที่รันอยู่หรือสิทธิ์ที่มากเกินไปเป็นฐานในการเข้าถึงทรัพยากรที่ไม่ควรเข้าถึงได้

สิ่งที่น่ากังวลเป็นพิเศษคือ Indirect Prompt Injection หากข้อมูลภายนอกหรือหน้าเว็บที่เอเจนต์อ่านเข้ามามีการฝังคำสั่งที่เป็นอันตรายไว้ เอเจนต์อาจเข้าใจผิดว่าเป็น "คำสั่งที่ถูกต้อง" และดำเนินการตามที่ระบุไว้ข้างต้นได้ ทั้งนี้ OWASP ได้รวบรวมความเสี่ยงเฉพาะของแอปพลิเคชัน LLM ไว้ ซึ่งสามารถใช้ OWASP LLM Top 10 に学ぶ AI セキュリティ เป็นจุดเริ่มต้นในการศึกษาแนวทางป้องกันได้

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

ตัวอย่างเช่น ข้อห้ามใน Prompt อาจถูกเขียนทับด้วยการทำ Prompt Injection ที่แยบยล หากแอปพลิเคชันมีการตรวจสอบที่หลุดรอดไป ก็อาจทำให้ Path ของไฟล์หรือคำสั่งที่ไม่คาดคิดสามารถทำงานได้ และหากโครงสร้างของ Agent อนุญาตให้รันโค้ดตามอำเภอใจได้ ก็จะยิ่งทำให้การควบคุมในระดับแอปพลิเคชันถูกข้ามไปโดยสิ้นเชิง

ด้วยเหตุนี้ นอกเหนือจากการควบคุมแบบ "ขอความร่วมมือ" ในระดับแอปพลิเคชันแล้ว จึงจำเป็นต้องมีการป้องกันแบบหลายชั้น (Defense in Depth) ในระดับ OS และเครือข่าย เพื่อสร้างสภาวะที่ "ไม่สามารถรันได้หรือเข้าถึงไม่ได้ตั้งแต่แรก" การแยกส่วนด้วย Sandbox ถือเป็นปราการด่านสุดท้ายที่สำคัญที่สุด ซึ่งควรทำความเข้าใจควบคู่ไปกับ คู่มือการใช้งานความปลอดภัย LLM ว่ามาตรการเหล่านี้จะมีความหมายก็ต่อเมื่อนำไปใช้ร่วมกับการพัฒนาแอปพลิเคชันที่ปลอดภัยเท่านั้น

การแยกส่วนแบบ Sandbox สามารถจัดระเบียบได้ง่ายหากพิจารณาจากโดเมนการป้องกัน 4 ด้าน ได้แก่ "ไฟล์ (File)", "กระบวนการ (Process)", "เครือข่าย (Network)" และ "นโยบายสิทธิ์ (Permission Policy)" ก่อนที่จะเข้าสู่ขั้นตอนการติดตั้งใช้งาน เรามาดูภาพรวมกันก่อนว่าแต่ละส่วนทำหน้าที่ปกป้องอะไรบ้าง

โดเมนแรกคือการจำกัดไฟล์ที่เอเจนต์สามารถเข้าถึงได้และกระบวนการที่สามารถดำเนินการได้ ในสภาพแวดล้อม Linux สามารถทำได้โดยใช้ฟังก์ชันของ OS kernel ดังนี้:

• Landlock: กลไกความปลอดภัยของ Linux ที่จำกัดไฟล์และไดเรกทอรีที่แต่ละโปรเซสสามารถเข้าถึงได้ (เปิดตัวใน kernel 5.13) จุดเด่นคือไม่จำเป็นต้องใช้สิทธิ์ root ต่างจาก SELinux และโปรเซสที่ไม่มีสิทธิ์พิเศษก็สามารถจำกัดสิทธิ์ของตนเองได้ ซึ่งช่วยให้สามารถควบคุมไม่ให้เอเจนต์อ่านหรือเขียนข้อมูลนอกเหนือจากไดเรกทอรีที่กำหนดไว้ได้
• seccomp: กลไกสำหรับจำกัด system call ที่โปรเซสสามารถเรียกใช้ได้ โดยจะบล็อก system call ที่ไม่จำเป็น (เช่น ระบบเครือข่ายบางประเภทหรือการจัดการสิทธิ์) เพื่อลดช่องทางในการโจมตี

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

โดเมนที่สองคือการสื่อสาร (Communication) การนำข้อมูลออกและการแพร่กระจายของข้อมูลรับรอง (Credential) มักเกิดขึ้นผ่านเครือข่ายเป็นส่วนใหญ่ ดังนั้น การจำกัดการสื่อสารจากสภาพแวดล้อมการทำงานของ Agent ให้เหลือเพียง "ปลายทางที่จำเป็นเท่านั้น" จึงเป็นวิธีที่มีประสิทธิภาพ

โดยเฉพาะอย่างยิ่ง ควรปฏิเสธการสื่อสารภายนอกทั้งหมดโดยค่าเริ่มต้น (Default Deny) และเพิ่มเฉพาะปลายทางที่จำเป็นต่อการทำงาน (เช่น LLM API ที่ใช้งาน หรือบริการภายในองค์กรที่ได้รับอนุญาต) ลงในรายการที่อนุญาต (Allowlist) เท่านั้น ในกรณีที่ Agent ต้องเชื่อมต่อกับเครื่องมือหรือแหล่งข้อมูลภายนอก ก็ควรจำกัดปลายทางในการเชื่อมต่อด้วยเช่นกัน

แม้ในการกำหนดค่าที่ใช้ MCP ซึ่งเป็นมาตรฐานสำหรับการเชื่อมต่อเครื่องมือภายนอก การควบคุมเพิ่มเติมในระดับเครือข่ายว่า "อนุญาตให้เข้าถึงเครื่องมือใดและปลายทางใดได้บ้าง" จะช่วยป้องกันความผิดพลาดจากการตั้งค่าในฝั่งนิยามของเครื่องมือได้ เนื่องจากตัวการเรียกใช้งานโมเดลเองก็ถือเป็นการสื่อสารรูปแบบหนึ่ง การกำหนดปลายทางที่ใช้งานให้คงที่และปิดกั้นการส่งข้อมูลไปยังปลายทางที่ไม่คาดคิด จึงเป็นทางลัดในการป้องกันการรั่วไหลของข้อมูลรับรองและข้อมูลที่เป็นความลับ

ในฐานะโดเมนที่สามและสี่ เราจะใช้แนวคิดการกำหนดนโยบายสิทธิ์แบบ "เชิงประกาศ" (Declarative) และการดำเนินงานโดยยึดหลักสิทธิ์ขั้นต่ำ (Least Privilege) โดยคำว่า "เชิงประกาศ" หมายถึงการเขียนกฎการอนุญาตหรือการห้ามไว้อย่างชัดเจนในไฟล์การตั้งค่า เป็นต้น แทนที่จะพึ่งพาเงื่อนไขการตัดสินใจ (Conditional Branching) ที่กระจัดกระจายอยู่ตามส่วนต่างๆ ของโค้ด

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

ข้อดีของการใช้ "นโยบายเชิงประกาศ × สิทธิ์ขั้นต่ำ" มี 2 ประการ ประการแรกคือ สามารถตรวจสอบและทำ Audit ได้ง่ายเนื่องจากขอบเขตการอนุญาตถูกแสดงไว้ในรายการที่ชัดเจน ประการที่สองคือ การเพิ่มหรือลบสิทธิ์สามารถทำได้เสร็จสิ้นผ่านการแก้ไขการตั้งค่า ทำให้สามารถติดตามประวัติการเปลี่ยนแปลงได้ สำหรับการสร้างโครงสร้างองค์กรเพื่อรองรับการดำเนินงาน สามารถศึกษาเพิ่มเติมได้ที่ AgentOps (การออกแบบองค์กรสำหรับปฏิบัติการ AI Agent)

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

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

• ไฟล์หรือไดเรกทอรีใดที่ต้องอ่านและเขียน
• บริการภายนอกหรือ API ใดที่ต้องเชื่อมต่อ
• คำสั่งหรือเครื่องมือใดที่จำเป็นต้องเรียกใช้งาน
• ข้อมูลที่จัดการมีข้อมูลส่วนบุคคลหรือข้อมูลลับรวมอยู่ด้วยหรือไม่

ความแม่นยำในการตรวจสอบรายการเหล่านี้จะเป็นตัวกำหนดคุณภาพของการออกแบบสิทธิ์ในขั้นตอนถัดไป ข้อผิดพลาดที่พบบ่อยคือ "การให้สิทธิ์แบบกว้างๆ ไว้ก่อน" ซึ่งถือเป็นสิ่งที่ตรงกันข้ามกับหลักการสิทธิ์ขั้นต่ำ (Principle of Least Privilege) การตั้งค่าให้จำกัดไว้ก่อนตั้งแต่แรกแล้วค่อยๆ เพิ่มเฉพาะส่วนที่จำเป็นต่อการทำงาน จะส่งผลให้ได้โครงสร้างที่ปลอดภัยกว่าในท้ายที่สุด สำหรับความเสี่ยงเรื่องการเพิ่มขึ้นของเอเจนต์ที่อยู่นอกเหนือการควบคุมในหน้างาน ควรศึกษาเพิ่มเติมได้ที่ ความเสี่ยงและการจัดการ Shadow AI

ควบคู่ไปกับการตรวจสอบสิทธิ์ (Permission Inventory) ให้ดำเนินการระบุ "สินทรัพย์ที่ต้องปกป้อง" โดยเป็นการตรวจสอบว่ามีข้อมูลสำคัญที่รั่วไหลไม่ได้อยู่ในสภาพแวดล้อมการทำงานของ Agent หรือบริเวณใกล้เคียงหรือไม่

• ข้อมูลรับรอง (Credentials) เช่น API Key, Token, รหัสผ่าน
• ข้อมูลส่วนบุคคล เช่น ข้อมูลลูกค้า, ข้อมูลพนักงาน
• เอกสารลับ เช่น เอกสารการออกแบบ, สัญญา, ข้อมูลทางการเงิน

โดยเฉพาะข้อมูลรับรองที่มักถูกเก็บไว้ในรูปแบบข้อความธรรมดา (Plain text) ในตัวแปรสภาพแวดล้อม (Environment variables) หรือไฟล์การตั้งค่า ซึ่งหากอยู่ในตำแหน่งที่ Agent สามารถอ่านได้ จะทำให้ความเสี่ยงเพิ่มสูงขึ้นทันที หลักการพื้นฐานคือการแยกไปไว้ในระบบจัดการความลับ (Secret Management) เพื่อไม่ให้มองเห็นได้จากไดเรกทอรีการทำงานของ Agent สำหรับบริษัทญี่ปุ่นที่ดำเนินธุรกิจในกลุ่มประเทศอาเซียน การจัดการข้อมูลส่วนบุคคลจะต้องอยู่ภายใต้กฎหมายคุ้มครองข้อมูลของแต่ละท้องถิ่นด้วย สำหรับการจัดระเบียบธรรมาภิบาลเมื่อขยายธุรกิจไปยังหลายประเทศ โปรดดูที่ การสร้างกรอบธรรมาภิบาล AI สำหรับบริษัทที่ขยายธุรกิจสู่อาเซียน

ขั้นตอนที่ 1 คือการรัน Agent ใน "กล่องแบบใช้แล้วทิ้ง" (disposable box) ที่แยกออกจากสภาพแวดล้อมการทำงานจริง (production environment) โดยให้เลือกระหว่าง Container หรือ MicroVM พร้อมทั้งตั้งค่าขอบเขตของไฟล์และกระบวนการ (process boundaries) ให้เรียบร้อย

การแยกสภาพแวดล้อมในการทำงาน (Execution environment isolation) มักใช้ Container หรือ MicroVM เป็นพื้นฐาน โดยทั้งสองแบบมีข้อแลกเปลี่ยนระหว่างความแข็งแกร่งในการแยกส่วน (Isolation) กับต้นทุนในการเริ่มต้นทำงาน (Startup cost)

โดยสรุปแล้ว หากต้องจัดการกับโค้ดหรือคำสั่งจากภายนอกที่ต้องการการแยกส่วนที่เข้มงวด MicroVM คือตัวเลือกพื้นฐาน แต่หากเป็นการใช้งานภายในองค์กรที่เน้นประสิทธิภาพในการเริ่มต้นทำงาน Container จะเป็นตัวเลือกหลัก ในกรณีที่ใช้ Container ควรใช้มาตรการควบคุมร่วมด้วย เช่น ไม่รันด้วยสิทธิ์ Root, ปิดการใช้งานฟังก์ชันที่ไม่จำเป็น (Capabilities) และใช้ระบบไฟล์แบบอ่านอย่างเดียว (Read-only filesystem) เป็นค่าเริ่มต้น ไม่ว่าจะใช้วิธีใด การสร้างสภาพแวดล้อมใหม่สำหรับแต่ละงานและทิ้งไปหลังใช้งานเสร็จ (Disposable) จะช่วยป้องกันไม่ให้สิ่งตกค้างจากงานก่อนหน้าส่งผลกระทบต่องานถัดไป ซึ่งมีความปลอดภัยมากกว่า

เมื่อเตรียมสภาพแวดล้อมแบบแยกส่วน (Isolated environment) เรียบร้อยแล้ว ให้จำกัดขอบเขตของไฟล์และกระบวนการ (Process) ภายในนั้นให้แคบลงอีก โดยใช้ Landlock และ seccomp ที่กล่าวถึงข้างต้นในการตั้งค่าดังนี้:

• ขอบเขตของไฟล์ (File boundaries): อนุญาตให้อ่านและเขียนได้เฉพาะในไดเรกทอรีการทำงานของ Agent เท่านั้น ส่วนพื้นที่อื่น (พื้นที่ระบบ, ข้อมูลของผู้ใช้อื่น, ที่เก็บข้อมูลรับรองความถูกต้อง) จะต้องไม่สามารถเข้าถึงได้
• ขอบเขตของกระบวนการ (Process boundaries): ใช้ seccomp เพื่อบล็อก System call ที่ไม่จำเป็น เพื่อป้องกันไม่ให้มีการเริ่มกระบวนการหรือจัดการสิทธิ์ที่ไม่ได้คาดคิด

หัวใจสำคัญของการตั้งค่าคือการใช้ "วิธีการอนุญาตเฉพาะรายการ" (Allowlist approach) โดยเริ่มจากการห้ามทุกอย่างไว้ก่อน แล้วจึงเปิดเฉพาะสิ่งที่จำเป็นต่อการทำงานจริงเท่านั้น หากใช้วิธีการห้ามเฉพาะรายการ (Blocklist approach) ซึ่งเป็นการบล็อกสิ่งที่ดูอันตรายเป็นรายกรณีไป มักจะหลงเหลือสิ่งที่ลืมบล็อกไว้เสมอ หลังจากตั้งค่าเสร็จแล้ว ให้ลองรันงานปกติของ Agent ให้ครบถ้วน จากนั้นตรวจสอบผ่าน Log ว่ามีการอนุญาตการเข้าถึงที่จำเป็นอย่างครบถ้วนและพอดีหรือไม่ รวมถึงตรวจสอบว่าการเข้าถึงที่ไม่คาดคิดถูกปฏิเสธแล้วหรือไม่

ขั้นตอนที่ 2 คือการจำกัดการสื่อสารจากสภาพแวดล้อมของ Agent ด้วยวิธี "ปฏิเสธโดยค่าเริ่มต้น + รายการอนุญาต (Default Deny + Allowlist)" เนื่องจากการนำข้อมูลออกและการแพร่กระจายของข้อมูลรับรอง (Credential) ส่วนใหญ่ต้องผ่านการสื่อสาร จุดนี้จึงเป็นหัวใจสำคัญของมาตรการป้องกันข้อมูลรั่วไหล

เครือข่ายนโยบาย (Network Policy) ควรเริ่มต้นด้วยการปฏิเสธการเชื่อมต่อทั้งหมดเป็นค่าเริ่มต้น (รวมถึงทิศทางการส่งข้อมูลออก) จากนั้นจึงเพิ่มเฉพาะปลายทางที่จำเป็นต่อการดำเนินงานลงในรายการอนุญาต (Allowlist)

ปลายทางทั่วไปที่ควรอยู่ในรายการอนุญาตมีดังนี้:

• เอนด์พอยต์ของ LLM API ที่ใช้งาน
• บริการภายในองค์กรที่เอเจนต์เชื่อมต่อด้วย
• แหล่งข้อมูลภายนอกที่ได้รับอนุญาตให้เข้าถึง

การอนุญาตควรจำกัดให้เหลือน้อยที่สุด โดยไม่เพียงแค่ระบุ "โดเมน/IP" เท่านั้น แต่ต้องรวมถึง "พอร์ต" และ "โปรโตคอล" ด้วย การอนุญาตช่วงกว้างในคราวเดียวอาจกลายเป็นช่องทางในการรั่วไหลของข้อมูลได้ สิ่งที่ควรระวังคือการจัดการกับ DNS หรือบริการที่ดูเหมือนไม่มีอันตราย หากอนุญาตสิ่งเหล่านี้โดยไม่มีเงื่อนไข อาจเปิดช่องให้ถูกใช้เป็นเส้นทางในการส่งข้อมูลออกไปภายนอกทีละน้อยได้ รายการอนุญาตควรได้รับการตรวจสอบอย่างสม่ำเสมอ และควรมีกระบวนการลบปลายทางที่ไม่ได้ใช้งานออกอยู่เสมอ

เมื่อนำ Network Policy (รวมถึง Permission Policy โดยทั่วไป) มาใช้งาน การบังคับใช้ (Enforce) แบบเต็มรูปแบบในทันทีอาจมีความเสี่ยงที่จะทำให้การทำงานหยุดชะงัก ดังนั้น จึงควรเลือกใช้โหมด Audit (บันทึกการละเมิดแต่ยังอนุญาตให้ผ่านได้) สลับกับโหมด Enforce อย่างเหมาะสม

• โหมด Audit: ในขั้นแรกจะยังไม่มีการบล็อก แต่จะทำการบันทึกการละเมิดนโยบายไว้ เพื่อให้เห็นภาพชัดเจนว่า "อะไรบ้างที่จะถูกปฏิเสธ" ในการทำงานจริง และตรวจสอบว่ามีการรวมการสื่อสารที่ถูกต้องตามกฎหมายเข้าไปด้วยหรือไม่
• โหมด Enforce: เมื่อตรวจสอบผ่านโหมด Audit แล้วว่าไม่มีปัญหา จึงค่อยเปลี่ยนไปสู่การใช้งานจริงที่บล็อกการละเมิดนั้นๆ

การเปลี่ยนผ่านตามขั้นตอนเช่นนี้จะช่วยหลีกเลี่ยงอุบัติเหตุที่ว่า "นโยบายเข้มงวดเกินไปจนงานหยุดชะงัก" และช่วยให้สามารถบรรลุการควบคุมที่รัดกุมได้ในที่สุด บันทึก (Log) ที่เก็บไว้ในขั้นตอน Audit ยังสามารถนำมาใช้เป็นข้อมูลในการปรับปรุงรายการอนุญาต (Allowlist) ได้อีกด้วย แม้จะเปลี่ยนไปใช้โหมด Enforce แล้ว ก็ควรเก็บ Log ของ Audit ไว้ต่อไปเพื่อเฝ้าระวังการพยายามสื่อสารที่ไม่คาดคิด

ขั้นตอนที่ 3 คือการรวมบันทึกการตรวจสอบ (Audit Log) ที่สามารถติดตามการทำงานของเอเจนต์ย้อนหลัง และกลไกการอนุมัติโดยมนุษย์ก่อนดำเนินการที่มีความเสี่ยงสูง นี่คือชั้นที่รับมือกับความเสี่ยงที่เหลืออยู่ผ่านการดำเนินงาน หลังจากที่ได้จำกัด "ขอบเขตที่ทำได้" ด้วยการแยกส่วน (Isolation) แล้ว

監査ログ (Audit Log) には、エージェントが「何をしようとし、許可されたか／拒否されたか」を記録する。最低限、次の情報を残しておきたい。

• いつ・どのエージェントが
• どの操作（ファイルアクセス・通信・コマンド実行）を試みたか
• ポリシーにより許可されたか拒否されたか
• 拒否の場合、どのルールに該当したか

この allow/deny の証跡があると、インシデント発生時の追跡（何が起きたか）と、ポリシー改善（どこが過不足か）の両方に使える。ログは改ざんされにくい場所に集約し、エージェント自身が書き換えられない構成にする。運用組織としてログを継続的に見直す体制づくりはAgentOps の設計が参考になる。

แม้การแยกส่วน (Isolation) และนโยบายจะช่วยป้องกันปัญหาได้มาก แต่ก็ยังคงมีการดำเนินการที่ "ต้องการให้ทำได้ แต่ถ้าผิดพลาดจะส่งผลกระทบสูง" หลงเหลืออยู่ เช่น การลบข้อมูลจริง, การส่งข้อมูลออกภายนอก, หรือการดำเนินการที่เกี่ยวข้องกับการชำระเงินและสัญญา ซึ่งการดำเนินการเหล่านี้จำเป็นต้องมีมนุษย์เข้ามาตรวจสอบและอนุมัติ (Human-in-the-Loop: HITL)

หลักการออกแบบพื้นฐานคือการแบ่งประเภทการดำเนินการตามระดับความเสี่ยง:

• การดำเนินการอัตโนมัติ: การดำเนินการที่มีความเสี่ยงต่ำและสามารถแก้ไขได้ (เช่น การดูข้อมูล, การสร้างฉบับร่าง)
• การดำเนินการที่ต้องผ่านการอนุมัติ: การดำเนินการที่มีความเสี่ยงสูงและย้อนกลับได้ยาก (เช่น การส่งข้อมูล, การลบข้อมูล, การยืนยันรายการ)

ตัวอย่างการนำขั้นตอนการอนุมัติไปใช้งานจริง สามารถดูได้จากบทความเรื่อง การใช้งาน MCP Tool ของ AI Agent ภาษาลาวและการทำ HITL ซึ่งอธิบายถึงการนำการตรวจสอบโดยมนุษย์มาผนวกเข้ากับการใช้งานเครื่องมือ หากกำหนดให้มีการอนุมัติมากเกินไปจะทำให้การดำเนินงานติดขัด ดังนั้นจึงควรออกแบบโดยจำกัดเฉพาะ "การดำเนินการที่สร้างความเสียหายได้จริง" เท่านั้น เพื่อเรียกให้มนุษย์เข้ามาตรวจสอบ นอกจากนี้ การนำเสนอเนื้อหาและขอบเขตผลกระทบของการดำเนินการนั้นๆ พร้อมกับบันทึก (Log) จะช่วยให้ผู้อนุมัติสามารถตัดสินใจได้อย่างรวดเร็วและแม่นยำ

นี่คือรายการข้อผิดพลาดที่มักพบในการนำ Sandbox Isolation มาใช้ พร้อมแนวทางแก้ไข

ข้อผิดพลาดที่ 1: การแยกส่วน (Isolation) หละหลวมเกินไปจนไม่มีความหมาย คือกรณีที่ "แค่ใส่ไว้ในคอนเทนเนอร์" แต่ภายในยังคงอนุญาตให้มีสิทธิ์สูงหรือสื่อสารได้อย่างอิสระ แนวทางแก้ไขคือ ต้องยึดหลักสิทธิ์ขั้นต่ำ (Least Privilege) และการปฏิเสธโดยค่าเริ่มต้น (Default Deny) โดยอนุญาตให้ใช้งานได้เฉพาะสิ่งที่ระบุไว้ในรายการอนุญาต (Allowlist) เท่านั้น

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

ข้อผิดพลาดที่ 3: ข้อมูลรับรอง (Credentials) ถูกเปิดเผยจาก Agent คือกรณีที่มีการวางคีย์แบบ Plaintext ไว้ในตัวแปรสภาพแวดล้อม (Environment Variables) หรือไฟล์ตั้งค่า ซึ่งสามารถอ่านได้จากภายในสภาพแวดล้อมที่แยกส่วน แนวทางแก้ไขคือ ให้แยก Secret ออกไปไว้ในระบบจัดการเฉพาะ และทำให้ไม่สามารถมองเห็นได้จากไดเรกทอรีการทำงาน

ข้อผิดพลาดที่ 4: ไม่มีการบันทึก Log หรือ Log ถูกแก้ไขได้ คือกรณีที่ไม่สามารถตรวจสอบได้ว่าเกิดอะไรขึ้นเมื่อเกิดเหตุการณ์ไม่คาดคิด หรือตัว Agent เองสามารถแก้ไข Log ได้ แนวทางแก้ไขคือ ให้รวบรวม Audit Log ไว้ภายนอกและทำให้ไม่สามารถแก้ไขได้

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

Q1. แค่ใส่ไว้ในคอนเทนเนอร์ก็เพียงพอแล้วหรือยัง? การทำ Containerization เป็นเพียงจุดเริ่มต้นเท่านั้น ซึ่งบ่อยครั้งยังไม่เพียงพอ หากยังคงมีการรันด้วยสิทธิ์ root, การให้ Capability ที่มากเกินความจำเป็น หรือการอนุญาตให้สื่อสารกับภายนอกได้อย่างอิสระ ความเสียหายก็สามารถเกิดขึ้นภายในคอนเทนเนอร์ได้ การจะเรียกว่า "การแยกส่วน" (Isolation) ได้นั้น ต้องครอบคลุมถึงการกำหนดสิทธิ์ขั้นต่ำ (Least Privilege), การปฏิเสธโดยค่าเริ่มต้น (Default Deny) และการตั้งค่าขอบเขตของไฟล์/กระบวนการทำงานด้วย

Q2. สำหรับทีมขนาดเล็ก จำเป็นต้องทำถึงขนาดนี้เลยหรือ? ให้ตัดสินจากความละเอียดอ่อนของข้อมูลที่จัดการ หากเป็นเอเจนต์ที่ต้องเข้าถึงข้อมูลส่วนบุคคลหรือข้อมูลรับรอง (Credentials) ไม่ว่าทีมจะมีขนาดเท่าใด ก็ควรมีการแยกส่วนขั้นพื้นฐาน (สิทธิ์ขั้นต่ำ, การจำกัดการสื่อสาร, บันทึกการตรวจสอบ) หากไม่แน่ใจว่าควรเริ่มจากตรงไหน สามารถเริ่มจากรายการตรวจสอบในบทความ มาตรการรับมือความเสี่ยงทางไซเบอร์สำหรับ AI ในธุรกิจขนาดกลางและขนาดย่อม เพื่อจัดระเบียบความคิดได้ง่ายขึ้น

Q3. ถ้าใช้ Managed Service บนคลาวด์ จำเป็นต้องแยกส่วนอีกไหม? แม้จะเป็นสภาพแวดล้อมแบบ Managed แต่ความรับผิดชอบในการออกแบบสิทธิ์, ขอบเขตการสื่อสาร และการเข้าถึงข้อมูลที่ให้กับเอเจนต์ยังคงเป็นของผู้ใช้งาน ควรแยกแยะระหว่างความแข็งแกร่งของโครงสร้างพื้นฐานกับการออกแบบสิทธิ์ที่บริษัทกำหนดขึ้นเอง และควรดำเนินการจัดระเบียบสมมติฐานรวมถึงการออกแบบนโยบายตามบทความนี้

Q4. การแยกส่วนจะทำให้ประสิทธิภาพของเอเจนต์ลดลงหรือไม่? หากออกแบบอย่างเหมาะสม การเข้าถึงที่จำเป็นต่อการทำงานจะยังคงได้รับอนุญาต ทำให้ประสิทธิภาพในการทำงานจริงแทบไม่เปลี่ยนแปลง สิ่งที่จะกลายเป็นปัญหาไม่ใช่ประสิทธิภาพ แต่เป็น "การอนุญาตที่มากหรือน้อยเกินไป" ดังนั้น การตรวจสอบการเข้าถึงที่จำเป็นในโหมด audit ก่อนที่จะเปลี่ยนไปใช้โหมด enforce จึงเป็นวิธีที่เหมาะสมในทางปฏิบัติ

การแยกส่วน AI Agent ไว้ใน Sandbox เป็นรากฐานสำคัญในการปกป้องข้อมูลภายในและข้อมูลรับรอง (Credentials) จากเอเจนต์ที่ทำงานแบบอัตโนมัติ เนื่องจากการควบคุมในระดับ Prompt และแอปพลิเคชันอาจถูกเจาะได้ การป้องกันเชิงลึก (Defense in Depth) ในระดับ OS, เครือข่าย และนโยบายสิทธิ์การเข้าถึง เพื่อสร้างสภาวะที่ "ไม่สามารถรันหรือเข้าถึงได้ตั้งแต่ต้น" จึงเป็นสิ่งที่ขาดไม่ได้

การนำไปปฏิบัติสามารถแบ่งออกเป็น 3 ขั้นตอน ได้แก่ การแยกสภาพแวดล้อมการทำงานด้วย Container/MicroVM และจำกัดขอบเขตของไฟล์และกระบวนการ (ขั้นตอนที่ 1) การควบคุมเครือข่ายด้วยนโยบายปฏิเสธการเชื่อมต่อโดยค่าเริ่มต้น (Default Deny) และใช้รายการอนุญาต (Allowlist) (ขั้นตอนที่ 2) และการรวมบันทึกการตรวจสอบ (Audit Log) เข้ากับการอนุมัติโดยมนุษย์สำหรับปฏิบัติการที่มีความเสี่ยงสูง (ขั้นตอนที่ 3) ทั้งหมดนี้ตั้งอยู่บนหลักการพื้นฐานเดียวกัน คือ การให้สิทธิ์เท่าที่จำเป็น (Least Privilege), การปฏิเสธโดยค่าเริ่มต้น (Default Deny) และการเปลี่ยนผ่านจากการตรวจสอบ (Audit) ไปสู่การบังคับใช้ (Enforce)

สำหรับบริษัทญี่ปุ่นที่ดำเนินธุรกิจในกลุ่มประเทศ ASEAN จำเป็นต้องมีการออกแบบที่คำนึงถึงกฎหมายคุ้มครองข้อมูลส่วนบุคคลของแต่ละท้องถิ่นด้วย บริษัทของเราพร้อมสนับสนุนการนำ AI Agent ไปใช้งานอย่างปลอดภัยและการจัดทำธรรมาภิบาล หากท่านต้องการออกแบบร่วมกับเราว่า "ควรปิดกั้นอะไรในระดับใด" สำหรับเอเจนต์ของบริษัทท่าน สามารถติดต่อสอบถามเราได้ทันที