Pydantic AI Harness 0.61.0 ปรับ InputGuardrail หลังพบการแทนข้อความผิดส่วน

คำตอบสั้น: รุ่น pydantic-ai-harness 0.61.0 ที่เผยแพร่วันที่ 24 ตุลาคม และรีลีส Pydantic AI v2.61.0 มีการแก้พฤติกรรมใน Harness guardrails หลังผู้ดูแลพบว่า InputGuardrail อาจเขียนผลการปกปิดความลับลงในส่วนข้อความผิด เมื่อ capability อื่นเพิ่มข้อความในคำขอเดียวกัน ทำให้ข้อความลับเดิมอาจยังไปถึงโมเดล หรือบางกรณีอาจเกิด UserError ตามคำอธิบายของ PR #10841

นี่คือการแก้ข้อผิดพลาดของโค้ดที่พบระหว่างรีวิว capability ไม่ใช่รายงานว่ามีผู้ใช้ถูกโจมตีหรือข้อมูลรั่วจริง เราไม่ได้ติดตั้งหรือทดสอบแพ็กเกจเอง และไม่พบหลักฐานจากแหล่งที่ตรวจว่ามี CVE หรือเหตุการณ์โจมตีที่เชื่อมกับกรณีนี้

อ่านต่อ: การตรวจพิสูจน์โค้ดและขอบเขตหลักฐาน

เวอร์ชันที่ควรรู้ก่อนอ่านข่าว

ตัวเลขเวอร์ชันไม่ได้ใช้แทนกันได้: repository tag และแพ็กเกจ SDK หลักใช้ v2.61.0 / pydantic-ai 2.61.0; ส่วนไลบรารี Harness แยกเป็น pydantic-ai-harness 0.61.0 และ PyPI ระบุว่าอัปโหลดวันที่ 24 ตุลาคม 2026 รุ่น Harness นี้เป็นส่วนที่มี InputGuardrail ตาม PR ที่แก้

GitHub แสดงหัวข้อ release v2.61.0 เป็นวันที่ 23 ตุลาคม แต่รายการผู้ปล่อยแสดงเวลา 24 ตุลาคม 03:13 UTC (dd82a00) การแยกวันตามที่แต่ละหน้าแสดงช่วยเลี่ยงการเรียกเวลารวมกันว่าเป็นวันเดียวกัน

ก่อนแก้: guard อ่าน prompt หนึ่งส่วน แต่ไปเขียนทับอีกส่วน

ตาม PR #10841, InputGuardrail อ่านข้อความของผู้ใช้จาก ctx.prompt แต่เดิมเลือก UserPromptPart ตัวท้ายสุดใน request เพื่อเขียนข้อความที่ถูกแทนด้วย [redacted:…] กลับลงไป หาก capability อย่าง SystemReminders, Planning หรือ Memory เพิ่ม UserPromptPart เข้า request หลังข้อความผู้ใช้ guard จึงอาจเขียนทับข้อความเสริมแทน prompt เดิม ผลตามคำอธิบายผู้ดูแลคือความลับใน prompt เดิมอาจยังถูกส่งให้โมเดล หรือบางกรณีที่ใช้ SystemReminders เกิด UserError

หลังแก้ guard จะหา prompt ของรอบนั้นจากส่วนข้อความใน ctx.messages แล้วจับคู่กับส่วนใน request ด้วย object identity หรือ timestamp ที่ยังคงอยู่เมื่อ capability คัดลอกส่วนข้อความ ทำให้การแทนค่ากลับไปยังส่วนของ prompt เดิม ส่วนข้อความที่ capability เพิ่มไว้ยังอยู่

รีลีส v2.61.0 ยังระบุ PR #10852 ว่าปรับให้การ redact ของ InputGuardrail เขียนแก้ prompt ใน history ด้วย เมื่อโมเดลได้รับสำเนาของ prompt ไปแล้ว พร้อมปรับเอกสาร guardrails ให้ชัดขึ้น รายละเอียดนี้ชี้ว่าการปกปิดครอบคลุมทั้ง request ที่กำลังส่งและประวัติที่เก็บไว้เป็นบริบท แต่ข้อมูลที่เข้าถึงได้ในรอบนี้มีเพียงชื่อ PR จาก release note/ดัชนี commit จึงไม่ขยายความกลไกหรือขอบเขตเกินกว่านั้น

หากรอบที่กลับมาทำงานมี prompt หลายส่วน guard ยังคงตรวจภาพรวมเหมือน ctx.prompt แต่การแทนค่าที่เขียนทับทั้งกลุ่มจะทำให้เกิด UserError แทนการเขียนกลับแบบเสี่ยง ผลนี้เป็นขอบเขตสำคัญ: การแก้ช่วยกรณีระบุส่วนข้อความผิด ไม่ได้พิสูจน์ว่า guard จะตรวจพบความลับทุกแบบหรือครอบคลุมทุกเส้นทางข้อมูลของแอป

จุด fail-open ที่ยังเป็นการเตือน ไม่ใช่การปฏิเสธ

คำว่า “ปิดช่องทาง fail-open” ในชื่อ PR ควรอ่านควบคู่รายละเอียด compatibility: ถ้า guard ส่งค่าที่ไม่ใช่ True, False หรือ GuardrailResult เช่นสตริง ‘unsafe’ ค่า truthy ยังถูกตีความตาม truthiness และผ่านได้ รุ่น 0.61.0 เพิ่ม HarnessDeprecationWarning; PR ระบุว่ารุ่นอนาคตจึงจะยกระดับกรณีนี้เป็น UserError

ดังนั้นคำกล่าวว่า “รุ่นนี้บังคับปฏิเสธคำตัดสินที่ไม่ใช่ boolean แล้ว” จึงไม่ตรงกับรายละเอียดใน PR ทางปฏิบัติ ผู้พัฒนาไม่ควรคืน label หรือ None เพื่อสั่งบล็อก แต่ควรคืน boolean จริงหรือ GuardrailResult ตามรูปแบบ API

PR ยังแก้การอ่านอาร์กิวเมนต์ของ guard บาง signature: ฟังก์ชันที่ประกาศชนิดพารามิเตอร์แรกเป็น prompt: str และมีพารามิเตอร์ตัวที่สองพร้อมค่าเริ่มต้น จะรับ prompt ตามชนิดที่ประกาศ ไม่ใช่ RunContext อย่างเดิม ส่วน signature กำกวมที่พารามิเตอร์แรกไม่ระบุชนิด/ใช้ Any, object หรือแก้ชนิดไม่ได้ และพารามิเตอร์สองมีค่าเริ่มต้น ยังรับ RunContext พร้อมคำเตือน

การเปลี่ยนอื่นใน PR ลดการเก็บ guardrail.original ใน redaction span ซึ่งเคยเป็นจุดหนึ่งที่ข้อความซึ่งถูกปกปิดอาจปรากฏเมื่อเปิด content tracing และให้ ToolGuardrail ตรวจ raw ModelRetry/ToolFailed ที่เกิดระหว่างการทำงานของ tool ภายใต้ CodeMode ขอบเขตนี้ไม่รวม retry จาก hook ของ capability อื่นหรือผล verdict แบบ retry ของ ToolGuardrail เอง

สิ่งที่หลักฐานยืนยัน และยังไม่ยืนยัน

Release v2.61.0 อ้างอิง PR #10841 และ #10852 ในรายการ guardrail changes; ชื่อ PR #10852 ระบุการแก้ history prompt เมื่อโมเดลได้รับสำเนาไว้ด้วย. PR #10841 อยู่ในทั้งรายการ compatibility และ bug fixes ส่วน PR แสดงรายชื่อ unit tests ครอบคลุมการแทน prompt ข้าง SystemReminders, การที่ secret ไม่เข้า span เมื่อเปิด tracing, verdict ที่ไม่ใช่ boolean, การตีความ signature และ raw failure ใน CodeMode ผู้ดูแลระบุว่าไฟล์ทดสอบที่เกี่ยวข้องผ่านทีละไฟล์ และ pyright/ruff ผ่านในไฟล์ที่เปลี่ยน นี่เป็นผลทดสอบที่โครงการรายงาน ไม่ใช่การทดสอบอิสระของ Hybrid Mind

หลักฐานที่ตรวจยืนยันการเปลี่ยนโค้ดและการเผยแพร่รุ่น แต่ไม่ยืนยันเหตุการณ์โจมตี การรั่วไหลในระบบจริง จำนวนผู้ได้รับผลกระทบ หรือความปลอดภัยโดยรวมของ agent ที่ประกอบจาก capability หลายตัว แหล่งประกาศที่เราตรวจไม่ได้ให้ CVE หรือคำแนะนำว่าทุกแอปต้องดำเนินการตอบสนองเหตุการณ์

เช็กลิสต์สำหรับทีมที่ใช้ guardrail

• ตรวจว่า guard คืน boolean จริงหรือ GuardrailResult; อย่าใช้สตริง truthy เช่น ‘unsafe’ แทนคำสั่งปฏิเสธ
• ระบุ type ของพารามิเตอร์ให้ชัด โดยเฉพาะเมื่อมีพารามิเตอร์เสริมพร้อมค่าเริ่มต้น
• ทดสอบการประกอบ InputGuardrail กับ capability ที่เพิ่มหรือเขียน prompt ใหม่ใน request เดียวกัน รวมเส้นทางที่ resume และกรณีหลาย prompt parts
• อย่าถือว่าการ redaction ในแอปหนึ่งปิดบัง secret จาก model, trace, log และ tool ทุกจุดแล้ว ควรลด secret ที่ส่งเข้า context ตั้งแต่ต้นและจำกัดสิทธิ์/retention ของ log ตามระบบของตน

อินเทอร์แอ็กทีฟ: เมื่อมีข้อความเสริม จุดที่ต้องแก้เปลี่ยนอย่างไร

ตัวเลือกด้านล่างเป็นภาพจำลองเพื่อเรียนรู้จากลำดับที่ PR อธิบาย ไม่ได้เรียก Pydantic AI หรือทดสอบ runtime จริง ลองเลือกว่า request มี prompt จากผู้ใช้ส่วนเดียว หรือมีข้อความที่ capability เติมเข้ามา แล้วดูว่าจุดที่ InputGuardrail ต้องเขียนกลับควรเป็นส่วนใด เนื้อหาสำรองแสดงคำอธิบายเดียวกันได้โดยไม่พึ่ง JavaScript

สรุป

รุ่น Harness 0.61.0 แก้เส้นทางสำคัญที่ตัว guard ตรวจ prompt หนึ่งชุดแต่เคยเขียนผลการ redaction ลงส่วน request คนละตัว พร้อมปรับการส่งค่าคำตัดสินที่ไม่ใช่ booleanให้มีคำเตือนก่อนการเปลี่ยนเป็น error ในอนาคต ประเด็นที่ทีมพัฒนาควรทำต่อคือระบุชนิดผลลัพธ์ให้ชัด ตรวจการต่อ capability หลายตัว และทดสอบ log/trace ของแอปตนเอง โดยไม่ตีความ release note เป็นหลักฐานว่ามีการโจมตีหรือเป็นใบรับรองความปลอดภัย

คำถามที่พบบ่อย

นี่คือรายงานว่า Pydantic AI มีข้อมูลรั่วจริงหรือไม่?

ไม่ใช่ PR อธิบายความเสี่ยงเชิงโค้ดที่พบระหว่างรีวิว แต่ไม่ได้ระบุผู้เสียหายหรือเหตุการณ์โจมตี

pydantic-ai-harness 0.61.0 คือ pydantic-ai 2.61.0 หรือไม่?

ไม่ใช่ เป็นแพ็กเกจคนละตัวและมีเลขเวอร์ชันคนละสาย เรื่องนี้อ้าง tag repository v2.61.0 และรุ่น Harness 0.61.0 ตามหน้าของแต่ละแพ็กเกจ

รุ่น 0.61.0 ปฏิเสธ verdict แบบสตริงทุกกรณีแล้วหรือยัง?

ยัง PR ระบุว่าเกิด deprecation warning แต่ค่า truthy ยังถูกใช้ตาม truthiness; การยกระดับเป็น UserError จะเกิดในรุ่นอนาคต

ทีมที่ใช้ guardrail ควรทำอะไร?

คืน bool หรือ GuardrailResult, ระบุ type ของ guard ให้ชัด และทดสอบการประกอบกับ capability ที่แก้หรือเพิ่ม prompt parts โดยตรง

แหล่งอ้างอิง

• Pydantic AI release v2.61.0
• Merged PR #10841: InputGuardrail prompt redaction and guardrail paths
• Pydantic AI release v2.61.0, including PR #10852 history-prompt redaction follow-up
• PyPI: pydantic-ai-harness 0.61.0
• PyPI: pydantic-ai 2.61.0

หมายเหตุ: บทความนี้ยังไม่มีผลทดสอบซอฟต์แวร์อิสระ การไม่มีรายงานเหตุการณ์ในแหล่งที่ตรวจไม่ใช่หลักฐานว่าไม่เคยมีเหตุการณ์ดังกล่าว