ทั้งอุตสาหกรรมเพิ่งเห็นตรงกันว่า agent ของคุณไม่ควรเห็นคีย์ของคุณ แต่พวกเขาซ่อนมันไว้ผิดที่

สัปดาห์นี้ Anthropic ปล่อยบรรทัดหนึ่งใน changelog ของ Claude Code อย่างเงียบ ๆ: "Fixed MCP servers requiring authentication exposing auth-stub tools to the model in headless/SDK mode" [1] พูดให้เข้าใจง่าย — ตอนที่ Claude Code รันแบบ headless (ซึ่งเป็นวิธีที่มันรันใน CI และ automated agent pipelines) เครื่องมือยืนยันตัวตนที่ควรจะซ่อนอยู่ ถูกเปิดให้โมเดลเห็น: AI มองเห็นชื่อของ auth tool มองเห็นพารามิเตอร์ของมัน และอาจเข้าไปแตะต้องมันได้ ใน coding agent ที่มีคนใช้มากที่สุดในโลก — 133k stars — ชั้นของ credential กำลังรั่วไหลไปอยู่ในที่สุดท้ายที่คุณอยากให้มันไป นั่นคือ context ของโมเดลเองครับ

มันถูกแก้แล้ว แต่แพตช์เป็นเรื่องเล็ก เรื่องใหญ่คือ ทำไม harness สำหรับ agent ทุกตัวที่จริงจังถึงเพิ่งต้องมาสู้สมรภูมิเดียวกัน

สาม harness หนึ่งสัปดาห์ สัญชาตญาณเดียวกัน

ดูสิ่งที่ปล่อยออกมาในหน้าต่างเวลาเพียง 24 ชั่วโมง:

• Claude Code แพตช์ช่องโหว่ auth-stub ข้างบน และคุมการยืนยันตัวตนของ MCP ให้เข้มขึ้น [1]
• Hermes (v0.17.0) เพิ่ม "Managed Scope" — secrets ที่ admin ปักหมุดไว้ ผู้ใช้แก้ไขไม่ได้ ล็อกไว้ที่ filesystem เพื่อให้ผู้ดูแล agent ไม่สามารถ ลบทับได้ — พร้อม secret redaction ใน debug dumps และการบล็อก MCP configs ที่มีลักษณะของการดูดข้อมูลออกไป ก่อนที่มันจะถูกเปิดทำงาน [2]
• Codex (v0.141.0) ห่อทราฟฟิกการรันระยะไกลด้วย encrypted Noise channels และเริ่มจัดเส้นทางให้ปลั๊กอินตามโหมดการยืนยันตัวตนของแต่ละตัว [3]

คู่แข่งสามราย สามแนวทาง ข้อสรุปร่วมหนึ่งข้อ: harness ต้องเป็นเจ้าของ secrets และ agent ต้องไม่มีวันเห็นคีย์แบบดิบ เมื่อคู่แข่งมาบรรจบกันแบบนี้ภายในสัปดาห์เดียว มันไม่ใช่กระแสครับ มันคือหมวดหมู่หนึ่งที่เพิ่งยอมรับว่าตัวเองมีไว้เพื่ออะไร

ปัญหาถัดไปคือ credential sprawl

ข้อแม้มีอยู่ตรงนี้ แพตช์ทั้งหมดนั้นอยู่ ภายใน harness ทั้งสิ้น และบั๊กของ Claude Code คือหลักฐาน: เมื่อการยืนยันตัวตนอยู่ใน harness ข้าง ๆ โมเดล "agent ต้องไม่มีวันเห็นมัน" จะหยุดเป็นข้อเท็จจริง แล้วกลายเป็นสมบัติที่คุณต้อง วิศวกรรม มันอยู่เรื่อย ๆ — และบางครั้งก็พลาด ในโหมด headless ที่ไม่มีมนุษย์คอยมองอยู่ คุณประกาศมันครั้งเดียวไม่ได้ คุณต้องป้องกันมันทีละรีลีส

แต่ปัญหาที่ลึกกว่าไม่ใช่การรั่วไหลครั้งใดครั้งหนึ่ง — มันคือสิ่งที่เกิดขึ้นเมื่อทุก harness ทุก vendor และทุก use case ต่างปล่อย คำตอบของตัวเอง ออกมา คุณจะได้ vault หนึ่งใบใน Claude Code อีกใบใน Hermes อีกใบใน Codex มี OAuth pool อยู่ที่หนึ่ง มีไฟล์ secrets อยู่อีกที่ — คลัง credential แยกกันสำหรับทุกเครื่องมือที่คุณรัน นั่นคือ credential sprawl และมันคือปัญหาถัดไป ไม่ใช่ปัญหาที่ปิดไปแล้วครับ

Sprawl คือความล้มเหลว แม้ว่าไซโลเหล่านั้นจะไม่มีที่ไหนรั่วเลยก็ตาม secrets ของคุณจะถูกคัดลอกเข้าไปในแต่ละที่เพื่อให้มันทำงานได้ — สำเนามากขึ้น จุดที่จะขโมยมากขึ้น การหมุนเวียนคีย์ต้องทำ N ครั้งด้วยมือ และตัวที่คุณลืมคือตัวที่เผาคุณเอง และไม่มีใครตอบคำถามเดียวที่สำคัญจริง ๆ ได้ — agent ตัวไหนใช้คีย์ไหน กับอะไร เมื่อไร — เพราะคำตอบกระจายอยู่ในคลังหลายสิบใบที่ไม่คุยกัน คุณตั้ง vault ใหม่ขึ้นมาสำหรับทุก vendor และทุกเวิร์กโฟลว์ไม่ได้หรอกครับ มันไม่ขยายขนาดได้ และมัน คือ สิ่งที่จะพัง

คีย์ไม่ควรอยู่ใน harness ตั้งแต่แรก

แพตช์ที่คุณไม่ต้องปล่อยออกมาเลย คือแบบที่ agent ไม่ได้ถือการยืนยันตัวตนไว้ตั้งแต่ต้น วาง credentials ไว้ในอำนาจ หนึ่งเดียว ที่อยู่ นอก harness ทุกตัว — ไม่ใช่ vault หนึ่งใบต่อ vendor แต่เป็นหนึ่งเดียวที่อยู่ใต้ทั้งหมดนั้น ไม่ว่า agent จะอยู่ใน Claude Code ใน Codex หรือใน Hermes ก็ตาม มันขอดำเนินการหนึ่งอย่างที่ตั้งชื่อไว้ แล้วได้ credential แบบจำกัดขอบเขตและมีอายุสั้น ซึ่งถูกฉีดเข้ามาเฉพาะงานนั้น ดึงมาแบบสด ๆ และหายไปหลังใช้งาน ไม่มี auth-stub ใน context ของโมเดลให้เผลอเปิดเผย เพราะการยืนยันตัวตนไม่เคยอยู่ใน harness เลย ไม่มี sprawl เพราะมีคลังเดียวแทนที่จะเป็นคลังต่อเครื่องมือ — หมุนเวียนครั้งเดียว ไม่ใช่ N ครั้ง และการเข้าถึงทุกครั้งลงเอยที่ audit trail เดียว แทนที่จะกระจายอยู่ในไซโลหลายสิบใบที่ตอบไม่ได้ว่าใครใช้อะไร (การเก็บ secret ให้พ้นจากที่ที่โค้ดรันอยู่ อยู่อันดับต้น ๆ ของ กฎที่เครื่องมือจัดการ credential ควรยึดถือ — อุตสาหกรรมเพิ่งใช้เวลาหนึ่งสัปดาห์ค้นพบมันครับ)

และนี่คือส่วนที่เป็น security boundary ไม่ใช่เรื่องความสะดวก: credential ต้องไม่อยู่ในระบบเดียวกับ agent ถ้าวางไว้ด้วยกัน มันจะแชร์ blast radius ร่วมกัน — prompt injection หนึ่งครั้ง MCP server ที่ถูกวางยาหนึ่งตัว debug dump ที่ใช้ร่วมกันหนึ่งไฟล์ บั๊ก auth-stub ถัดไปอีกหนึ่งตัว แล้วอะไรก็ตามที่เข้าถึง agent จะเข้าถึงคีย์ไปพร้อมกัน นั่นคือเหตุผลที่แค่ "มองเห็น" ก็ถือว่ารั่วแล้ว: ทันทีที่ secret ไปอยู่ในที่ที่ agent มองเห็นได้ ให้ถือว่ามันรั่วไปแล้วและหมุนเวียนมันเสีย — อย่างที่ทีมที่รอบคอบทุกทีมปฏิบัติกับ auth-stub ของ Claude Code ในวันที่มันถูกปล่อยออกมาครับ ถือ credential ไว้ให้ห่าง ในระบบที่ agent ทำได้แค่ ขอ — ไม่อ่าน ไม่ถือ — ต่อให้ agent ถูกยึดทั้งตัว มันก็ยังดูดสิ่งที่ไม่เคยอยู่ในมือมันออกไปไม่ได้ มันขอดำเนินการอย่างหนึ่งได้ แต่มันหอบคีย์เดินออกไปไม่ได้ ระยะห่าง คือ การป้องกัน และ vault ที่อยู่ในกระบวนการเดียวกันนั้นไม่มีสิ่งนี้ในราคาใด ๆ

นั่นคือเส้นที่ Clavitor ขีดไว้ ทั้งวงการเพิ่งพิสูจน์หลักการนี้ไปแล้ว — agent ไม่ควรเห็นคีย์ เราเพียงแต่ไม่คิดว่าคุณควรต้องพิสูจน์มันซ้ำอีกครั้งในทุก harness ที่คุณรัน และเราไม่คิดว่าสิ่งที่ถือคีย์ของคุณควรเป็นสิ่งเดียวกับที่ผู้โจมตีเพิ่งยึดไปครับ

ให้เครดิตทีมงานฝั่ง harness ด้วย: secrets ที่ admin ปักหมุด encrypted relays ค่าเริ่มต้นแบบ fail-closed ล้วนเป็นงานวิศวกรรมที่ดีและจริงจัง แต่ "แพตช์ประจำสัปดาห์" สำหรับช่องโหว่ที่ผุดขึ้นซ้ำแล้วซ้ำเล่าไม่ใช่สถาปัตยกรรม — มันคืออาการ สถาปัตยกรรมคือการที่คีย์ไม่ได้อยู่ตรงนั้นให้รั่วตั้งแต่แรก

เมื่อคู่แข่งสามรายเย็บแผลเดียวกันในสัปดาห์เดียว แผลนั้นคือการออกแบบครับ agent ไม่ควรเห็นคีย์ของคุณ — ดังนั้นเลิกเก็บมันไว้ในที่ที่มันเห็นได้

Clavitor (@clavitorai) คือ credential vault ที่สร้างขึ้นสำหรับ AI agents และเพื่อรับมือกับมัน clavitor.ai

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

[1] Claude Code v2.1.183 — "Fixed MCP servers requiring authentication exposing auth-stub tools to the model in headless/SDK mode" — https://github.com/anthropics/claude-code/releases/tag/v2.1.183

[2] Hermes Agent v0.17.0 — Managed Scope (secrets ที่ admin ปักหมุด), secret redaction, การบล็อก exfil-config — https://github.com/NousResearch/hermes-agent/releases

[3] OpenAI Codex v0.141.0 — encrypted Noise relay channels, การจัดเส้นทางปลั๊กอินตาม auth-mode — https://github.com/openai/codex/releases