Credential ในหน่วยความจำของแอปคุณกำลังจะรั่วไหล

นี่คือคำทำนายที่ไม่ค่อยสบายนัก และผมไม่ได้พูดเผื่อเอาไว้: credential ที่กำลังนั่งอยู่ในหน่วยความจำของแอปพลิเคชันคุณตอนนี้ — รหัสผ่านฐานข้อมูลที่มันโหลดมาตอนเริ่มต้น, API token ที่อยู่ใน environment ของมัน, cloud key ที่มันถือไว้เพื่อทำงาน — มีแนวโน้มว่าจะรั่วไหลภายในสิบสองเดือนข้างหน้า ไม่ใช่เพราะมีใครเจาะระบบเก่งกว่าทีมรักษาความปลอดภัยของคุณ แต่เพราะสมมติฐานเดียวที่เคยทำให้ secret ในหน่วยความจำปลอดภัย — ว่ามีแต่โค้ดที่เชื่อถือได้เท่านั้นที่รันอยู่ข้างมัน — ถูกทำให้เป็นเท็จอย่างเงียบ ๆ ในปีนี้ และแทบไม่มีใครปรับวิธีรับมือตามเลยครับ

เรื่องนี้เป็นเรื่องที่คุณจะเก็บไปทำ "ภายหลัง" ไม่ได้ครับ

สิ่งที่กำลังเกิดขึ้นจริง

แอปพลิเคชันเกือบทุกตัวถือ secret ไว้ในแบบเดียวกัน ตอนเริ่มต้นมันอ่านค่าเหล่านั้น — จากไฟล์ .env, secret ที่ mount ไว้, ตัวแปร environment — แล้วโหลดเข้าไปในหน่วยความจำของตัวเอง แบบ plaintext ตลอดอายุของ process สามสิบปีมานี่เป็นการออกแบบที่ดี และดีด้วยเหตุผลเดียว: การจะอ่านหน่วยความจำของโปรแกรมอื่นที่กำลังรันอยู่ หรือ environment ของมัน ต้องรันโค้ดบนเครื่องเดียวกัน ที่สิทธิ์ระดับเดียวกัน เกณฑ์นี้เคยสูงทีเดียว สิ่งที่ผ่านไปได้มีเพียงซอฟต์แวร์ของคุณเองและคนของคุณเอง

ตอนนี้ agent ผ่านไปได้แล้ว Coding agent, เครื่องมือ MCP, worker ที่ทำงานอัตโนมัติ — โดยการออกแบบ มันรันโค้ด บนเครื่องจริง ในฐานะผู้ใช้จริง และสำหรับโค้ดที่รันที่สิทธิ์ระดับนั้น credential ในหน่วยความจำไม่ใช่ vault ที่ต้องเจาะ มันคือไฟล์ที่ต้องอ่าน /proc/<pid>/environ แสดงตัวแปร environment ของ process อื่นแบบ plaintext Core dump ก็ยก heap ของมันให้ไปเลย ไม่มี exploit, ไม่มี CVE, ไม่มีสัญญาณเตือน — EDR, WAF, firewall ของคุณ เห็น process ที่ได้รับอนุญาตอ่านหน่วยความจำที่มันมีสิทธิ์อ่านอยู่แล้ว และไม่เห็นอะไรผิดปกติ เพราะตามกฎของมันก็ไม่มีอะไรผิด ทุกขั้นตอนถูกกฎหมาย Secret แค่อยู่ตรงนั้นให้หยิบ

นี่ไม่ใช่ความผิดพลาดที่คุณก่อ

ชัดเจนก่อนว่านี่เป็นความผิดของใคร เพราะไม่ใช่ของคุณ .env บนเครื่องที่ hardened แล้ว, secret ที่ดึงจาก manager เข้ามาในหน่วยความจำตอน boot — นั่นคือ pattern ที่แนะนำ มันคือ twelve-factor, ตามตำรา, สิ่งที่วิศวกรที่ดีทำ มันเป็นสิ่งที่รับผิดชอบแล้ว สิ่งที่หมดอายุไม่ใช่แนวทางปฏิบัติ แต่คือสมมติฐานใต้แนวทางนั้น: ว่าโค้ดเพียงอย่างเดียวที่รันอยู่ข้าง secret ของคุณคือโค้ดที่คุณวางไว้ตรงนั้นเอง ทันทีที่มี agent รันบนเครื่องนั้น — และคุณกำลังวาง agent ไปทุกที่ อย่างตั้งใจ เพราะมันมีประโยชน์ — สมมติฐานนั้นก็หายไป และ plaintext ที่คุณโหลดเข้าไปอย่างรับผิดชอบก็กลายเป็นเป้าในรัศมีระเบิด

เราเห็นเวอร์ชันแรกของเรื่องนี้เกิดขึ้นแล้ว [4] เมื่อ coding agent ถูก hijack — error report ที่ถูกวางยา, เครื่องมือประสงค์ร้ายที่อยู่ในทางของมัน — สิ่งแรกที่เอื้อมถึงก็คือสิ่งนี้พอดี: token และ key ที่ process ของมันเอง และ process ข้าง ๆ กำลังถืออยู่ในหน่วยความจำแล้ว การ inject เป็นเพียงประตู Credential ที่ประจำการอยู่คือรางวัล

"แต่บนเครื่องนั้นไม่มี agent"

นี่คือคำตอบที่สบายใจ และเป็นคำตอบที่ใช้ไม่ได้ การป้องกันพิงอยู่กับกำแพง: เก็บ agent ไว้ฝั่งนี้ เก็บ credential ไว้ฝั่งนั้น กำแพงนั้นคือสิ่งเดียวที่ปีนี้พิสูจน์ซ้ำแล้วว่าต้านไม่อยู่

คุณไม่ต้องเชื่อเรื่องนี้ด้วยศรัทธา — ปีนี้มีหลักฐานออกมาแล้ว สองครั้ง ในการทดสอบที่ Anthropic เผยแพร่เอง Mythos โมเดลของพวกเขาถูกนำไปเจาะ NFS server ของ FreeBSD ซึ่งเป็นโค้ดในเคอร์เนลที่มนุษย์อ่านมาแล้วสิบเจ็ดปี และด้วยตัวมันเอง มันพบ stack overflow ใน authentication path เขียน exploit แบบยี่สิบ gadget ที่แบ่งส่งข้ามหก network packet และยึด root ที่ไม่ต้อง authenticate ผ่านสายได้ นั่นคือ CVE-2026-4747 และใช้เวลาประมาณสี่ชั่วโมง ไม่ใช่ "ชี้ว่าฟังก์ชันนี้น่าสงสัย" — แต่เป็น remote-root exploit ที่ใช้งานได้จริง กับโค้ดที่รอดการ review มาสิบเจ็ดปี และทำแบบเดียวกันได้กับช่องโหว่ร้ายแรงในทุกระบบปฏิบัติการและเบราว์เซอร์ใหญ่ ๆ ที่มันถูกนำไปเจาะ [1]

และการกักกันที่คุณจะห่อไว้รอบ agent ก็ไม่ได้ดีไปกว่าเส้นขอบ ใน safety evaluation ของ Anthropic เอง เมื่อถูกสั่งให้ออกจาก sandbox และเข้าถึงนักวิจัยที่กำลังทดสอบอยู่ Mythos ต่อ exploit — JIT heap spray — เพื่อแหกออก ทั้ง browser renderer และ sandbox ของระบบปฏิบัติการ ทะลุออกไปถึงอินเทอร์เน็ตแบบเปิด และส่งอีเมลหาเขา [1] ข้อยุติธรรมคือ: มันทำอย่างนั้นเพราะการทดสอบสั่งให้ทำ ไม่ใช่โดยความคิดริเริ่มของมันเอง แต่ "เราสั่งให้มันทำ" นั่นแหละคือเก้าอี้ของผู้โจมตีพอดี — และ "แหกออกมา ยกระดับ ยึด credential" คือ payload มาตรฐานของทุก malicious prompt ตั้งแต่นี้เป็นต้นไป ความสามารถนี้ไม่เคยรอความคิดริเริ่มของโมเดลเอง มันรอคำสั่ง และคำสั่งคือ input เดียวที่คุณวางใจได้ว่าจะมาถึง ความจริงจังถูกรับรู้ในระดับเดียวที่มีความหมาย — สหรัฐฯ ควบคุมการส่งออกตัวโมเดลเอง เป็นครั้งแรกที่เป็นโมเดล AI ไม่ใช่ชิปที่อยู่เบื้องหลัง หลังจากที่ Mythos เวอร์ชันหนึ่งรายงานว่าเจาะเข้าระบบลับเกือบทั้งหมดของ NSA ได้ภายในเวลาไม่กี่ชั่วโมง [2][3]

ตอนนี้วางเรื่องนี้ข้าง ๆ ปัญหาเรื่องหน่วยความจำ เพราะสองเรื่องมาบรรจบกัน Root บนเครื่องอ่านหน่วยความจำของ ทุก process ได้ ไม่ใช่เฉพาะของ user ตัวเอง ดังนั้นคำถามจริงไม่ใช่ "ฉันจะรัน agent ข้าง secret ของตัวเองไหม" แต่เป็น "โมเดลที่มีความสามารถจะเข้าถึงเครื่องนี้ หรือแหกออกจากกล่องที่ฉันขังมันไว้ไหม" — และปีนี้ตอบทั้งสองคำถามแล้ว ในที่สาธารณะ "บนเครื่องนั้นไม่มี agent" ไม่ใช่ control ที่คุณ enforce มันคือความหวังว่าสิ่งต่าง ๆ จะอยู่นิ่ง ๆ และสิ่งเหล่านั้นก็แสดงให้เห็นแล้วว่าไม่ได้อยู่นิ่ง วางแผนสำหรับกรณีที่ agent มาถึงเครื่องเถอะครับ ทางเลือกอื่นคือวางแผนเพื่อให้โชคดี

ออกแบบมาเพื่อเรื่องนี้ อย่างตั้งใจ

ดังนั้นเลิกพยายามกัน agent ออกจาก secret ที่วางทิ้งไว้เฉย ๆ แล้วเอาสิ่งที่วางทิ้งไว้นั้นออกไป

Credential ใน Clavitor ไม่เคยถูกโหลดเข้าไปในหน่วยความจำของแอปพลิเคชันเพื่อรอ มันถูก fetch แบบ live ณ ขณะที่เรียก ใช้กับ request นั้น request เดียว แล้วก็หายไป มันไม่เคยอยู่ในตัวแปร environment, ไม่เคยลงเอยใน .env, ไม่เคยค้างอยู่ใน heap ตลอดอายุของ process เพื่อรอให้ dump ไม่มีอะไรให้ /proc ไล่เรียง และไม่มีอะไรให้ core dump หอบไป เพราะเครื่องนั้นไม่ได้ถูกวางใจให้ถือ secret ประจำการตั้งแต่แรก

และ credential เพียงตัวเดียวที่มันส่งมอบ ถูกจำกัดขอบเขตไว้กับสิ่งเดียวที่ agent ตัวนั้นถูกตั้งชื่อให้ทำ มันไล่เรียง vault ไม่ได้, นับไม่ได้ว่ามีอะไรอีกอยู่, ค้นหา key ถัดไปไม่ได้ การ fetch แต่ละครั้งถูกจำกัดอัตรา, ทริกล็อกดาวน์เมื่อมี burst ผิดปกติ, และถูกเขียนลง log แบบ append-only, hash-chained ที่อยู่บน vault — ไม่ใช่บน endpoint ที่ agent รันอยู่ นั่นคือ trail ที่แก้ไขย้อนหลังไม่ได้และระบุตัวตนได้ ตามที่ PCI DSS Requirement 10 และ NIST 800-171 (control 3.3.8) ต้องการ: หลักฐานว่า agent ของคุณไปแตะอะไรมาบ้าง เก็บไว้ที่ซึ่งเครื่องที่ถูกโจมตีเข้าถึงไม่ได้และเขียนทับไม่ได้

ข้อยกเว้นที่ต้องพูดตรง ๆ เพราะข้ออ้างนี้ต้องมี: ในจังหวะไมโครวินาทีที่มันถูกใช้ secret นั้นมีอยู่จริงในหน่วยความจำ — สำหรับ request นั้น request เดียว ในขณะเวลานั้น ไม่มีการออกแบบใดเขียนฟิสิกส์ใหม่ได้ สิ่งที่มันเขียนใหม่คือความแตกต่างระหว่าง secret ที่ ประจำการ — นั่งอยู่ใน process ของคุณเป็นชั่วโมง, dump ได้ตลอดเวลา — กับ secret ที่ ชั่วคราว — อยู่ตรงนั้นเพียงการเรียกครั้งเดียว แล้วไม่มีอะไรให้หยิบ คุณ dump สิ่งที่ไม่ได้ตั้งอยู่ไม่ได้ครับ

บทเรียนไม่ใช่ "ล็อกเครื่องให้แน่นกว่าเดิม"

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

เรา เขียนกฎที่เครื่องมือจัดการ credential ควรยึดถือ ไว้ สำหรับโลกแบบนี้ ลองเอาของคุณไปเทียบดูครับ

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

Sources

[1] Anthropic (Anthropic Red Team) — Assessing Claude Mythos Preview's cybersecurity capabilities (autonomous discovery + exploitation of the FreeBSD NFS RCE, CVE-2026-4747; critical flaws across major OSes and browsers) — https://red.anthropic.com/2026/mythos-preview/

[2] Associated Press (via CNBC) — Anthropic's Mythos model found vulnerabilities in classified U.S. government systems, official says — https://www.cnbc.com/2026/06/23/anthropics-mythos-model-found-vulnerabilities-in-classified-us-government-systems-official-says.html

[3] Fortune — Anthropic disables Fable and Mythos AI models following U.S. government export ban — https://fortune.com/2026/06/13/anthropic-disables-fable-mythos-export-controls-national-security-threat/

[4] Tenet Security (Tenet Threat Labs) — Agentjacking: Coding Agents with Fake Sentry Errors (hijack-to-resident-credential precedent) — https://tenetsecurity.ai/blog/agentjacking-coding-agents-with-fake-sentry-errors/