Agent Vault: เมื่อ AI Agent ไม่ควรถือ Secret เองอีกต่อไป

ถ้า AI agent จะเข้า production จริง คำถามที่น่ากลัวไม่ใช่แค่ว่า agent ฉลาดแค่ไหนครับ

แต่คือ agent ถือ secret อะไรอยู่ในมือบ้าง

ลองนึกภาพ coding agent หรือ workflow agent ที่ทำงานแทนเราได้หลายอย่าง:

• เรียก LLM API
• เปิด PR ใน GitHub
• อ่าน issue
• deploy ขึ้น cloud
• ส่งข้อความหาลูกค้า
• ยิง payment หรือ billing API
• อ่านข้อมูล CRM
• แตะข้อมูลส่วนตัวของลูกค้า

ถ้า agent ตัวนั้นมี API key, GitHub PAT, cloud credential, CRM token หรือ payment token อยู่ใน environment variable, config file, prompt หรือ sandbox memory

เรากำลังฝากความปลอดภัยไว้กับความหวังว่า agent จะไม่โดนหลอกครับ

และนี่คือเหตุผลที่ Infisical Agent Vault น่าสนใจมาก

ไม่ใช่เพราะมันเป็น secret manager อีกตัวหนึ่ง

แต่เพราะมันตั้งคำถามถูกจุด:

ถ้า AI agent ไม่ควรถือ secret เราจะออกแบบระบบให้มันไม่เห็น secret ตั้งแต่แรกได้ไหม?

Agent Vault คืออะไร

Agent Vault เป็น open-source project จาก Infisical ที่วางตัวเป็น HTTP credential proxy and vault for AI agents

คำอธิบายสั้น ๆ คือมันนั่งอยู่ตรงกลางระหว่าง agent กับ API service ที่ agent จะเรียก

แทนที่จะส่ง credential จริงให้ agent

เราส่ง agent ผ่าน proxy

Agent Vault เก็บ credential จริงไว้ใน vault แล้วค่อย inject credential ตอน outbound request วิ่งออกไปหา service ปลายทาง

ตัวอย่างเช่น agent อยากเรียก Anthropic API หรือ GitHub API

แทนที่จะใส่ ANTHROPIC_API_KEY หรือ GITHUB_PAT จริงใน environment ของ agent

เราใส่ dummy value หรือให้ agent ใช้ scoped session

จากนั้นบังคับให้ outbound HTTP/HTTPS traffic วิ่งผ่าน Agent Vault ผ่าน HTTPS_PROXY

Agent Vault ดูว่า request ไป host ไหน ตรงกับ service rule อะไร แล้วค่อยใส่ credential จริงให้ก่อน forward ไปยัง service ปลายทาง

ผลคือ agent ทำงานได้

แต่ agent ไม่เคยเห็น secret จริง

นี่คือแนวคิด credential brokering

ทำไม secret management แบบเดิมเริ่มไม่พอสำหรับ agent

Secret management แบบเดิมถูกออกแบบมาสำหรับ workload ที่ค่อนข้าง deterministic

แอปพลิเคชันดึง secret จาก vault แล้วใช้ตาม code path ที่ developer เขียนไว้

แต่ AI agent ไม่ได้ทำงานแบบนั้นเสมอไป

Agent อ่าน instruction จาก user

อ่านไฟล์

เปิดเว็บ

ดึงข้อมูลจาก external source

เรียก tool

รัน command

และอาจเจอ prompt injection จากเอกสาร webpage ticket issue หรือข้อมูลที่ผู้โจมตีควบคุม

ถ้า secret อยู่ในพื้นที่ที่ agent อ่านได้ ผู้โจมตีอาจหลอก agent ให้:

• print environment variables
• ส่ง token ออกไป endpoint ภายนอก
• เขียน secret ลงไฟล์หรือ log
• ใช้ credential ในทางที่ไม่ตรงกับงาน
• เรียก API เพื่อ exfiltrate data

Infisical เรียกปัญหานี้ว่า credential exfiltration

และถ้า credential หลุด ปัญหาจะไม่จบที่ key รั่ว

มันจะกลายเป็น data exfiltration เพราะ attacker เอา key นั้นไปใช้เข้าถึงระบบจริงต่อได้

นี่คือเหตุผลที่ short-lived token หรือ rotation อย่างเดียวไม่พอ

มันช่วยลดเวลาความเสียหาย แต่ไม่ได้แก้ข้อเท็จจริงว่า agent ยังสามารถคาย token ระหว่างที่ token ยังใช้ได้

แนวคิดสำคัญ: Agent ได้สิทธิทำงาน แต่ไม่ได้ถือกุญแจ

ผมชอบ framing นี้มากครับ

Agent ควรได้สิทธิทำงาน ไม่ใช่ได้ถือกุญแจบ้านทั้งพวง

Agent Vault แยกสิ่งนี้ออกจากกัน

Agent มี route ที่ใช้ทำงาน

แต่ credential จริงอยู่ใน vault

เวลาต้องเรียก API ตัว vault เป็นคนใส่ credential ให้ request นั้น

ถ้า agent โดน prompt injection แล้วพยายามอ่าน secret ก็ไม่มี secret ให้มันอ่าน

ถ้า agent พยายาม leak environment variable ก็เจอแค่ dummy value หรือ scoped session ที่ไม่ได้ใช้แทน secret จริงโดยตรง

แน่นอนว่ายังมีความเสี่ยงอื่นอยู่

Agent อาจ misuse permission ที่มีได้

เช่น เรียก API ที่ได้รับอนุญาตผิดงาน หรือส่งคำขอที่ไม่ควรส่ง

แต่ attack surface เปลี่ยนจาก “ขโมย token ไปใช้ที่ไหนก็ได้” เป็น “พยายาม misuse สิทธิผ่านช่องทางที่เราคุมและ log ได้”

อันนี้ควบคุมได้มากกว่าเยอะ

Agent Vault ทำงานตรง layer ไหน

จุดที่น่าสนใจคือ Agent Vault ไม่ได้แก้แค่ MCP

มันแก้ที่ layer ต่ำกว่า interface

Infisical อธิบายว่า agent อาจเรียก service ได้หลายแบบ:

• API โดยตรง
• CLI
• SDK
• MCP tool
• custom harness

แต่สุดท้าย request ส่วนใหญ่ก็กลายเป็น outbound HTTPS

Agent Vault จึงวางตัวเป็น forward proxy/MITM proxy ที่ agent ชี้ไปผ่าน HTTPS_PROXY

เมื่อ agent เรียก service เช่น api.github.com หรือ api.anthropic.com traffic จะผ่าน Agent Vault ก่อน

Agent Vault terminate TLS ด้วย CA ที่ agent trust, อ่าน request, strip หรือ inject auth header ตาม service rule, แล้วเปิด TLS connection ใหม่ไปยัง upstream จริง

จากมุม agent มันเหมือนเรียก API ปกติ

แต่ credential ไม่เคยอยู่ใน address space ของ agent

นี่คือเหตุผลที่ pattern นี้น่าสนใจกว่า “ทำ SDK อีกตัว”

เพราะ agent ไม่จำเป็นต้องเปลี่ยนวิธีใช้ทุก tool

เราคุมที่ egress layer แทน

Features ที่ควรสังเกต

จาก README และ docs จุดที่ควรจับตาได้แก่:

1) Credential brokering

Agent Vault สามารถแทน dummy credential เช่น __anthropic_api_key__ ด้วย credential จริง หรือ replace auth header ตอน outbound request

จุดนี้คือหัวใจของ tool

2) Transparent integration

agent ใช้ MCP, CLI, SDK หรือ API ได้ตามเดิม โดย bootstrap environment ให้ใช้ HTTPS_PROXY และ CA trust ของ Agent Vault

3) Egress filtering

กำหนดได้ว่า agent หรือ vault ไหนเข้าถึง service/API endpoint ไหนได้บ้าง

README ยังบอกว่าสามารถตั้ง strict deny mode ด้วย unmatched_host_policy=deny เพื่อ reject host ที่ไม่ match service rule

4) Request logging

Agent Vault log proxied request ในระดับ method, host, path, status, latency และ credential key names

แต่ตาม security docs ไม่ log bodies, headers หรือ query strings

อันนี้ดี เพราะเราต้องการ audit behavior โดยไม่ทำให้ log กลายเป็นที่รวม secret รอบใหม่

5) Network guard

Security docs ระบุว่า Agent Vault block cloud metadata endpoints เช่น 169.254.169.254 และมี protection สำหรับ private/link-local ranges, DNS rebinding, rate limiting และ token model

นี่สำคัญมาก เพราะ agent ที่มี proxy ไม่ควรใช้ proxy เป็นทางลัดเข้า internal infrastructure

6) Separate host recommendation

README บอกชัดว่า Agent Vault ควรอยู่คนละเครื่องหรือคนละ network boundary กับ AI agents เพื่อให้ agent เข้าถึง credential store โดยตรงไม่ได้

นี่คือเรื่องที่หลาย prototype มักข้าม

ถ้า vault กับ agent อยู่ host เดียวกันแบบไม่แยก isolation ดีพอ agent ที่รัน command ได้อาจเจาะไปอ่าน storage หรือ process รอบข้างได้

แต่ยังไม่ควรมองว่า production-ready แบบไม่ต้องคิด

จุดที่ต้องพูดตรง ๆ คือ Agent Vault ยังเป็น preview/research-preview

README ระบุว่า API subject to change

launch blog ก็ย้ำว่ายังต้องปรับ form factor, ergonomics, security และ scalability อีกมาก

ดังนั้นบทเรียนของ Deep Dive นี้ไม่ใช่ “ทุกบริษัทควรเอา Agent Vault เข้า production วันนี้”

บทเรียนที่สำคัญกว่าคือ:

credential brokering จะกลายเป็น pattern หลักของ production AI agents

Agent Vault เป็นหนึ่งใน source ที่อธิบาย pattern นี้ชัดมาก และเป็น sandbox ที่ดีสำหรับทีมที่อยากเข้าใจ architecture

แต่ถ้าจะใช้กับ production จริง ต้องมี security review, license review, network design, backup, monitoring, incident plan และการทดสอบ bypass scenario ก่อน

ทำไมเรื่องนี้สำคัญกับธุรกิจไทย

หลายธุรกิจไทยเริ่มใช้ AI agent แล้ว แต่ยังอยู่ใน pattern ง่าย ๆ:

• ใส่ API key ใน .env
• ให้ agent รันใน server หรือ laptop
• ให้ agent อ่าน repo
• ให้ agent เปิด PR
• ให้ agent call API
• ให้ agent deploy หรือแก้ config

ในช่วง prototype อาจพอรับได้

แต่ถ้า agent เริ่มแตะ production, customer data, payment, LINE OA, CRM, cloud, database หรือ GitHub organization จริง

secret handling ต้องเปลี่ยนครับ

เพราะ agent ไม่ใช่แค่ script

agent เป็น worker ที่รับคำสั่งจาก context จำนวนมาก และ context บางส่วนเราไม่ได้ควบคุม

ถ้า agent อ่าน issue ที่คนอื่นเขียนได้ issue นั้นอาจมี prompt injection

ถ้า agent เปิด webpage ได้ webpage นั้นอาจมี instruction แฝง

ถ้า agent อ่านเอกสารลูกค้าได้ เอกสารนั้นอาจมีข้อความที่พยายามหลอก agent

การบอก agent ว่า “ห้ามเปิดเผย secret” จึงไม่ใช่ control ที่พอ

control ที่ดีกว่าคือทำให้ secret ไม่อยู่ในที่ที่ agent อ่านได้

Checklist ก่อนให้ Agent แตะระบบจริง

ก่อนให้ agent ใช้งาน service ที่มี credential จริง ผมแนะนำให้ถาม 10 ข้อนี้

1. Agent จำเป็นต้องเห็น raw secret ไหม หรือแค่ต้องเรียก service ได้
2. Credential scope แคบที่สุดหรือยัง
3. ใช้ token แยกต่อ agent, per vault, per tenant หรือ per session ได้ไหม
4. outbound traffic ถูกบังคับผ่าน proxy หรือ server-side tool wrapper หรือยัง
5. agent สามารถ bypass proxy ด้วย network path อื่นได้ไหม
6. มี allowlist/deny policy สำหรับ host และ endpoint หรือยัง
7. log บอกได้ไหมว่า request ไหนใช้ credential อะไร โดยไม่เก็บ secret ลง log
8. action ที่แตะเงิน ลูกค้า production หรือ public channel มี human approval ไหม
9. ถ้า token หรือ session ถูก misuse จะ revoke/rotate/contain อย่างไร
10. tool ที่ใช้เป็น preview หรือ production-supported และใครรับผิดชอบตอน incident

ถ้าตอบไม่ได้ แปลว่ายังไม่ควรให้ agent ถือสิทธิ์แรง ๆ

เริ่มจาก read-only ก่อน

ต่อด้วย draft-only

จากนั้นค่อยให้ agent ทำ action ผ่าน approval gate

และเมื่อ workflow ชัดแล้วค่อยเพิ่ม brokered access ทีละส่วน

Agent Vault เทียบกับแนวทางอื่น

Agent Vault ไม่ใช่วิธีเดียวในการแก้ปัญหานี้

แนวทางอื่นที่ใช้ได้ เช่น:

• ให้ application server เป็นคนถือ secret แล้ว expose custom tool ที่ทำเฉพาะ action ที่อนุญาต
• ใช้ MCP server ที่ auth อยู่ฝั่ง server และ agent ไม่เห็น token
• ใช้ managed-agent platform ที่มี vault/proxy แยกจาก sandbox
• ใช้ short-lived credential ร่วมกับ egress allowlist และ audit log
• ใช้ dynamic credentials ที่ expire เร็วและ scope แคบ

สิ่งสำคัญคือหลักการเดียวกัน:

อย่าให้ agent ถือ secret มากกว่าที่จำเป็น

และถ้าเป็นไปได้ อย่าให้ถือ secret เลย

ให้ถือสิทธิผ่าน boundary ที่เราคุมได้แทน

มุมมอง Data-Espresso

ผมมอง Agent Vault เป็นสัญญาณว่า AI agent เริ่มโตจาก demo ไปสู่ production architecture

ช่วงแรกเราคุยกันเรื่อง model ไหนเก่งกว่า

ต่อมาเราคุยกันเรื่อง tool use, MCP, workflow, memory, multi-agent

แต่ถ้า agent จะทำงานจริงในองค์กร เราต้องคุยเรื่องที่น่าเบื่อขึ้น:

• secret อยู่ตรงไหน
• ใครมีสิทธิอะไร
• request ไปไหนได้บ้าง
• log อะไรเก็บได้ อะไรห้ามเก็บ
• revoke อย่างไร
• approval อยู่ตรงไหน
• ถ้า agent โดนหลอกเสียหายได้แค่ไหน

นี่แหละครับคือเส้นแบ่งระหว่าง “agent toy” กับ “agent system”

Agent toy ขอ API key แล้วไปลองเล่น

Agent system ต้องมี trust boundary

และ trust boundary ที่ดี ไม่ควรเริ่มจากการฝากกุญแจบ้านไว้กับ agent แล้วหวังว่ามันจะไม่ทำหาย

สรุป

Infisical Agent Vault สำคัญเพราะมันพูดเรื่องที่ production AI agents ต้องเจอแน่:

secret ไม่ควรอยู่ในมือ agent

Agent ควรทำงานผ่าน broker, proxy, tool wrapper หรือ platform boundary ที่ inject credential เฉพาะตอนจำเป็น และตรวจสอบย้อนหลังได้

สำหรับธุรกิจไทยที่กำลังเริ่มใช้ coding agents หรือ workflow agents กับงานจริง ผมจะจำประโยคนี้ไว้:

ถ้า agent โดน prompt injection แล้วอยากคาย secret

ระบบที่ดีควรทำให้มันไม่มี secret ให้คายตั้งแต่แรก

นั่นคือ mindset ที่ต่างจากการใช้ AI แบบทดลองเล่น

และเป็น mindset ที่ต้องมี ถ้าเราจะปล่อย AI agent เข้าใกล้ production จริงครับ