
อธิบาย AI Blue Teaming: สามชั้นที่มาตรการควบคุมสามารถอยู่ได้จริง
- Orcaใหม่Orca: OrcaCyber Ultra 1.02026-10-17$5.00 / $10.00 ต่อ 1 ล้านโทเค็น · 11 tok/s
- deepseekใหม่DeepSeek: DeepSeek V4.1 Flash 10172026-10-1745ความฉลาด
- DeepSeekใหม่DeepSeek: DeepSeek V4.1 Flash2026-10-1740ความฉลาด
- Orcaใหม่Orca: OrcaCyber Zero 1.52026-10-10$3.00 / $7.50 ต่อ 1 ล้านโทเค็น · 137 tok/s
- openaiOpenAI: GPT-6.1 Sol2026-09-2952ความฉลาด
- anthropicAnthropic: Claude Sonnet 5.52026-09-2856ความฉลาด
- typesafeTypeSafe: Jev 1.132026-09-24$0.04 / $0.00 ต่อ 1 ล้านโทเค็น · 1012 tok/s
- OpenAIOpenAI: GPT-6 Luna2026-09-2238ความฉลาด
- OpenAIOpenAI: GPT-6 Sol2026-09-2248ความฉลาด
- AnthropicAnthropic: Claude Opus 5.52026-09-2258ความฉลาด
- xAIGrok 4.72026-09-2146ความฉลาด
- OrcaOrca: OrcaCyber Zero 1.02026-09-17$3.00 / $7.50 ต่อ 1 ล้านโทเค็น · 50 tok/s
- OrcaOrca: OrcaVerify Text 1.02026-09-16$2.00 / $0.00 ต่อ 1 ล้านโทเค็น · 826 tok/s
- OpenAIOpenAI: GPT-6 Astra2026-09-0453ความฉลาด77การเขียนโค้ด
- GoogleGoogle: Gemini 3.8 Flash2026-09-0241ความฉลาด76การเขียนโค้ด
- AlibabaQwen: Qwen3.8 Max (0902)2026-09-0245ความฉลาด76การเขียนโค้ด
- AnthropicAnthropic: Claude Fable 5.12026-09-0153ความฉลาด82การเขียนโค้ด
- TencentTencent: Hy4 preview2026-08-28$0.83 / $2.50 ต่อ 1 ล้านโทเค็น · 47 tok/s
- AlibabaQwen: Qwen3.8 Flash2026-08-26$0.15 / $0.47 ต่อ 1 ล้านโทเค็น · 94 tok/s
- z-aiZ.ai: GLM 5.3 Flash2026-08-2642ความฉลาด72การเขียนโค้ด
ถามทีมความปลอดภัยว่า guardrails ของ AI อยู่ที่ไหน คำตอบมักระบุชื่อเอกสารนโยบาย พรอมต์ระบบ หรือฟีเจอร์จากผู้ขาย ไม่มีสิ่งใดในนั้นเป็น control ที่แท้จริง control คือสิ่งที่ตัดสิน ณ ขณะเกิดการกระทำ ว่าการกระทำนั้นจะเกิดขึ้นหรือไม่ — และสำหรับเอเจนต์ AI มีเพียงสามตำแหน่งที่สามารถตัดสินได้ ได้แก่ โมเดล เกตเวย์ที่อยู่ด้านหน้าโมเดล และสภาพแวดล้อมรอบตัวมัน ทุกสิ่งที่ทีม blue team ให้สัญญาได้อย่างซื่อตรงล้วนมาจากสองตำแหน่งหลังนั้น นี่คือคำถามเรื่องเลเยอร์ และมันมาก่อนการตัดสินใจอื่นทุกอย่างของ blue team รวมถึงว่าจะบันทึกอะไรเป็น log และจะเรียกหาใคร นอกจากนี้ยังเป็นเหตุผลว่าทำไมหลักฐานภาคสนามจึงสำคัญ: คลังเหตุการณ์ AI มีเหตุการณ์ของเอเจนต์ 400 เหตุการณ์ตั้งแต่ 2024-12 ถึง 2026-10-17 และส่วนใหญ่ไม่ใช่เรื่องราวของโมเดลที่ประพฤติตัวไม่ดี แต่เป็นเรื่องราวของการติดตั้งใช้งานที่ไม่มีเลเยอร์ใดเลยที่สามารถบอกว่า “ไม่” ได้
การทำ Blue teaming ในความหมายของ AI คือการติดตั้งเลเยอร์เหล่านั้นเข้าไป ปรับแต่งว่าเลเยอร์เหล่านั้นจะตรวจจับอะไร และมีคำตอบที่ซักซ้อมไว้สำหรับวันที่เลเยอร์ใดเลเยอร์หนึ่งทำงาน มันไม่หรูหรา ไม่ได้ให้คะแนนใด ๆ และเป็นเพียงครึ่งเดียวของคู่ red-team/blue-team ที่เปลี่ยนตัวเลขความเสี่ยง
สิ่งที่ทีม Blue ได้รับสืบทอด และสิ่งที่ไม่ได้
การทำ blue teaming แบบดั้งเดิมตั้งอยู่บนชุดสมมติฐานที่การติดตั้งใช้งาน AI ทำลายลงอย่างเงียบ ๆ โดยที่เราแทบไม่รู้ตัว มีการสันนิษฐานว่าบันทึก日志 (logs) นั้นครบถ้วน เพราะเครือข่ายมองเห็นทุกแพ็กเก็ต มีการสันนิษฐานว่าสินทรัพย์ (assets) นั้นสามารถแจกแจงได้ เพราะต้องมีใครสักคนจัดเตรียมมันขึ้นมา มีการสันนิษฐานว่าพฤติกรรมนั้นเป็น deterministic เพราะโปรแกรมทำสิ่งเดิมเมื่อได้รับอินพุตเดิม ไม่มีสักข้อในสามข้อนี้ที่อยู่รอดเมื่อต้องเผชิญหน้ากับ agent
สิ่งที่ทีมบลูได้รับสืบทอดแทนคือระบบที่การตัดสินใจซึ่งมีผลกระทบมากที่สุดเกิดขึ้นภายในคำขอที่ชั้นเครือข่ายมองว่าเป็นทราฟฟิก HTTPS ธรรมดาไปยังโฮสต์เนมเดียว พรอมป์ต์ บริบทที่ดึงมา การเรียกใช้เครื่องมือ และผลลัพธ์ที่สร้างขึ้น — ทั้งหมดนี้อยู่ภายในบอดี้ของคำขอ และถ้าไม่มีใครดักจับและแยกวิเคราะห์บอดี้ดังกล่าว การติดตั้งใช้งานนั้นก็เท่ากับไม่มีการเฝ้าระวังในทางปฏิบัติ ไม่ว่าแนวป้องกันรอบนอกจะดีเพียงใดก็ตาม ภารกิจแรกของทีมบลูจึงไม่ใช่การตรวจจับ แต่คือ การสร้างเซนเซอร์ หากไม่มีความสามารถมองเห็นในระดับคำขอและระดับเครื่องมือ ก็ไม่มีอะไรให้ตรวจจับ และมาตรการควบคุมปลายน้ำทุกอย่างก็เป็นเพียงของประดับ
ใครสามารถบังคับใช้การควบคุมได้จริง
เมื่อมีเซ็นเซอร์แล้ว คำถามก็กลายเป็นว่าอนุญาตให้แต่ละคอนโทรลอยู่ตรงไหน วิธีที่ได้ผลในการอธิบายเรื่องนี้คือแบ่งตามความเป็นเจ้าของมากกว่าแบ่งตามเทคโนโลยี เพราะความเป็นเจ้าของคือสิ่งที่กำหนดว่าคอนโทรลหนึ่งจะอยู่รอดไปถึงรีลีสถัดไปได้หรือไม่

ชั้นโมเดลเป็นของใครก็ตามที่ฝึกมันขึ้นมา คุณไม่ได้กำหนดค่าให้มัน มองเข้าไปข้างในไม่ได้ และพฤติกรรมของมันเปลี่ยนไปเมื่อผู้ขายออกเวอร์ชันใหม่ — ซึ่งอาจเป็นวันอังคารใดก็ได้ สิ่งที่คุณทำได้คือ ปักหมุดเวอร์ชัน และถือว่าการเปลี่ยนเวอร์ชันเป็นการเปลี่ยนแปลงจุดยืนด้านความเสี่ยงของคุณที่ต้องทดสอบใหม่ สิ่งที่คุณทำไม่ได้คืออ้างว่ามีมาตรการควบคุมตรงนี้ "โมเดลปฏิเสธคำขอที่เป็นอันตราย" เป็นคุณสมบัติที่คุณพึ่งพาอยู่ ไม่ใช่กลไกที่คุณดำเนินการเอง
ชั้นเกตเวย์คือจุดที่พรอมต์และการตอบกลับทุกครั้งต้องผ่านคอมโพเนนต์ที่คุณเป็นเจ้าของเอง นี่คือที่ที่ขีดจำกัดงบประมาณและอัตราการใช้งานตั้งอยู่ ที่ซึ่งรายการที่อนุญาตและสิทธิ์การใช้งานเครื่องมือถูกบังคับใช้ ที่ซึ่งการบันทึกคำขอและคำตอบครบถ้วนโดยโครงสร้างการทำงานเอง และที่ซึ่งคำขอสามารถถูกเขียนใหม่ บล็อก หรือเปลี่ยนเส้นทางก่อนที่โทเค็นใด ๆ จะถูกคิดเงิน การควบคุมที่เกตเวย์ยังเป็นสิ่งเดียวที่ยังคงผูกอยู่เมื่อคุณเปลี่ยนโมเดล ซึ่งสำคัญกว่าที่ฟังดู เพราะทีมที่ใส่การควบคุมไว้ในพรอมต์จะสูญเสียมันไปทั้งหมดในวันที่พวกเขาย้ายระบบ
ชั้นสภาพแวดล้อมคือชั้นที่เป็นของคุณทั้งหมด ทั้งข้อมูลรับรองและขอบเขตสิทธิ์ของข้อมูลเหล่านั้น การเชื่อมต่อออกสู่เครือข่าย การเข้าถึงไฟล์ และขีดจำกัดของแซนด์บ็อกซ์ด้านเวลาจริงและค่าใช้จ่าย และยังเป็นจุดที่การรันที่ถูกยึดครองสร้างความเสียหาย เอเจนต์ที่ถูกหว่านล้อมให้ลงมือกระทำการอันตรายจะdangerous มากน้อยเพียงใดก็เป็นสัดส่วนโดยตรงกับสิ่งที่สภาพแวดล้อมอนุญาตให้การกระทำนั้นเข้าถึงได้ — และสภาพแวดล้อมก็เป็นที่เดียวที่ "สิทธิ์น้อยที่สุด" (least privilege) เป็นเพียงการปรับเปลี่ยนการตั้งค่า มิใช่โจทย์วิจัย
การทดสอบเชิงปฏิบัติสำหรับการควบคุม AI ที่เสนอใด ๆ คือคำถามเดียว: ในสามชั้นนี้ ชั้นใดบังคับใช้มัน? หากคำตอบคือชั้นโมเดล การควบคุมนั้นเป็นเพียงความหวัง หากคำตอบคือ "พรอมต์ระบบ" มันเป็นเพียงข้อเสนอแนะภายในชั้นโมเดล ซึ่งแย่กว่าความหวัง เพราะมันมาพร้อมเอกสารที่อ้างเป็นอย่างอื่น
ตรวจจับ: สิ่งที่เอเจนต์ส่งออกมาจริง ๆ
การตรวจจับสำหรับเอเจนต์ใช้ชุดสัญญาณที่แตกต่างจากการตรวจจับสำหรับคน ไม่มีความผิดปกติของการเข้าสู่ระบบให้เชื่อมโยง สิ่งที่มีแทนคือสตรีมคำขอที่มีโครงสร้างอุดมสมบูรณ์ผิดปกติ และสัญญาณสี่ตระกูลที่ควรแจ้งเตือน
• ปริมาณและรูปแบบของการเรียกใช้เครื่องมือ เอเจนต์ที่จู่ ๆ ก็เรียกเครื่องมืออ่านไฟล์ถึงสี่สิบครั้งในงานเดียว หรือที่มีลำดับการเรียกเครื่องมือเปลี่ยนจากสามขั้นตอนเป็นสามสิบขั้นตอน ถือว่าควรค่าแก่การจับตามอง — ไม่ใช่เพราะมันเป็นอันตราย แต่เพราะการกระจายตัวนั้นเปลี่ยนไป
• การระบุแหล่งที่มาของเนื้อหา ณ ขอบเขตข้อความใดในพรอมต์มาจากผู้ใช้ ข้อความใดมาจากการดึงข้อมูล ข้อความใดมาจากผลลัพธ์ของเครื่องมือ และข้อความใดมาจากหน่วยความจำ การตรวจจับการฉีดพรอมต์ส่วนใหญ่ลดทอนเหลือเพียง "ข้อความที่เป็นคำสั่งปรากฏในช่องทางที่ควรมีเฉพาะข้อมูล" และคุณไม่สามารถคำนวณสิ่งนั้นได้ เว้นแต่เกตเวย์จะติดป้ายแหล่งที่มาขาเข้า
• ขอบเขตการส่งข้อมูลออกและขอบเขตการเข้าถึง คำขอไปยังปลายทางที่อยู่นอกรายการที่อนุญาต การอ่านพาธที่อยู่นอกขอบเขต และการพยายามใช้ข้อมูลรับรองนอกบริการที่ตั้งใจไว้ สัญญาณเหล่านี้มีความแม่นยำสูงและมีต้นทุนต่ำ เพราะสภาพแวดล้อมรู้อยู่แล้วว่าสิ่งใดได้รับอนุญาต
• การใช้จ่ายและความหน่วงเป็นตัวชี้วัดแทน ทั้งลูปที่วิ่งไม่หยุดและการถูกเจาะระบบ ต่างก็ดูเหมือนเส้นโค้งค่าใช้จ่ายที่เปลี่ยนความชัน การแจ้งเตือนงบประมาณเป็นการตรวจจับที่ดูไม่หวือหวาที่สุดในสแต็ก และเป็นหนึ่งในวิธีที่คืนทุนได้เร็วที่สุด
สิ่งที่จงใจไม่ใส่ไว้ในรายการนั้นคือตัวจำแนกประเภทที่ถูกขอให้ตัดสินว่าผลลัพธ์ที่โมเดลสร้างขึ้นเป็นอันตรายหรือไม่ มันคือแนวคิดด้านการตรวจจับที่ทีมต่าง ๆ หยิบมาใช้เป็นอันดับแรก และเป็นแนวคิดที่เสื่อมสภาพเร็วที่สุดเมื่อเวลาผ่านไป มันคลาดเคลื่อนไปตามโมเดล มีอัตราผลบวกลวงที่ฝึกให้นักวิเคราะห์ของคุณเพิกเฉยต่อมัน และไม่ได้ให้อะไรที่คุณจะเอาไปใส่ในรันบุ๊กได้
ควบคุม: สามปุ่มที่หยุดการรันที่แย่
การจำกัดขอบเขตของเอเจนต์ง่ายกว่าที่คิด เพราะปุ่มควบคุมเพียงสามตัวครอบคลุมเกือบทุกอย่าง งบประมาณจำกัดสิ่งที่การรันหนึ่งครั้งใช้จ่ายได้ ซึ่งช่วยจำกัดทั้งความเสียหายทางการเงินและรัศมีผลกระทบของลูป ขอบเขตจำกัดสิ่งที่การรันหนึ่งครั้งแตะต้องได้ — เครื่องมือที่เปิดใช้สำหรับงานนั้น เส้นทาง และผู้เช่า แซนด์บ็อกซ์จำกัดระยะเวลาที่มันสามารถรันได้ และสิ่งที่มันเข้าถึงได้ขณะรัน ทั้งสามอย่างเป็นการตั้งค่าของเกตเวย์หรือสภาพแวดล้อม ซึ่งเป็นอีกนัยหนึ่งว่าสิ่งเหล่านี้สามารถบังคับใช้ได้
หลักการออกแบบที่สำคัญคือขอบเขตเฉพาะงาน ไม่ใช่ขอบเขตเฉพาะเอเจนต์ เอเจนต์ที่มีชุดสิทธิ์แบบถาวรคือเอเจนต์ที่สิทธิ์จะสะสมไปเรื่อย ๆ จนกว่าจะมีใครสักคนตรวจสอบ ส่วนเอเจนต์ที่ได้รับข้อมูลรับรองเฉพาะขอบเขตงานตลอดระยะเวลาของงานนั้นมีขอบเขตที่หมดอายุได้เอง วิธีที่สองต้องใช้แรงสร้างมากกว่าแต่ปกป้องได้ถูกกว่ามาก

นี่คือจุดที่เกตเวย์สมชื่อ การควบคุมที่อยู่หน้าทุกการเรียกใช้โมเดล — การเรียกใช้เครื่องมือและ MCP ที่ถูกประเมินก่อนทำงาน นโยบายเนื้อหาและการปิดบังข้อมูลส่วนบุคคลที่ถูกใช้ก่อนมีการเรียกเก็บเงินสำหรับคำขอ — เป็นการควบคุมชุดเดียวกัน ไม่ว่าโมเดลที่อยู่เบื้องหลังจะเป็นตัวที่คุณใช้เมื่อไตรมาสที่แล้วหรือตัวที่เพิ่งเปิดตัวสัปดาห์ที่แล้ว ความต่อเนื่องนี้คือผลิตภัณฑ์จริง ๆ ไม่ใช่ฟิลเตอร์ที่ดีกว่า แต่เป็นที่อยู่ของฟิลเตอร์ที่ไม่ขยับไปตามโมเดล
กู้คืน: เล่นซ้ำ แพตช์ และทดสอบซ้ำ
การกู้คืนจากเหตุการณ์ AI มีข้อได้เปรียบหนึ่งเหนือการกู้คืนจากเหตุการณ์เครือข่าย: โดยปกติแล้วการรันทั้งหมดจะถูกบันทึกไว้ พรอมต์ บริบท การเรียกใช้เครื่องมือ ผลลัพธ์ที่สร้างขึ้น และเวลาที่ใช้ — หากเกตเวย์บันทึกสิ่งเหล่านี้ไว้ เหตุการณ์นั้นสามารถเล่นซ้ำได้ ซึ่งเป็นจุดเริ่มต้นที่แข็งแกร่งกว่าจุดเริ่มต้นที่งานสืบสวนทางนิติวิทยาศาสตร์ส่วนใหญ่ได้รับ
Replay ทำหน้าที่สามประการตามลำดับ มันยืนยันว่าเกิดอะไรขึ้นจริง แทนที่จะเป็นสิ่งที่บันทึกถอดความชี้ว่าเกิดขึ้นหลังจากที่หลายคนได้สรุปมันไปแล้ว มันระบุมาตรการควบคุมที่ควรถูกกระตุ้นให้ทำงาน ซึ่งเป็นความแตกต่างระหว่างการแก้ที่อาการกับการแก้ที่ขอบเขต และมันสร้างเคสทดสอบการถดถอย: อินพุตที่บันทึกไว้ซึ่งตอนนี้ต้องถูกบล็อก นำไปรันกับคอนฟิกูเรชันใหม่เพื่อพิสูจน์ว่ามันถูกบล็อกจริง
ขั้นตอนการแพตช์เป็นจุดที่ทีมบลูเล็งเป้าผิดพลาดบ่อยที่สุด หากสิ่งที่พบเป็นพฤติกรรมของโมเดล มาตรการบรรเทาที่มีอยู่ล้วนอยู่นอกโมเดล — การลดขอบเขต การกรองที่เกตเวย์ การถอดสิทธิ์ออกจากสภาพแวดล้อม หากสิ่งที่พบเป็นพฤติกรรมของระบบ การแก้ไขอยู่ที่การกำหนดค่า และการทดสอบถดถอยมีต้นทุนต่ำ ไม่ว่าจะกรณีใด การทดสอบซ้ำไม่ใช่ทางเลือก เพราะทั้งการแก้ไขและเวอร์ชันโมเดลต่างก็เปลี่ยนแปลง และการควบคุมที่ได้รับการตรวจสอบกับบิลด์ของเดือนที่แล้วเป็นการอ้างอิงถึงเดือนที่แล้ว
ซ้อมวันที่จะยิง
รันบุ๊กที่ไม่เคยถูกอ่านภายใต้แรงกดดันเป็นเพียงเอกสาร ไม่ใช่ขีดความสามารถ การซ้อมที่มีคุณค่าต้องแคบและเจาะจง: หยิบเหตุการณ์ของเอเจนต์ที่น่าเป็นไปได้มาหนึ่งเหตุการณ์ เดินให้ครบตั้งแต่ต้นจนจบ และจับเวลาทุกขั้นตอน ใครเป็นคนสังเกตเห็น? ต้องใช้เวลานานเท่าใดกว่าคนจะได้ดูบรรทัดล็อกที่ถูกต้อง? ใครสามารถหยุดการรันได้ — คนที่ระบุชื่อคนเดียว หรือคณะกรรมการ? ใครสามารถเพิกถอนข้อมูลรับรองได้ และกว่าการเพิกถอนจะแพร่กระจายไปทั่วต้องใช้เวลานานเท่าใด? ใครเป็นผู้ตัดสินใจว่าจะแจ้งผู้ใดภายนอกบริษัทหรือไม่?
คำถามสองข้อนี้มักทำให้ทีมสะดุดได้เสมอ “ใครสามารถหยุดการรันได้” จะใช้ไม่ได้เมื่อการหยุดต้องพึ่งคนที่กำลังนอนหลับ ดังนั้นคำตอบต้องเป็นกลไกมากกว่าบุคคล — เพดานงบประมาณหรือสวิตช์ตัดระบบที่วิศวกรเวรสามารถดึงได้คนเดียว “การเพิกถอนใช้เวลานานเท่าใด” ใช้ไม่ได้เพราะข้อมูลรับรองมักถูกแคชไว้ในคอมโพเนนต์ที่ไม่ได้อยู่ในไดอะแกรม

การอ่านคลังบันทึกเป็นรูปแบบการซ้อมที่ถูกที่สุดที่มีอยู่ เพราะช่วยให้คุณสืบทอดโครงสร้างเหตุการณ์ของคนอื่นแทนที่จะต้องคิดค้นขึ้นเอง หยิบรายการสักสองสามรายการที่คล้ายกับการติดตั้งใช้งานของคุณ แล้วถามคำถามสามข้อข้างต้นกับแต่ละรายการ รายการใดที่คุณตอบคำถามเหล่านั้นไม่ได้ รายการนั้นคือช่องว่างในรันบุ๊กของคุณ และคุณพบมันก่อนเกิดเหตุการณ์ ไม่ใช่หลังจากนั้น
ความไม่สมมาตรที่ควรพูดออกมาอย่างตรงไปตรงมา
Red teaming และ blue teaming ไม่ใช่กิจกรรมที่มีความสมมาตรกัน และไม่ควรจัดสรรงบประมาณราวกับว่าสมมาตรกัน การรัน red team ถูกจำกัดด้วยกำหนดการและสร้างชุดข้อค้นพบที่เสื่อมค่าลงเมื่อเป้าหมายเปลี่ยนแปลง การควบคุมของ blue team นั้นคงอยู่ สะสมต่อเนื่อง และเป็นเพียงสิ่งเดียวที่กั้นระหว่างอินพุตที่ไม่ดีกับผลลัพธ์ที่ไม่ดีจริง ๆ engagement หนึ่งครั้งสามารถค้นพบขอบเขตได้ แต่มีเพียงอีกฝ่ายเท่านั้นที่รักษาขอบเขตนั้นไว้ได้
ซึ่งทำให้มาตรฐานที่ซื่อตรงสำหรับ blue team ไม่หวือหวาและตรวจสอบได้ สำหรับทุกการควบคุมที่คุณอ้างว่ามี คุณควรสามารถระบุชั้นที่บังคับใช้มัน บรรทัดล็อกที่พิสูจน์ว่ามันทำงาน การแจ้งเตือนที่บอกคุณเมื่อมันไม่ทำงาน และคนที่สามารถปิดการรันได้ สี่ประโยค หากขาดอย่างใดอย่างหนึ่งไป การควบคุมนั้นก็เป็นเพียงเอกสารนโยบาย และเอกสารนโยบายไม่ได้อ่านบอดีคำขอ
