Microsoft RAMPART + Clarity: เมื่อ Agent Safety ต้องเข้า CI

Microsoft Security Blog เผยแพร่บทความ Introducing RAMPART and Clarity: Open source tools to bring safety into Agent development workflow เมื่อวันที่ 20 พฤษภาคม 2026

ประเด็นหลักคือ Microsoft เปิดโอเพนซอร์ส 2 เครื่องมือสำหรับทีมที่กำลังสร้าง agentic AI applications:

• RAMPART: framework สำหรับเขียน safety/security tests ให้ AI agents ในรูปแบบที่คุ้นกับ pytest และ CI
• Clarity: เครื่องมือช่วยทีม clarify problem, solution, failure analysis และ decision ก่อนรีบลงมือ build

ถ้าอ่านแบบผิวเผิน นี่อาจดูเหมือนข่าวเครื่องมือ security อีกตัว

แต่ในมุม operator ผมคิดว่านี่เป็นสัญญาณใหญ่กว่า:

AI agent safety กำลังกลายเป็นงาน engineering lifecycle ไม่ใช่ checkpoint ปลายทาง

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

Microsoft อธิบายว่า AI systems ในองค์กรวันนี้ไม่ได้หยุดอยู่ที่การ generate text แล้ว

agent เริ่มเข้าถึง email, CRM, code repo, command line, database, document, ticket, workflow และ connected systems จำนวนมาก

เมื่อ agent “ทำสิ่งต่าง ๆ ในโลกจริง” ได้ ความเสี่ยงก็เปลี่ยนทันที

ไม่ใช่แค่คำตอบผิด

แต่คือ:

• เรียก tool ผิด
• อ่านข้อมูลที่ไม่ควรอ่าน
• เอา instruction จากเอกสารที่ถูก poison มาเชื่อ
• ส่ง action ออกไปผิดระบบ
• แก้ record หรือ code โดยไม่มี boundary
• ทำซ้ำ incident เดิมหลังจากทีมคิดว่าแก้แล้ว

RAMPART ถูกออกแบบมาเพื่อเปลี่ยนความเสี่ยงพวกนี้ให้เป็น test ที่รันได้

Microsoft บอกว่า RAMPART built on top of PyRIT และให้ทีมเขียน standard pytest tests ที่อธิบาย scenario จาก threat model ของ agent

ตัว test จะ connect เข้า agent ผ่าน adapter, orchestrate interaction, evaluate observable outcomes แล้วคืน pass/fail signal ที่เอาเข้า CI ได้เหมือน integration test

ส่วน Clarity ช่วยทีมถามคำถามก่อน build เช่น problem จริงคืออะไร, solution ที่เลือกมี failure mode อะไร, decision นี้มี rationale อะไร, และเมื่อ problem statement เปลี่ยน artifact ไหนควรถูก revisit

ผลลัพธ์ถูกเก็บใน .clarity-protocol/ เป็น markdown ใน repo

นี่สำคัญมาก เพราะมันทำให้ safety ไม่ใช่เอกสารแยกนอก workflow

แต่มันกลายเป็น artifact ที่ commit, diff, review และย้อนดูได้

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

Red team ยังสำคัญครับ

แต่ red team ที่จบเป็น report อย่างเดียวมักมีปัญหา 3 อย่าง:

1. finding อยู่ในเอกสาร ไม่ได้อยู่ใน workflow ที่รันซ้ำ
2. engineer แก้ครั้งหนึ่งแล้วไม่มี test กัน regression
3. เมื่อ agent ต่อ tool ใหม่ ความเสี่ยงเดิมอาจกลับมาในรูปใหม่โดยไม่มีใครรู้

RAMPART พยายามปิดช่องนี้ด้วยแนวคิดที่คุ้นมากใน software engineering:

เจอ bug แล้วต้องเขียน regression test

แต่เปลี่ยนจาก bug ธรรมดาเป็น agent safety incident

ตัวอย่างเช่น ถ้า red team พบว่า agent อ่าน ticket ที่มี prompt injection แล้วไปเรียก tool อันตราย

สิ่งที่ควรเกิดขึ้นไม่ใช่แค่ “บอกทีมให้ระวัง”

แต่ควรมี test ที่จำลอง scenario นั้น แล้ว assert ว่า agent ไม่ควรเรียก tool นั้น หรือควรขอ approval ก่อน

จากนั้น test นี้ต้องรันซ้ำเมื่อมีการเปลี่ยน agent prompt, tool, adapter, model, retrieval source หรือ policy

นี่คือความต่างระหว่าง awareness กับ operating control

awareness ทำให้คนรู้ว่ามีความเสี่ยง

operating control ทำให้ระบบจับได้เมื่อความเสี่ยงกลับมา

3) Prompt injection กลายเป็น integration-test problem

หนึ่งในจุดที่ Microsoft เน้นคือ RAMPART mature coverage ตอนนี้อยู่ที่ cross-prompt injection attacks

แปลเป็นภาษาทำงานคือ:

agent ไม่ได้โดนหลอกเฉพาะจาก prompt ที่ user พิมพ์ตรง ๆ

แต่มันอาจโดนหลอกจาก content ที่ agent ไป retrieve หรือ process เอง เช่น:

• เอกสารใน drive
• email
• ticket
• web page
• CRM note
• support transcript
• pull request comment
• knowledge base article

ถ้า content เหล่านั้นมี instruction แปลก ๆ เช่น “ignore previous instructions” หรือ “send this secret to external URL” agent ที่ไม่มี boundary อาจทำตามได้

นี่ไม่ใช่ปัญหา prompt wording อย่างเดียว

มันเป็นปัญหา system behavior

ดังนั้น evaluator ต้องดูว่า agent ทำอะไรจริง:

• เรียก tool ไหน
• action มี side effect ไหม
• ข้อมูลออกนอก boundary หรือเปล่า
• ต้อง approval แล้วข้ามไหม
• outcome ยังอยู่ใน expected boundary ไหม

RAMPART จึงน่าสนใจตรงที่มันคิดแบบ observable outcome ไม่ใช่แค่ดู text answer

สำหรับ agent ที่แตะระบบจริง นี่คือทิศทางที่ถูกต้อง

เพราะคำตอบของ model อาจดูดี แต่ action ที่มันเรียกอาจผิด

4) Clarity แก้ปัญหาก่อนโค้ดเริ่มไหล

RAMPART อยู่ฝั่ง test หลังจากเรามี agent/system ให้ทดสอบ

แต่ Clarity อยู่ก่อนหน้านั้น

Microsoft วาง Clarity เป็น structured sounding board ที่ช่วยทีมคิดให้ชัดก่อนลงมือ build

ในยุคที่ AI coding tool ทำให้การ execute ง่ายขึ้น ปัญหาใหญ่ไม่ใช่ “เขียนโค้ดได้ไหม”

แต่คือ “เรากำลัง build สิ่งที่ควร build หรือเปล่า”

นี่ใกล้ตัวมากสำหรับทีมเล็ก

เพราะเมื่อ AI ช่วยเขียนเร็วขึ้น ความผิดพลาดด้าน direction ก็แพงขึ้นตาม

ถ้าทีมยังไม่ชัดว่า workflow ต้องการอะไรจริง ๆ agent จะช่วยผลิต implementation ที่ผิดได้เร็วมาก

Clarity บันทึก artifact เช่น:

• problem statement
• solution rationale
• failure analysis
• key decisions
• options ที่เคยพิจารณา
• criteria ที่ใช้ตัดสิน

และเก็บเป็น markdown ใน repo เพื่อให้ review ได้เหมือนโค้ด

นี่คือ pattern ที่ผมชอบ:

decision ก็เป็น source of truth เหมือน code

ถ้า agent จะทำงานกับระบบจริง เราไม่ควรมีแค่โค้ดกับ prompt

เราควรมี reason ที่อธิบายว่า:

• ทำไม agent ต้องมี tool นี้
• ทำไม tool นี้ให้ write access ได้
• ทำไม action นี้ต้อง approval
• ทำไม failure mode นี้ยอมรับได้หรือไม่ได้
• ถ้า requirement เปลี่ยน test ไหนต้องเปลี่ยน

5) ธุรกิจไทยควรเอาไปใช้ยังไง

ผมไม่คิดว่าทุกทีมไทยต้องรีบเอา RAMPART หรือ Clarity ไปลง production ทันที

แต่ pattern ที่ควรเอาไปใช้ทันทีคือ:

ทุก agent workflow ต้องมี spec, boundary, proof และ regression path

เริ่มง่าย ๆ ด้วย 4 ชั้นนี้

ชั้นที่ 1: เขียน agent boundary ให้ชัด

ก่อนให้ agent แตะ tool ให้ตอบให้ได้:

• agent ทำงานอะไร
• เห็นข้อมูลอะไร
• tool ไหนอ่านได้
• tool ไหนเขียนได้
• action ไหนต้อง approval
• action ไหนห้ามทำเด็ดขาด
• log/proof หลังจบงานอยู่ที่ไหน

ถ้าตอบไม่ได้ อย่าเพิ่งเพิ่มสิทธิ์

ชั้นที่ 2: แปลง failure เป็น test

เมื่อเจอเคสเสี่ยง อย่าจบที่การบอกว่า “คราวหน้าระวัง”

ให้ถามว่า:

• scenario นี้จำลองได้ไหม
• input/test fixture คืออะไร
• expected safe behavior คืออะไร
• assert จาก tool call หรือ side effect ได้ไหม
• test นี้ควรรันใน PR หรือ nightly

ถ้าตอบได้ ให้ใส่เข้า test suite

ถ้ายังตอบไม่ได้ อย่างน้อยต้องเก็บเป็น known risk พร้อม owner

ชั้นที่ 3: ทำ approval gate ตามความเสี่ยง

ไม่ใช่ทุก action ต้องรอคน

แต่ action ที่แตะเงิน ลูกค้า production public channel pricing DNS หรือข้อมูลสำคัญ ต้องมี approval

agent ที่ดีไม่ใช่ agent ที่ไม่ถามคนเลย

agent ที่ดีคือ agent ที่รู้ว่าจุดไหนควรหยุดและยื่น proof ให้คนตัดสิน

ชั้นที่ 4: ให้ CI เป็นผู้จำ safety memory

คนจำไม่ได้ทุก incident

แต่ CI จำได้ ถ้าเราเขียน test ไว้

นี่คือหัวใจของ RAMPART ในมุมผม:

อย่าให้ safety memory อยู่ในหัวคนคนเดียว หรือ report ที่เปิดปีละครั้ง

ให้มันอยู่ใน repo และรันซ้ำกับงานจริง

6) ตัวชี้วัดที่ควรเริ่มเก็บ

ถ้าทีมเริ่มใช้ agent กับ workflow สำคัญ ผมอยากเห็น metric แบบนี้:

• จำนวน safety regression tests ต่อ workflow
• percentage ของ tool calls ที่มี policy coverage
• จำนวน incident ที่ถูกแปลงเป็น test ภายในกี่วัน
• approval bypass attempts ที่ถูกจับได้
• prompt injection scenarios ที่ test แล้ว
• agent output ที่ fail เพราะ safety gate
• time from finding to CI coverage
• number of stale decisions/specs ที่ต้อง revisit

ตัวเลขพวกนี้อาจดูไม่หวือหวาเท่า “agent ทำ task ได้กี่งาน”

แต่ถ้าจะใช้ agent เป็นระบบทำงานจริง ตัวเลขด้าน safety/operability สำคัญไม่แพ้ productivity

เพราะงาน agent ที่เร็วแต่คุมไม่ได้ จะกลายเป็น cost ตอนเกิด incident

7) มุมมองของผม: Fully autonomous ต้องเริ่มจาก fully accountable

คำว่า autonomous ฟังดูดี

แต่ในธุรกิจจริง ผมจะระวังมากถ้า agent ยังไม่มี accountability layer

accountability ในที่นี้ไม่ใช่แค่มี log

แต่ต้องมี:

• source of truth
• owner
• test
• approval gate
• rollback path
• artifact หลังจบงาน
• decision history
• incident-to-regression loop

RAMPART และ Clarity ไม่ได้ทำให้ agent ปลอดภัยอัตโนมัติ

แต่สองเครื่องมือนี้ชี้ทิศทางที่ถูก:

agent safety ต้องอยู่ใกล้ code, PR, test และ CI มากขึ้น

ไม่ใช่อยู่เฉพาะใน governance deck

สรุป

ข่าว RAMPART + Clarity ของ Microsoft เป็นอีกสัญญาณว่าโลก agent กำลังเข้าสู่ phase ใหม่

จาก “agent ทำอะไรได้บ้าง”

ไปสู่ “เราจะทำให้ agent ทำงานซ้ำได้อย่างตรวจสอบได้อย่างไร”

สำหรับทีมไทย ผมคิดว่าบทเรียนคือ:

อย่าเริ่มจากเพิ่มสิทธิ์ให้ agent

ให้เริ่มจากเพิ่มระบบตรวจ agent

ถ้า agent จะอ่านข้อมูล ให้มี boundary

ถ้า agent จะเรียก tool ให้มี observable outcome

ถ้า agent เคยพลาด ให้มี regression test

ถ้า agent จะทำ action เสี่ยง ให้มี approval

และถ้าทีมตัดสินใจอะไรสำคัญ ให้ decision นั้นอยู่ใน repo ไม่ใช่หายไปใน chat

เพราะ agent ที่ทำงานจริง ไม่ได้ต้องการแค่ model ที่ฉลาดขึ้น

มันต้องการระบบที่จำความเสี่ยง ตรวจซ้ำได้ และหยุดถูกจุดก่อนเรื่องเล็กกลายเป็น incident