แทนที่จะรอให้ผู้โจมตีตัวจริงพบช่องโหว่ ทีมพัฒนาสามารถให้ agent สำรวจระบบที่ได้รับอนุญาต เก็บผลจากเครื่องมือ และร่างรายงานเพื่อให้มนุษย์ตรวจสอบก่อนแก้ไขได้ นี่คือสิ่งที่ T3MP3ST พยายามทำให้เป็นจริง โดยทีมไม่จำเป็นต้องซื้อแพลตฟอร์ม AI security ชุดใหม่ เพราะอาจใช้ coding agent ที่มีอยู่แล้วเป็นตัววางแผน

จุดสำคัญจึงไม่ใช่แค่การนำ Claude Code, Codex หรือ Hermes มาต่อกับเครื่องมือ security แต่คือการแยกให้ออกว่าอะไรที่ใช้งานได้ในปัจจุบัน อะไรเป็นเพียงคำกล่าวอ้างของผู้พัฒนา และอะไรยังเป็นเพียงแนวคิดสถาปัตยกรรม multi-agent ที่ไม่มีหลักฐานรองรับ

T3MP3ST เป็นตัวเชื่อม ไม่ใช่ pentester อัตโนมัติ

T3MP3ST เป็นเฟรมเวิร์ก offensive security แบบโอเพนซอร์สที่เสริมระบบวางแผน การเรียกใช้เครื่องมือ การเก็บข้อค้นพบพร้อมหลักฐาน และการจัดทำรายงานให้ coding agent หรือโมเดลภายในองค์กร README ของ GitHub/elder-plinius/T3MP3ST เรียกโครงสร้างนี้ว่า meta-harness ชื่อนี้อธิบายบทบาทของระบบได้ตรงกว่าการมองว่าเป็น agent เดี่ยวที่ตอบคำถามจากข้อความ

ผู้ใช้เลือกควบคุมงานผ่านหน้า War Room หรือ CLI ได้ ด้าน reasoning มีให้เลือกสองแนวทาง แนวทางแรกเชื่อมกับ Claude Code, Codex หรือ Hermes ที่ลงชื่อเข้าใช้อยู่แล้ว ผู้พัฒนาเรียกวิธีนี้ว่า “keyless” เพราะผู้ใช้ไม่ต้องป้อน model API key ชุดใหม่ให้ T3MP3ST แต่ไม่ได้หมายความว่าการใช้บัญชี แพ็กเกจสมาชิก หรือโควตาของ coding agent ต้นทางจะไม่มีค่าใช้จ่าย

อีกแนวทางหนึ่งใช้โมเดล local โดยตั้งต้นกับ Ollama หรือชี้ไปยังเซิร์ฟเวอร์ที่เข้ากันได้กับ OpenAI เช่น LM Studio, vLLM และ llama.cpp วิธีนี้ช่วยให้ทีมกำหนดได้ว่าข้อมูลจะถูกส่งไปที่ใดบ้าง ซึ่งต่างจากการส่งงานไปยังบริการภายนอก แต่คำว่า local ไม่ได้หมายความว่าข้อมูลจะไม่ออกจากเครื่อง ทีมยังต้องตรวจ endpoint, adapter, log และเครื่องมือเครือข่ายที่เปิดให้ agent ใช้งาน

ตั้งแต่สำรวจจนถึงทำรายงาน ข้อค้นพบทุกชิ้นต้องมีหลักฐาน

ในภาพรวม กระบวนการที่ปลอดภัยแบ่งได้เป็นสี่ช่วง

1. สำรวจภายในขอบเขต เพื่อทำความเข้าใจระบบและส่วนต่าง ๆ ที่ได้รับอนุญาตให้ทดสอบ โดยบันทึกว่าเครื่องมือใดให้ข้อมูลอะไร
2. ตรวจสอบสิ่งผิดปกติ ด้วยการเชื่อมโยงข้อมูลจากผลลัพธ์หลายชุดเข้าด้วยกัน ไม่ถือว่าข้อความที่โมเดลคาดเดาเป็นช่องโหว่ทันที
3. ยืนยันผลอย่างรัดกุม โดยทดสอบเฉพาะภายในขอบเขตและเงื่อนไขที่กำหนดไว้ พร้อม stop condition ที่ชัดเจน
4. จัดทำรายงานพร้อมหลักฐาน เพื่อให้มนุษย์ประเมินความรุนแรง ตัดสินใจ และแก้ไขต่อ

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

แนวคิดเดียวกันปรากฏในส่วน coordinated disclosure ซึ่งระบบทำได้เพียงสร้างร่างและให้มนุษย์เป็นผู้ส่ง การแบ่งหน้าที่เช่นนี้ควรใช้กับการตัดสินใจทุกขั้นตอนที่มีผลกระทบ ไม่ใช่เฉพาะอีเมลฉบับสุดท้าย

Agent harness ไม่ได้มาแทน vulnerability scanner

README ของ T3MP3ST ไม่ได้นำเสนอผลการทดสอบเปรียบเทียบโดยตรงกับ vulnerability scanner ทั่วไป หากจะเปรียบเทียบอย่างเป็นธรรม จึงควรพิจารณาจากวิธีทำงาน ไม่ใช่ตัดสินว่าแบบใดดีกว่า

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

เริ่มประเมินจากส่วนที่ใช้งานได้ ไม่ใช่จากแนวคิด swarm

ส่วนที่ทีมทดลองใช้ได้ก่อนคือ War Room สำหรับควบคุมงานผ่านเบราว์เซอร์และ CLI สำหรับใช้งานผ่านเทอร์มินัล โครงการยังมี MCP และ HTTP API ให้ระบบอื่นเรียกงานสำรวจหรือควบคุมงานทดสอบได้ จึงทดลองเชื่อมกับ workflow ใน lab ได้โดยไม่ต้องเปิดใช้ agent แปดบทบาทพร้อมกัน

README รายงานว่าชุดเริ่มต้นมีเครื่องมือ 35 รายการ ส่วนโหมด full Arsenal มีตัวเชื่อมให้เลือกเปิดเพิ่มอีก 48 รายการ รวมเป็น 83 รายการ เครื่องมือความเสี่ยงสูงที่ใช้หลังเข้าถึงระบบต้องผ่านการอนุมัติจากมนุษย์ แต่จำนวนเครื่องมือบอกได้เพียงว่ามีตัวเชื่อมให้เลือกมากเพียงใด ไม่ได้บอกว่าผลลัพธ์แม่นยำหรือระบบพร้อมใช้กับ production

กลไก egress-scope containment เปิดใช้งานโดยค่าเริ่มต้นเพื่อป้องกันไม่ให้เครื่องมือเครือข่ายในตัวติดต่อ public host นอกเป้าหมายและ subdomain ที่กำหนด อย่างไรก็ตาม ปลายทางในเครื่องและ private network ยังเข้าถึงได้ อีกทั้งยังไม่มีหลักฐานว่าตัวเชื่อมทุกชนิดใช้ข้อจำกัดเดียวกัน ทีมจึงต้องทดสอบการกั้นเครือข่ายด้วยตัวเอง ไม่ควรถือว่าการตั้งค่าเริ่มต้นนี้ทำให้ระบบปลอดภัยทันที

คำสั่ง npm run verify-claims ช่วยคำนวณผล benchmark หลักซ้ำจากข้อมูลที่เก็บในโครงการ ผู้พัฒนารายงานว่าการตรวจ 24 จาก 24 รายการผ่าน แต่บันทึกการใช้เครื่องมือในแต่ละขั้นถูกนำออกเพื่อปกป้องความเป็นส่วนตัว การตรวจซ้ำจึงยืนยันได้เพียงผลที่ผ่านการให้คะแนนแล้ว แต่ตรวจสอบขั้นตอนการทำงานทั้งหมดไม่ได้

Benchmark บอกเรื่อง single-agent มากกว่าเรื่อง swarm

ก่อนดูคะแนน ต้องรู้ก่อนว่า benchmark หลักทั้งหมดใช้วงจรการทำงานของ agent ตัวเดียว ไม่ใช่ swarm ที่มี operator แปดบทบาท คะแนนจึงบอกว่า agent ตัวเดียวทำงานร่วมกับเครื่องมือผ่าน harness นี้ได้อย่างไร อีกทั้งยังสะท้อนความสามารถของทั้ง T3MP3ST และโมเดลประสิทธิภาพสูงในปัจจุบัน จึงแยกไม่ได้ว่าผลที่ดีขึ้นมาจาก T3MP3ST เพียงอย่างเดียวเท่าไร

ภายใต้เงื่อนไขนี้ หน้าโครงการรายงานว่า XBEN แบบ black-box ซึ่ง agent มองไม่เห็นโค้ดภายใน ผ่านอย่างน้อย 91 จาก 104 challenge และมีคะแนนเฉลี่ย 90.1% เมื่อให้หนึ่งโอกาสต่อโจทย์หรือ pass@1 ด้วย gpt-5.5 ส่วน Cybench ได้ 23 จาก 40 โจทย์ หรือ 58% จากการรันครั้งเดียวโดยไม่มี hint ด้วย Opus 4.8

ตัวเลขทั้งหมดเป็นเพียงคำกล่าวอ้างของผู้พัฒนาในแหล่งข้อมูลเดียว ไม่ใช่ผลจากการทดสอบซ้ำของบทความนี้ และเทียบโดยตรงกับคะแนนที่ใช้วิธีวัดต่างกันไม่ได้ ตัวอย่างเช่น README ระบุชัดว่าไม่สามารถนำผล Cybench แบบรันครั้งเดียวนี้ไปเทียบตรง ๆ กับสถิติ pass@10 ที่ให้โอกาสทดสอบหลายครั้งได้

โครงสร้างแปดบทบาทมีตั้งแต่ Recon, Scanner และ Coordinator ไปจนถึงบทบาทในขั้นหลัง ๆ แต่ README ยอมรับว่าการประสานงานแบบ swarm ตั้งแต่ต้นจนจบยังไม่น่าเชื่อถือและยังไม่มี benchmark รองรับ คำว่า multi-agent จึงมีไว้เพื่ออธิบายสถาปัตยกรรมที่โครงการตั้งเป้าจะพัฒนา ไม่ใช่หลักฐานว่า agent หลายตัวทำงานเป็นทีมได้ดีกว่าตัวเดียว

งานเฉพาะทางด้าน cloud, mobile, binary และ identity ก็มีระดับความพร้อมไม่เท่ากัน หลายส่วนยังเป็นเพียงโครงสำหรับวิเคราะห์ เป็นงานทดลอง หรืออยู่ในแผนพัฒนา จึงควรประเมินทีละความสามารถแทนที่จะคาดหวังแพลตฟอร์ม autonomous red team ที่สมบูรณ์แล้ว

ตอบคำถามสี่ข้อนี้ให้ได้ก่อนทดลอง

1. เป้าหมายอยู่ในขอบเขตที่ได้รับอนุญาตจริงหรือไม่ ต้องระบุระบบ เจ้าของ ระยะเวลา และสิ่งที่ห้ามแตะให้ชัด การอนุญาตแบบกว้าง ๆ หรือการคิดไปเองว่าเป็นระบบสาธารณะนั้นไม่เพียงพอ
2. ข้อมูลและ credential ออกไปที่ใดได้บ้าง ตรวจทั้งปลายทางที่ใช้รับส่งข้อมูลระหว่างระบบกับโมเดล บันทึกการทำงาน ช่องทาง MCP และ HTTP API ตัวเชื่อมเครื่องมือ และเส้นทางเครือข่าย ไม่ควรด่วนสรุปว่าการใช้วิธี keyless หรือ local จะทำให้ข้อมูลไม่ออกนอกขอบเขต
3. ข้อค้นพบทุกชิ้นมีหลักฐานจากเครื่องมือจริงหรือไม่ ข้อค้นพบในรายงานต้องตรวจสอบย้อนกลับได้ว่ามาจากผลลัพธ์ใด พบเมื่อไร และภายใต้เงื่อนไขใด ข้อความสรุปของโมเดลเพียงอย่างเดียวไม่ใช่หลักฐาน
4. มีมนุษย์ตัดสินใจก่อนดำเนินการขั้นต่อไปหรือไม่ ผู้ตรวจต้องสามารถหยุดกระบวนการ ปรับ scope หรือตีกลับข้อค้นพบได้ โดยเฉพาะก่อนลงมือยืนยันข้อค้นพบด้วยวิธีที่เพิ่มความเสี่ยง และก่อนส่งรายงานออกนอกทีม

คำถามเหล่านี้ไม่ได้หมายความว่า T3MP3ST บังคับใช้มาตรการควบคุมครบทุกข้อ แต่เป็นเกณฑ์ขั้นต่ำในการประเมิน harness ที่มีสิทธิ์เรียกใช้เครื่องมือจริง

เริ่มทดลองในระบบที่จำกัดความเสียหายได้ ไม่ใช่ production

พื้นที่ทดลองที่เหมาะสมคือ lab, CTF, localhost หรือระบบที่ได้รับอนุญาตเป็นลายลักษณ์อักษร ทีมควรกำหนด scope กับ stop condition ก่อนเริ่มทดสอบ พร้อมจำกัดสิทธิ์และเส้นทางเครือข่าย บันทึก log ทุกครั้งที่ทำงาน และให้มนุษย์ตรวจข้อค้นพบก่อนดำเนินการต่อ แนวทางเรื่องขอบเขตและการอนุญาตอยู่ในคู่มือ Scope and Authorization ของโครงการ

T3MP3ST น่าสนใจเพราะแสดงให้เห็นว่า coding agent ที่ใช้เขียนซอฟต์แวร์อยู่ทุกวันอาจทำหน้าที่วางแผนการใช้เครื่องมือ security ได้ โดยไม่ต้องเปลี่ยนระบบ AI ที่ใช้อยู่ทั้งหมด แต่ประโยชน์หลักในตอนนี้ไม่ได้อยู่ที่การให้ agent แปดตัวบุกระบบโดยอัตโนมัติ แต่อยู่ที่การทดลองว่า coding agent วางแผนการใช้เครื่องมือ เชื่อมโยงหลักฐาน และช่วยมนุษย์ตรวจระบบที่ได้รับอนุญาตได้ดีเพียงใด พร้อม stop condition เพื่อหยุดการทำงานก่อนที่ความผิดพลาดจะกระทบ production

---

ที่มา: บทความ GitHub - elder-plinius/T3MP3ST: autonomous red teaming platform; multi-agent offensive-security meta-harness จาก GitHub/elder-plinius/T3MP3ST