Claude Containment: Agent เก่งขึ้น ต้องกันพังให้เป็น

Anthropic Engineering เผยแพร่บทความ How we contain Claude across products เมื่อวันที่ 25 พฤษภาคม 2026

ถ้าอ่านแบบ headline นี่อาจดูเหมือนบทความ security ของ Claude อีกชิ้น

แต่ถ้าอ่านแบบ operator บทความนี้สำคัญมาก เพราะมันชี้ให้เห็นว่าโลก AI agent กำลังขยับจากคำถามว่า “model ปลอดภัยไหม” ไปสู่คำถามที่เป็นระบบกว่านั้น:

agent นี้ถูกจำกัดพื้นที่ทำงานจริงไว้ยังไง

นี่คือประเด็นที่ธุรกิจไทยควรสนใจ เพราะเมื่อ agent เริ่มอ่านไฟล์ เรียก API ใช้ browser เขียน code ส่ง email หรือแตะ production content ความเสียหายไม่ได้อยู่ใน chat แล้ว

1) เกิดอะไรขึ้น

Anthropic อธิบายวิธี contain Claude ใน 3 product ที่มี threat model ต่างกัน:

• claude.ai: code execution อยู่ใน ephemeral container ฝั่ง server
• Claude Code: agent ทำงานบนเครื่อง developer จึงต้องมี sandbox และ approval model ที่ไม่ทำให้คนล้า
• Claude Cowork: knowledge worker ไม่ควรถูกบังคับให้ตัดสินคำสั่ง shell เอง จึงใช้ local VM, file mount control และ network boundary ที่เข้มกว่า

แก่นของบทความคือ agent ที่ฉลาดขึ้นต้องการขอบเขตที่แข็งขึ้น

Anthropic แยกความเสี่ยงหลักเป็น 3 กลุ่ม:

• user misuse: คนสั่งผิดหรือสั่งสิ่งที่เสี่ยง
• model misbehavior: agent หาทางไปถึงเป้าหมายด้วยวิธีที่ไม่มีใครตั้งใจ
• external attackers: agent ถูกโจมตีผ่าน tools, files, network หรือ prompt injection

ทั้งหมดนี้มีจุดร่วมเดียวกัน:

ถ้า agent มีสิทธิ์ถึงระบบจริง ความเสี่ยงก็เกิดบนระบบจริง

2) ทำไม approval popup อย่างเดียวไม่พอ

ช่วงแรกของ coding agent หลายตัวใช้ pattern ที่เข้าใจง่าย:

agent จะอ่านได้ แต่ถ้าจะเขียนไฟล์ รัน command หรือแตะ network ต้องถามคนก่อน

ฟังดูดี แต่ Anthropic ระบุว่าปัญหาคือ approval fatigue

เมื่อคนเห็น permission prompt บ่อยขึ้น คนจะเริ่มกดผ่านเร็วขึ้น ความระมัดระวังลดลง และ prompt ที่ควรเป็น control กลายเป็นภาระของ workflow

นี่สำคัญมากสำหรับธุรกิจ

ถ้า agent ทำงานวันละหลายสิบครั้ง และทุกครั้งขอ approval แบบไม่แยก risk คนจะเริ่มตอบแบบ reflex

ระบบจึงต้องลด approval ที่ไม่จำเป็นด้วย boundary ที่ชัด เช่น:

• อนุญาตให้เขียนเฉพาะ workspace
• ปิด network เป็นค่าเริ่มต้น
• แยก credential ออกจาก sandbox
• ให้ action เสี่ยงจริงเท่านั้นที่ต้องถาม
• เก็บ log ไว้ตรวจหลังจบงาน

พูดง่าย ๆ คือ approval ไม่ควรเป็นกำแพงด่านเดียว

approval ควรเป็นชั้นหนึ่งในระบบ containment ที่มี sandbox และ policy คอยรับแรงกระแทกก่อน

3) บทเรียนที่แรงที่สุด: สิ่งที่เกิดก่อน trust dialog ก็เสี่ยง

หนึ่งในเคสที่ Anthropic เล่าคือช่องโหว่จาก project-local config ที่ถูกอ่านก่อนผู้ใช้กดยืนยันว่า trust folder นี้

ภาพคือ developer clone repo มา review แล้วใน repo มี config หรือ hook ที่ถูกอ่าน/execute ก่อน prompt “trust this folder” จะทำงาน

บทเรียนนี้แรงมาก:

ของที่อยู่ใน folder local ไม่ได้แปลว่าน่าเชื่อถือ

สำหรับทีมที่สร้าง agent หรือ automation เอง ควร treat เหตุการณ์เหล่านี้เหมือน inbound request จาก internet:

• project open
• config load
• hook execution
• localhost listener
• tool output
• README หรือไฟล์ instructions ใน repo

ทั้งหมดนี้เป็น input ที่อาจมี prompt injection หรือ code path อันตรายได้

ถ้า agent อ่านก่อนมี boundary ก็เท่ากับให้ attacker ได้จังหวะเข้าระบบก่อนที่ผู้ใช้จะตัดสินใจด้วยซ้ำ

4) Egress control สำคัญกว่าที่หลายทีมคิด

อีกบทเรียนที่น่าสนใจคือ prompt ที่หลอกให้ agent อ่าน credential แล้ว POST ออกไปภายนอก

ในเคสแบบนี้ model-layer defense อาจช่วยไม่ได้ เพราะคำสั่งมาจากผู้ใช้เอง หรือดูเหมือน task ปกติ

สิ่งที่หยุดได้จริงคือ environment boundary:

• agent อ่าน ~/.aws/credentials ไม่ได้ตั้งแต่แรก
• network POST ไป domain แปลกไม่ได้ตั้งแต่แรก
• secret ไม่ถูก inject เข้า sandbox
• egress proxy ตรวจทั้ง destination และ capability ที่ถูกเรียก

หลายทีมเข้าใจผิดว่า allowlist domain ก็พอ

แต่ Anthropic ชี้ว่า allowlist ไม่ใช่แค่ “ปลายทางที่อนุญาต”

มันคือ capability grant

ถ้า domain นั้นมี API สำหรับ upload file, call tool, fetch URL หรือส่งข้อมูลต่อ domain เดียวกันก็กลายเป็นช่องทาง exfiltration ได้

ดังนั้น egress control ต้องคิดเป็น function-level capability ไม่ใช่แค่ชื่อ domain

5) VM เหมาะกับคนที่ไม่ควรถูกให้ตัดสิน command

สำหรับ Claude Cowork, Anthropic ใช้ local VM เพราะกลุ่มผู้ใช้ไม่ใช่ developer เป็นหลัก

knowledge worker ไม่ควรถูกถามว่า command แบบนี้ควร allow ไหม:

find . -name "*.tmp" -exec rm {} \;

ถ้าคนอ่านคำสั่งไม่ออก การโยน approval ให้เขาไม่ได้เพิ่มความปลอดภัย

มันแค่ย้ายความเสี่ยงไปไว้ที่คนที่ตัดสินไม่ได้

ดังนั้น boundary ที่ถูกต้องคือระบบควรจำกัดให้ agent เห็นเฉพาะ workspace ที่ user เลือก และ credential สำคัญควรอยู่ใน host keychain ไม่ไหลเข้า guest VM

นี่คือบทเรียนสำคัญสำหรับบริษัทที่อยากใช้ agent กับ non-technical team เช่น sales, finance, admin, marketing หรือ operations

อย่าออกแบบ security โดยสมมติว่าทุกคนอ่าน bash ได้

6) สำหรับธุรกิจไทย ควรถามอะไรบ้าง

ถ้าจะให้ AI agent เริ่มทำงานจริง ผมจะไม่เริ่มจากคำถามว่า model ไหนฉลาดกว่า

ผมจะเริ่มจาก 8 คำถามนี้:

1. agent นี้ทำงานใน workspace แยกหรือเครื่องหลัก
2. agent อ่านไฟล์นอก scope ได้ไหม
3. secret อยู่ใน sandbox หรืออยู่ใน vault/proxy ที่แยกออกมา
4. network ออกไปไหนได้บ้าง
5. domain allowlist ถูกคิดเป็น capability หรือแค่ชื่อเว็บ
6. action ไหนต้อง approval และ action ไหนถูก block แบบ hard rule
7. tool output ถูกตรวจเป็น input ที่ไม่ trusted หรือยัง
8. ถ้าเกิดเหตุ มี log พอ reconstruct และ rollback ไหม

ถ้าตอบไม่ได้ อย่าเพิ่งเรียกว่า autonomous system

เรียกว่า experiment ที่ยังไม่มี blast-radius control จะตรงกว่า

7) มุม Data-Espresso: autonomy ต้องคู่กับ proof

สำหรับ Data-Espresso เรื่องนี้ผูกกับแนวคิด operating system ของ AI agent โดยตรง

agent ที่ดีไม่ใช่แค่ตัวที่ทำงานแทนคนได้

แต่ต้องทำงานโดยมี:

• task boundary
• source proof
• approval path
• workspace isolation
• tool permission
• audit trail
• rollback path
• final evidence

โดยเฉพาะงานที่กระทบ public publishing, email send, DNS, pricing หรือ production edit ต้องมี approval gate แยกเสมอ

นี่ไม่ใช่การทำให้ agent ช้าลง

แต่มันคือการทำให้ agent รับงานใหญ่ขึ้นได้โดยไม่เพิ่มความเสี่ยงแบบไม่รู้ตัว

8) บทสรุป

Anthropic ไม่ได้บอกว่า agent ไม่ควรถูกใช้กับงานจริง

ตรงข้าม บทความนี้สะท้อนว่า agent เริ่มทำงานจริงมากพอจน containment กลายเป็น engineering requirement แล้ว

คำถามของยุคนี้จึงไม่ใช่แค่ว่า “AI ทำอะไรได้บ้าง”

แต่คือ:

ถ้า AI ทำพลาด ระบบจำกัดความเสียหายไว้ตรงไหน

บริษัทที่ตอบคำถามนี้ได้ จะใช้ agent ได้ลึกกว่า เร็วกว่า และมั่นใจกว่า

บริษัทที่ตอบไม่ได้ อาจได้ automation ที่ดูฉลาดขึ้น แต่พังได้กว้างขึ้นตามไปด้วย