ทำไมต้องรัน AI Agent ใน Sandbox — มุมคนทำ model risk เรื่องวงความเสียหาย

เมื่อไม่กี่ปีก่อน AI ที่เราใช้กันคือ "แชตบอต" — มันพิมพ์คำตอบออกมา เราอ่าน แล้วเอาไปทำต่อเอง ความเสียหายสูงสุดที่มันสร้างได้คือ "ตอบผิด" ซึ่งเราจับได้ตอนอ่าน แต่ AI agent ยุคนี้ต่างออกไปสิ้นเชิง — มันรันคำสั่งจริงบนเครื่อง แก้ไฟล์จริง ลบไฟล์จริง ยิง API จริง ติดตั้งของจริง โดยเฉพาะเมื่อเราเปิดโหมดทำงานเองแบบไม่ต้องกดอนุมัติทีละขั้น (เช่น --dangerously-skip-permissions ใน Claude Code) ที่เร็วและลื่นก็จริง แต่แปลว่าเราปล่อยมือจากพวงมาลัยไปแล้ว

ในงานที่ผมทำมาสายวัดความเสี่ยงของโมเดล (model risk) มีคำถามหนึ่งที่ติดตัวจนเป็นนิสัย: เวลาประเมินอะไรก็ตามที่ทำงานอัตโนมัติ อย่าถามแค่ว่า "มันจะพลาดไหม" — เพราะทุกอย่างพลาดได้ทั้งนั้น ให้ถามว่า "ถ้ามันพลาด วงความเสียหายกว้างแค่ไหน และเรากู้กลับได้เร็วแค่ไหน" คำถามนี้แหละที่ทำให้เรื่อง Sandbox ไม่ใช่เรื่องของสาย security เท่ๆ แต่เป็นเรื่องพื้นฐานที่ทุกคนที่ปล่อย AI agent ทำงานเองควรเข้าใจ

Sandbox คืออะไร (แบบสั้นที่สุด)

Sandbox คือสภาพแวดล้อมที่ถูก "ขังไว้" — agent ทำงานข้างในได้เต็มที่ รันอะไรก็ได้ พังอะไรก็ได้ แต่มันแตะของจริงข้างนอกไม่ได้ ในทางปฏิบัติสำหรับคนทำงานทั่วไป Sandbox ที่คุ้มค่าและทำซ้ำง่ายที่สุดคือ container (เช่น Docker) — เปรียบเหมือนให้ agent ทำงานในห้องทดลองที่มีกำแพงกั้น ไม่ใช่ปล่อยให้เดินในบ้านจริงที่มีทั้งเอกสารสำคัญ กุญแจ และปลั๊กไฟเปิดอยู่

หัวใจไม่ได้อยู่ที่เทคโนโลยี แต่อยู่ที่หลักคิด: เราตั้งใจ "ให้สิทธิ์เท่าที่จำเป็น" กับ agent — มันเห็นเฉพาะโฟลเดอร์งานที่เราตั้งใจให้เห็น, ใช้เฉพาะ key ที่เราตั้งใจส่งเข้าไป, และถ้าเราลบ container ทิ้ง ทุกอย่างที่มันทำก็หายไปพร้อมกัน ไม่มีตกค้างบนเครื่องจริง

เหตุผลที่ 1 — จำกัดวงความเสียหาย (blast radius)

นี่คือเหตุผลหลัก และเป็นเหตุผลที่คนทำ risk จะพยักหน้าทันที agent ที่รันเองบนเครื่องจริงของคุณ มีสิทธิ์เท่ากับคุณทุกอย่าง — มันเข้าถึงไฟล์ทุกไฟล์ในบ้านคุณได้ (~/Documents, รูปถ่าย, งานลูกค้า), เห็น key และรหัสที่เก็บไว้ใน ~/.ssh หรือ ~/.aws ได้, และถ้ามันเข้าใจคำสั่งผิดแล้วรัน rm -rf ผิดที่ ของจริงก็หายจริง

คำสั่งพลาดไม่ใช่เรื่องทฤษฎี — มันเกิดจากเหตุง่าย ๆ อย่าง agent เข้าใจ path ผิด, สคริปต์ที่มันเขียนมี bug, หรือมันไปเจอไฟล์ที่มีคำสั่งฝังอยู่แล้วทำตาม (prompt injection) พอรันใน Sandbox วงความเสียหายถูกบีบให้เหลือแค่ "ในกล่อง" — พังได้แค่ของที่เราตั้งใจใส่เข้าไป ไม่ลามไปแตะเครื่องจริง

มุมคนทำ model validation: เราไม่เคยเอาโมเดลใหม่ไปรันกับข้อมูลจริงใน production ตั้งแต่วันแรก เรารันใน environment แยกก่อนเสมอ ดูว่ามันทำอะไรบ้างในสภาพที่คุมได้ Sandbox สำหรับ AI agent ก็คือหลักการเดียวกันเป๊ะ — containment ก่อน แล้วค่อยขยายสิทธิ์เมื่อพิสูจน์แล้วว่าไว้ใจได้ ไม่ใช่ให้สิทธิ์เต็มไว้ก่อนแล้วค่อยหวังว่าจะไม่มีอะไรพัง

เหตุผลที่ 2 — ทำซ้ำได้ และ reset ได้ในคำสั่งเดียว

ผมมีค่านิยมหนึ่งที่ใช้กรองทุกอย่าง: ถ้ามันซับซ้อนหรือทำซ้ำไม่ได้ อย่าเพิ่งเอามาใช้ Sandbox ตอบโจทย์ข้อนี้ตรง ๆ เพราะ container ถูกนิยามด้วยไฟล์ (Dockerfile) — สภาพแวดล้อมที่ agent เจอ เหมือนกันทุกครั้งที่รัน ไม่ใช่ "เครื่องผมลงอะไรไว้เยอะจนจำไม่ได้แล้ว"

ข้อดีที่ตามมาคือ การ reset ที่ถูกมาก ถ้า agent ทำอะไรรก ๆ ทิ้งไว้ หรือทดลองแล้วพัง เราแค่ลบ container ทิ้งแล้วสร้างใหม่ กลับมาสะอาดเอี่ยมในไม่กี่วินาที ไม่ต้องมานั่งไล่เก็บกวาดว่ามันไปแก้อะไรบนเครื่องเราไว้บ้าง ความกล้าที่จะ "ปล่อยให้ agent ลองเต็มที่" มันมาจากตรงนี้ — เพราะเรารู้ว่ากดปุ่ม reset ได้ตลอด

ทำไมมันสำคัญกับเรา: งานที่ทำซ้ำได้ = งานที่ตรวจสอบได้ = งานที่ scale ได้ พอสภาพแวดล้อมเป็นไฟล์ เราส่งต่อให้คนอื่นได้ รันบนเครื่องไหนก็เหมือนกัน และเวลามีอะไรผิดปกติ เราชี้ได้ว่า "ตัวแปรอะไรเปลี่ยน" เพราะมันมีจุดเริ่มที่รู้แน่นอนทุกครั้ง แนวคิดนี้ต่อยอดมาจากที่ผมเขียนไว้เรื่อง ให้ Claude Code ทำงานเอง 24/7 — จะปล่อยให้ agent วิ่งเองยาว ๆ ได้อย่างสบายใจ สภาพแวดล้อมต้อง reset ได้ก่อน

เหตุผลที่ 3 — แยกความลับออกจากตัว agent

agent ทำงานได้ดีต้องมี "ของ" ให้มันใช้ — API key, token, บางทีก็ข้อมูล แต่มีความต่างสำคัญระหว่าง "ส่ง key ที่จำเป็นเข้าไปหนึ่งดอก" กับ "เปิดบ้านทั้งหลังให้มันเดินหยิบเอง" บนเครื่องจริง agent เห็น credential ทุกอย่างที่คุณเคย login ไว้ ทั้งของงาน ของส่วนตัว ของลูกค้า

ใน Sandbox เราเลือกได้ว่าจะส่งอะไรเข้าไป — ใส่เฉพาะ key ที่งานนี้ต้องใช้ ผ่าน environment variable ที่มีอายุแค่ตอนรัน ไม่ mount โฟลเดอร์ที่มีความลับเข้าไปด้วย พอจบงานลบ container ความลับก็ไม่ตกค้าง หลักคิดคือ least privilege — ให้เท่าที่งานต้องใช้ ไม่ให้เผื่อ ซึ่งเป็นหลักเดียวกับที่ผมเขียนไว้ในเรื่อง ใช้ Claude Code กับข้อมูลลับขององค์กร และเป็นข้อที่คนทำงานสายการเงินต้องคิดก่อนแตะข้อมูลจริงทุกครั้ง

ทำจริง: Docker sandbox ที่ก็อปไปใช้ได้เลย

พอแล้วสำหรับหลักการ มาดูของจริง นี่คือ Sandbox ขั้นต่ำสำหรับรัน Claude Code ที่ก็อปไปวางแล้วใช้ได้เลย เริ่มจาก Dockerfile:

FROM node:22-slim

# เครื่องมือพื้นฐานที่ agent ต้องใช้จริง — git, ripgrep สำหรับค้นโค้ด
RUN apt-get update \
 && apt-get install -y --no-install-recommends git ripgrep ca-certificates \
 && rm -rf /var/lib/apt/lists/*

# ติดตั้ง Claude Code
RUN npm install -g @anthropic-ai/claude-code

# ไม่รันเป็น root — ให้ agent เป็น user ธรรมดา (ลดสิทธิ์ลงอีกชั้น)
RUN useradd -m agent
USER agent
WORKDIR /work

จากนั้น build แล้วรัน โดย จุดสำคัญอยู่ที่คำสั่ง docker run — เรา mount เฉพาะโฟลเดอร์งานปัจจุบันเข้าไปที่ /work เท่านั้น ไม่เอาทั้ง home เข้าไป และส่ง key ผ่าน environment variable ไม่ใช่ก็อปไฟล์ลับเข้าไป:

# build ครั้งเดียว
docker build -t claude-sandbox .

# รันในโฟลเดอร์โปรเจกต์ที่ต้องการให้ agent ทำงาน
docker run --rm -it \
  -v "$PWD":/work \
  -e ANTHROPIC_API_KEY="$ANTHROPIC_API_KEY" \
  claude-sandbox claude

อ่านทีละบรรทัดว่าแต่ละอย่างกันอะไร:

• --rm — พอออกจาก container มันลบตัวเองทันที ไม่มีขยะตกค้าง (นี่คือปุ่ม reset ในตัว)
• -v "$PWD":/work — agent เห็น เฉพาะโฟลเดอร์ปัจจุบัน ไฟล์อื่นบนเครื่องมองไม่เห็นเลย นี่คือกำแพงที่บีบ blast radius
• -e ANTHROPIC_API_KEY=... — ส่ง key เข้าไปแบบชั่วคราว ตอนรันเท่านั้น ไม่ได้ฝังในภาพ container
• USER agent ใน Dockerfile — ถึงในกล่องมีอะไรพลาด มันก็ไม่ได้เป็น root

จากจุดนี้จะเข้มขึ้นอีกก็ทำได้ตามงาน เช่น ใส่ --network none ตอนที่งานไม่ต้องต่อเน็ต (agent จะออนไลน์ไม่ได้เลย) หรือจำกัด RAM/CPU ด้วย --memory และ --cpus กันสคริปต์หลุดกินทรัพยากรจนเครื่องค้าง หลักการเดิมทุกข้อ: เปิดให้เท่าที่งานต้องใช้ ปิดที่เหลือไว้ก่อน

มุมคนทำ model validation: สังเกตว่าทั้งหมดนี้ไม่มีอะไรซับซ้อนเลย — Dockerfile สิบบรรทัด กับคำสั่งรันสี่บรรทัด นี่คือจุดที่ผมชอบ เพราะ control ที่ดีที่สุดคือ control ที่คนจะใช้จริง ถ้ามันยุ่งยากเกินไป สุดท้ายคนก็ข้ามแล้วไปรันบนเครื่องจริงอยู่ดี ความปลอดภัยที่ทำซ้ำง่ายเท่านั้นถึงจะได้ใช้จริง

แล้วเมื่อไหร่ที่ยังไม่ต้องลงทุนกับ Sandbox?

จะให้แฟร์ Sandbox มีต้นทุนของมัน — มีขั้นตอน setup, agent เข้าถึงเครื่องมือบางอย่างบนเครื่องแม่ไม่ได้ทันที, และงานที่ต้องต่อกับของบนเครื่องจริงเยอะ ๆ อาจรู้สึกขัด ๆ ตอนแรก ถ้าคุณแค่ให้ AI ช่วยอ่านโค้ดหรือตอบคำถามโดย ไม่เปิดโหมดให้มันรันคำสั่ง/แก้ไฟล์เอง ความเสี่ยงก็ต่ำ ยังไม่จำเป็นต้องมีกล่อง

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

สรุป

AI agent ไม่ใช่แชตบอตอีกต่อไป มันลงมือทำจริง และยิ่งเราปล่อยให้มันทำเองมากเท่าไหร่ คำถามเรื่อง "ถ้าพลาดแล้ววงความเสียหายกว้างแค่ไหน" ก็ยิ่งสำคัญ Sandbox ตอบคำถามนี้ได้ครบสามข้อในกล่องเดียว: จำกัดวงความเสียหาย, ทำซ้ำและ reset ได้ในคำสั่งเดียว, และแยกความลับออกจากตัว agent — โดยที่ต้นทุนคือ Dockerfile สิบบรรทัด

ไม่ต้องรอให้มีเรื่องก่อนถึงจะทำ พรุ่งนี้ที่คุณจะปล่อย agent ทำงานเอง ลองรันมันในกล่องดู แล้วคุณจะกล้าปล่อยให้มันลองเต็มที่กว่าเดิมเยอะ เพราะรู้ว่ากดปุ่ม reset ได้ตลอด

ทั้งหมดนี้คือหลักการที่ก็อปไปตั้งต้นได้ทันที ส่วนของจริงที่ผมใช้ — Sandbox ที่ตั้ง network/resource limit มาให้พร้อม, workflow ที่รัน agent เองยาว ๆ ได้โดยไม่ต้องเฝ้า, และวิธีวางสิทธิ์แบบ least privilege สำหรับงานสายการเงินโดยเฉพาะ — ผมประกอบเป็นแล็บให้ลงมือทำตามทีละขั้นใน คอร์ส Claude Code ตั้งแต่บทแรกที่พาตั้ง Docker sandbox จนรัน agent ได้จริง ถ้าอยากได้ทั้งชุดไปวางทับงานตัวเองเลย