Strands Box คุม AI ก่อนแตะไฟล์และกุญแจบริษัท แต่ยังมีขอบเขตที่ต้องรู้

AWS เปิด Strands Box ให้คุมผู้ช่วย AI ด้วยกฎที่จำประวัติได้ โดยยกตัวอย่างจำกัดการโพสต์ Slack ไว้ 3 ครั้ง แปลว่าอนุญาตให้รายงานงานได้ แต่ห้ามส่งไม่หยุดตามใจเอเจนต์ (AWS) บริษัทประกาศรุ่นทดลองสำหรับนักพัฒนาเมื่อวันที่ 7 ตุลาคม 2026 ยังเป็น developer preview ครับ (AWS)

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

สรุป 30 วินาที: เกิดอะไรขึ้น

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

Strands Box เป็น sandbox หรือพื้นที่ทำงานที่จำกัดว่าโปรแกรมเข้าถึงอะไรได้ โดยใช้ระบบปฏิบัติการช่วยบังคับขอบเขต แล้วเพิ่มกฎกำกับการกระทำภายในนั้น (AWS) โครงการเปิดซอร์สให้ตรวจและพัฒนาต่อภายใต้สัญญาอนุญาต Apache 2.0 แปลว่ามีเงื่อนไขการนำโค้ดไปใช้ที่ระบุไว้ชัดเจน (AWS)

จุดเด่นคือ Dogwood ภาษาสำหรับเขียนกฎอนุญาตหรือปฏิเสธ พร้อม Local Engine ซึ่งเป็นตัวประเมินกฎบนเครื่อง กฎดูทั้งสิ่งที่เอเจนต์ขอทำและประวัติที่บันทึกไว้ (AWS) ส่วนคำว่า harness-agnostic หมายถึงไม่ผูกกับโปรแกรมควบคุมเอเจนต์ยี่ห้อเดียว เอกสารยกชื่อ Strands CLI, Claude Code และ Codex CLI เป็นตัวอย่าง (เอกสาร Strands Box)

ทำไมเรื่องนี้เกี่ยวกับคุณ

ถ้าคุณเป็นพนักงานหรือเจ้าของร้านที่ให้ทีมใช้ AI ช่วยแก้เว็บไซต์ ประเด็นคือทีมเปิดให้มันแตะไฟล์อะไรบ้าง AWS เริ่มจากปัญหาการทำงานแบบ YOLO mode คืออนุมัติทุกการกระทำโดยไม่มีคนตรวจทีละรายการ (AWS) ความสะดวกจึงต้องมาคู่กับขอบเขตที่บังคับจริง ไม่ใช่เพียงข้อความกำชับให้ระวัง

นักศึกษาที่เริ่มใช้ผู้ช่วยเขียนโปรแกรมก็ควรแยกให้ออกว่า การให้แก้โครงการกับการให้เข้าถึงเครื่องทั้งเครื่องต่างกันอย่างไร เอกสาร Box ระบุว่า sandbox จำกัดไฟล์และโปรแกรมที่กระบวนการของเอเจนต์เข้าถึงได้ (เอกสาร Strands Box) คุณจึงควรถามผู้ตั้งค่าว่าเปิดโฟลเดอร์ไหน ไม่ต้องเริ่มจากการท่องชื่อเทคโนโลยีครับ

สำหรับทีมไทยที่รัน coding agent หรือผู้ช่วยเขียนโปรแกรมบนเครื่องตัวเอง Box ตั้งใจทำงานข้างเครื่องมือเดิม โดยไม่ต้องจัดระบบปฏิบัติการอีกชุดไว้ให้มัน (เอกสาร Strands Box) AWS มองว่าการเพิ่มเครื่องเสมือนหรือสภาพแวดล้อมแยกมีภาระดูแล และยังต้องกำหนดสิทธิ์การใช้เครื่องมืออยู่ดี (AWS)

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

ทำงานยังไง

ชั้นแรกเป็นการจำกัดการเข้าถึงด้วย Seatbelt กลไก sandbox ของ macOS ที่บังคับตามสิทธิ์จากไฟล์ตั้งค่า (เอกสาร Strands Box) ชั้นถัดมาเป็น policy หรือกฎตัดสินการกระทำ เช่น จะอ่านไฟล์ เริ่มโปรแกรม หรือส่งคำขอไปบริการภายนอกได้หรือไม่ (AWS)

ไฟล์ box.toml ระบุโปรแกรมเอเจนต์ โฟลเดอร์ทำงาน เครื่องมือ และการผูกข้อมูลสำหรับยืนยันตัวตน ส่วน policy.dw บรรจุกฎ Dogwood (AWS) กฎเป็นแบบ deny-by-default แปลว่าถ้าไม่มีข้ออนุญาตที่ตรงกับการกระทำนั้น ระบบจะปฏิเสธไว้ก่อน (เอกสาร Strands Box)

ในตัวอย่าง Slack ของ AWS หน้าต่างนับย้อนหลังยาว 10 นาที แปลว่ากฎดูเหตุการณ์ในช่วงเวลาที่กำหนด ไม่ได้นับสะสมตลอดงาน (AWS) ตัวอย่างนี้นับการโพสต์ที่ได้คำตอบสำเร็จจากปลายทาง และเอเจนต์ยังอ่านข้อมูลตรวจปัญหาต่อได้ขณะถูกระงับการโพสต์ (AWS) เป็นกฎสาธิตที่ตั้งได้ ไม่ใช่เพดานตายตัวของผลิตภัณฑ์ครับ

การรันคำสั่งผ่าน Shell หรือภาษาสั่งงานบนเครื่อง ใช้ตัวแปลชื่อ Strands Shell ส่วนภาษา Python ใช้ Monty ตัวแปลช่วยส่งการแตะไฟล์และการเรียกเครือข่ายให้ตัวประเมินกฎตรวจ (AWS) MCP คือช่องทางมาตรฐานให้เอเจนต์เรียกเครื่องมือภายนอก และ Box มี broker หรือตัวกลางตัดสินคำขอเหล่านั้นด้วย (เอกสาร Strands Box)

จุดตรวจเหล่านี้ใช้ประวัติร่วมกัน จึงเชื่อมการอ่านไฟล์ผ่านเครื่องมือหนึ่งกับการส่งข้อมูลผ่านอีกเครื่องมือได้ AWS ยกตัวอย่างกฎที่ปิดคำขอเครือข่ายออก หลังอ่านไฟล์จากโฟลเดอร์ข้อมูลลูกค้า (AWS) ขอบเขตของเหตุการณ์ที่บันทึกจึงสำคัญพอๆ กับเนื้อหากฎ

ส่วน egress gateway คือตัวกลางตรวจคำขอที่ออกจาก Box ก่อนส่งต่อบริการภายนอก สำหรับเส้นทาง API ที่ตั้งค่าไว้ มันแทนค่าตัวแทนด้วยข้อมูลลับจริง ทำให้ข้อมูลลับไม่เข้าไปอยู่ในสภาพแวดล้อมของเอเจนต์ (AWS) Credentials ในที่นี้คือข้อมูลยืนยันสิทธิ์ เช่น กุญแจเรียกบริการ ซึ่งควรแยกจากตัวผู้ช่วยที่ทำงาน

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

จุดหักมุม: กฎไม่ได้เห็นทุกการอ่านไฟล์

แต่ถ้าเอเจนต์อ่านไฟล์ผ่านเครื่องมืออ่านไฟล์ที่ติดมากับโปรแกรมควบคุม การอ่านนั้นอาจไม่เข้าประวัติของ policy ครับ ยังมี sandbox จำกัดขอบเขต แต่กฎ Dogwood ไม่เห็นเหตุการณ์นั้น (เอกสาร Strands Box)

อีกด้านคือ Strands Shell, Monty และตัวกลาง MCP ทำงานในกระบวนการของ Box นอก sandbox ของเอเจนต์ AWS ยอมรับว่านี่ทำให้ trusted computing base หรือส่วนโค้ดที่ต้องเชื่อว่าทำงานถูกต้อง มีขอบเขตกว้างขึ้น (AWS) กฎละเอียดขึ้นจึงมาพร้อมส่วนที่ต้องตรวจและไว้วางใจมากขึ้น

เรื่องเงิน / ผลกระทบ

Marc Brooker อธิบายว่ากฎจำกัดจำนวนการเรียกบริการช่วยจัดการ API ที่คิดเงินหรือมีโควตาได้ (Marc Brooker) แต่แหล่งที่ให้มายังไม่มีผลทดสอบว่าทีมไทยจะลดค่าใช้จ่ายได้เท่าไร จึงไม่ควรแปลคำว่า “คุมการเรียก” เป็น “รับประกันบิลถูกลง” โดยอัตโนมัติ

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

ผลกระทบเรื่องข้อมูลลับมีเงื่อนไขสำคัญ เอกสารระบุว่าเอเจนต์ เครื่องมือ และเซิร์ฟเวอร์ MCP ใน Box เดียวกัน ใช้การผูกข้อมูลยืนยันสิทธิ์ที่ประกาศใน Box นั้นได้ (เอกสาร Strands Box) ถ้ากระบวนการใดต้องไม่มีสิทธิ์ใช้ข้อมูลยืนยันตัวตนชุดนั้น เอกสารให้แยกไปอีก Box การไม่เห็นค่ากุญแจจริงจึงไม่เท่ากับไม่มีสิทธิ์ใช้กุญแจครับ (เอกสาร Strands Box)

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

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

ฝั่งสนับสนุนจาก AWS เสนอว่าการแยกพื้นที่เพียงอย่างเดียวไม่พอ ต้องควบคุมการใช้เครื่องมืออย่างมีบริบทด้วย (AWS) ฝั่งทักท้วงจาก Marc Brooker ซึ่งอธิบายการออกแบบของโครงการเอง ยอมรับว่าโค้ดที่ต้องเชื่อถือมากขึ้นเพิ่มโอกาสมีบั๊ก และบั๊กอาจทำให้ข้ามกฎได้ (Marc Brooker) นี่เป็นข้อแลกเปลี่ยนที่ผู้พัฒนายอมรับ ไม่ใช่เสียงคัดค้านอิสระที่เราควรแต่งเพิ่ม

The Register ใช้หัวข่าววาง Strands Box ในมุมป้องกันปัญหาจาก YOLO mode (The Register) อย่างไรก็ดี ข้อความที่ได้รับมีหัวข่าวและคำอธิบายสั้น ไม่มีเนื้อข่าวเต็ม จึงใช้ยืนยันได้เพียงมุมหัวข่าว ไม่ใช้ยืนยันประสิทธิภาพหรือสวมความเห็นผู้เชี่ยวชาญให้สื่อครับ

เรื่องเครือข่ายมีขอบเขตที่ต้องอ่านให้ครบ AWS อธิบายว่าคำขอออกผ่าน gateway โดยค่าเริ่มต้น (AWS) เอกสารลงรายละเอียดว่าเครื่องมือและเซิร์ฟเวอร์ MCP ภายในเครื่อง อาจตั้ง network.contain_egress = false เพื่อยกเว้นเส้นทางนี้ได้ (เอกสาร Strands Box) จึงไม่ใช่ข้อมูลขัดกันโดยตรง แต่คำอธิบายภาพรวมไม่พอให้สรุปว่าทุกการตั้งค่าจะมีการตรวจเหมือนกัน

เรื่องระบบที่รองรับ ประกาศเริ่มจาก macOS และบอกว่าจะขยายระบบปฏิบัติการเป็นลำดับถัดไป โดยยังไม่ให้วันเปิด (AWS) เอกสารระบุ macOS 15 ขึ้นไป แปลว่ารุ่นเก่ากว่านั้นอยู่นอกช่วงที่ระบุ และต้องเป็นเครื่อง Apple silicon (เอกสาร Strands Box) Linux ยังไม่รองรับ ส่วน Windows ระบุว่าไม่รองรับ จึงยังนัดวันให้ทีมใช้ข้ามระบบไม่ได้ (เอกสาร Strands Box)

เรื่องความง่ายและความพร้อม Brooker ยอมรับว่ากฎอาจอ่านและเขียนยาก และเป็นเรื่องที่ต้องลงทุนปรับปรุง (Marc Brooker) AWS วางแผนเครื่องมือช่วยสร้างไฟล์ตั้งค่ากับกฎเริ่มต้น แต่ยังเป็นงานถัดไป ไม่ใช่เหตุผลให้ถือว่า preview พร้อมใช้ทุกสถานการณ์แล้ว (AWS) ถ้ากฎดูครบ แต่ประวัติไม่เห็นการอ่านไฟล์บางทาง เราจะมั่นใจเงื่อนไขหลังอ่านข้อมูลได้แค่ไหน?

สำหรับการเทียบกับ GitHub Copilot local sandboxing ที่เคยเล่าไว้ ประเด็นที่บทความนี้ยืนยันได้คือ Box เพิ่มกฎตามประวัติข้ามเครื่องมือ ส่วนชุดแหล่งข่าวนี้ไม่พอให้เทียบความสามารถของ Copilot รายข้อ (AWS) อีกสิ่งที่ยังไม่มีคือเลขเวอร์ชันผลิตภัณฑ์และหลักฐานทดสอบอิสระในข้อความที่ได้รับ จึงเรียกตามสถานะ developer preview เท่านั้น

แล้วเราควรทำอะไร

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

คนทั่วไป เจ้าของร้าน และคนดูแลงานทีม — ทำตามได้เลย

1. ขอให้ผู้ตั้งค่าแสดงโฟลเดอร์ เครื่องมือ และบริการที่อนุญาต อย่าใช้คำว่า “มี sandbox แล้ว” เป็นคำตอบแทนรายการสิทธิ์ เพราะขอบเขตการเข้าถึงมาจากการตั้งค่า (เอกสาร Strands Box)
2. เริ่มด้วยโครงการที่ไม่มีข้อมูลอ่อนไหว ใช้ข้อมูลทดสอบแทนข้อมูลลูกค้า และกำหนดคนตรวจสิ่งที่ AI แก้ไว้ก่อนนำไปใช้จริง นี่เป็นข้อเสนอสำหรับการลอง preview ของผม
3. อย่าใส่รหัสลับของระบบจริงในสภาพแวดล้อมเอเจนต์ ให้ทีมใช้การแนบข้อมูลยืนยันสิทธิ์นอกเอเจนต์ตามเส้นทางที่รองรับ แล้วตรวจสิทธิ์ปลายทางด้วย (AWS)

ทีม IT และนักพัฒนา — ทำตามได้เลย

1. ตรวจว่าเครื่องอยู่ในช่วงรองรับ แล้วอ่านคู่มือเริ่มต้นก่อนเลือกโปรแกรมเอเจนต์ อย่าเหมารวมว่าการไม่ผูกยี่ห้อหมายถึงใช้ได้ทุกระบบปฏิบัติการ (เอกสาร Strands Box)
2. แยกหน้าที่ box.toml กับ policy.dw ให้ชัด เขียนกฎแบบปฏิเสธไว้ก่อน แล้วเปิดเฉพาะงานที่จำเป็น การประกาศข้อมูลยืนยันสิทธิ์ไม่ได้อนุญาตให้เข้าถึงปลายทางเครือข่ายโดยตัวมันเอง (AWS)
3. ตรวจเครื่องมืออ่านและเขียนไฟล์ที่เอเจนต์ใช้ หากต้องการให้ policy ตัดสินทุกการเปลี่ยนไฟล์ เอกสารแนะนำให้ใช้ shell เป็นเครื่องมือจัดการไฟล์เพียงทางเดียว (เอกสาร Strands Box)
4. ทดสอบทั้งงานที่ควรผ่านและงานที่ควรถูกปฏิเสธในโครงการทดสอบ แล้วตรวจบันทึกการตัดสิน Box มีบันทึกอนุญาตและปฏิเสธลงไฟล์ในเครื่อง จึงควรใช้ตรวจว่ากฎทำงานตามเจตนา (เอกสาร Strands Box)
5. ตรวจการยกเว้น gateway และแยก Box เมื่อเครื่องมือไม่ควรใช้ชุดสิทธิ์เดียวกัน หากนำขึ้นคลาวด์ให้หลายผู้ใช้ร่วมระบบ Brooker แนะนำเพิ่ม MicroVM หรือเครื่องเสมือนขนาดเล็กแยกต่อเซสชันด้วย (เอกสาร Strands Box, Marc Brooker)

ผมมองว่า…

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

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

ปิดท้าย: สิ่งที่ต้องจับตา

สิ่งที่เราควรเรียกร้องจากผู้ช่วย AI คือขอบเขตที่ตรวจสอบได้ทุกครั้งที่มันลงมือทำงาน ต่อจากนี้ให้จับตาการขยายระบบปฏิบัติการ และเครื่องมือช่วยสร้างการตั้งค่าเริ่มต้นตามแผน AWS ซึ่งยังไม่ระบุวันเปิดในแหล่งที่ได้รับ (AWS)

ถ้าทีมคุณจะให้ AI ช่วยแก้เว็บไซต์ของร้าน คุณอยากห้ามมันแตะโฟลเดอร์หรือบริการไหนเป็นอย่างแรก?

Recap

• เกิดอะไรขึ้น: AWS เปิด Strands Box รุ่นทดลองสำหรับนักพัฒนา เพื่อใช้ sandbox คู่กับกฎ Dogwood ตามประวัติการกระทำ (1)
• ตัวเลขที่จำ: เพดานโพสต์ 3 ครั้ง เป็นตัวอย่างของ AWS แปลว่าผู้ตั้งกฎกำหนดจำนวนได้เอง (1)
• ช่วงเวลาของตัวอย่างคือ 10 นาที แปลว่ากฎนับย้อนหลังตามเวลาที่กำหนด ไม่ใช่โควตาถาวร (1)
• ใครทักท้วง: Brooker ยอมรับส่วนโค้ดที่ต้องเชื่อถือกว้างขึ้น ส่วนเอกสารเตือนว่าการอ่านไฟล์โดยตรงบางทางไม่เข้าประวัติ policy (2, 4)
• ยังไม่รู้: วันรองรับ Linux และระบบอื่น ต้นทุนรวมในไทย และผลทดสอบอิสระจากข้อความที่ได้รับ
• กระทบคุณ: ตรวจโฟลเดอร์และสิทธิ์ก่อนใช้กับงานร้านหรือบริษัท ลองโครงการที่ไม่มีข้อมูลอ่อนไหว และไม่ใส่ข้อมูลลับระบบจริงในเอเจนต์
• ต้องจับตา: การรองรับระบบเพิ่มและเครื่องมือช่วยสร้างกฎเริ่มต้นตามแผน AWS (1)
• แหล่งอ่าน: 1 AWS · 2 Marc Brooker · 3 The Register — ใช้เฉพาะหัวข่าว · 4 เอกสาร Box