LiteLLM v1.84.8: AI Gateway ต้องมีลายเซ็น ก่อนปล่อย Agent แตะงานจริง

LiteLLM v1.84.8 เป็น release ที่ถ้าอ่านผ่าน ๆ อาจดูเหมือน maintenance release ครับ

แต่หัวข้อแรกใน release note กลับไม่ใช่ feature ใหม่ที่หวือหวา มันคือคำแนะนำให้ verify Docker image signature ด้วย cosign

ประโยคนี้สำคัญกว่าที่ดูมาก

เพราะในโลก AI Agent วันนี้ gateway, proxy, tool server และ MCP server กำลังขยับจาก “ของช่วย dev” ไปเป็น “โครงสร้างพื้นฐานของงานจริง”

ถ้า agent หลายตัวในบริษัทต้องผ่าน gateway เดียวกันก่อนเรียก model ข้างนอก gateway นั้นไม่ใช่แค่กล่องเทคนิคแล้วครับ มันคือด่านตรวจของ AI ทั้งองค์กร

1) LiteLLM คืออะไรในมุม operator

จาก docs ของ LiteLLM ตัว project วางตัวเป็น unified interface สำหรับเรียก LLM providers จำนวนมากผ่านรูปแบบ OpenAI API

พูดง่าย ๆ คือ developer ไม่ต้องเขียน logic แยกสำหรับทุก provider จะเรียก OpenAI, Anthropic, Vertex AI, Bedrock, Ollama หรือ provider อื่น ๆ ก็ทำผ่าน interface เดียวได้

อีกส่วนที่สำคัญกว่าคือ LiteLLM Proxy หรือ LLM Gateway

ชั้นนี้ช่วยทำเรื่องอย่างเช่น:

• virtual keys
• routing
• retry และ fallback
• load balancing
• cost tracking
• admin UI
• centralized management

สำหรับ application ปกติ นี่คือ proxy ที่สะดวก

แต่สำหรับ AI Agent นี่คือจุดคุมชีวิตของระบบครับ

เพราะ agent ไม่ได้แค่ถามตอบ มันอาจอ่านเอกสารลูกค้า สรุป lead เขียน code เปิด ticket สั่ง tool หรือทำงานหลาย step ผ่าน model หลายตัว

ถ้าทุกอย่างวิ่งผ่าน LLM Gateway ชั้นนี้จึงกลายเป็นทั้งประตู, สมุดบัญชี, firewall, และ black box recorder ของระบบ AI

2) ทำไม signed Docker image ถึงเกี่ยวกับ AI Agent

ใน release v1.84.8 LiteLLM ระบุว่า Docker images ถูก signed ด้วย cosign และแนะนำการ verify image ด้วย public key

จุดที่น่าสนใจคือ release แนะนำให้ verify ด้วย key ที่อ้างอิงจาก commit hash ที่กำหนดไว้ เพราะ commit hash เปลี่ยนย้อนหลังไม่ได้ง่ายเหมือน tag

ประเด็นนี้ไม่ใช่แค่เรื่อง “security best practice” แบบในตำรา

มันตอบคำถามพื้นฐานมาก:

เรากำลังรันของจริงจาก project ที่เราตั้งใจใช้ หรือกำลังรัน image ที่เราแค่เชื่อว่าเป็นของจริง?

ในระบบทั่วไป ถ้าดึง image ผิด อาจทำให้ app ล่มหรือข้อมูลรั่ว

ในระบบ agent ผลกระทบอาจกว้างกว่า เพราะ gateway เป็นจุดที่ agent ใช้เรียก model, ถือ key, route request และสร้าง log การทำงาน

ถ้าชั้นนี้ไม่น่าเชื่อถือ agent ทั้งชุดก็ไม่น่าเชื่อถือครับ

3) AI Gateway ไม่ควรถูกมองเป็นแค่ proxy

นี่คือจุดที่ผมอยากย้ำที่สุด

หลายทีมเริ่มใช้ gateway เพราะอยากสลับ model ง่ายขึ้น หรืออยากควบคุม cost

เหตุผลนั้นถูกครับ แต่ยังไม่พอ

เมื่อ agent เข้าไปอยู่ใน workflow จริง gateway ควรทำหน้าที่อย่างน้อย 4 ชั้น

ชั้นที่ 1: Artifact trust

ก่อน deploy ต้องรู้ว่า image มาจากไหน

มี signature ไหม verify ได้ไหม pin version หรือ digest ไว้หรือเปล่า หรือทุกอย่างยังดึง latest ด้วยความหวังว่าไม่น่ามีอะไรผิด

ชั้นที่ 2: Model policy

agent ตัวไหนเรียก model ไหนได้ งานแบบไหนใช้ model แพงได้ งานไหนต้องใช้ local model ถ้า provider หนึ่งล่ม fallback ไปไหน ถ้า fallback แล้วคุณภาพเปลี่ยน ใครรู้ก่อนลูกค้า

ชั้นที่ 3: Permission boundary

gateway ถือ key หรือไม่ key นั้น scope แคบแค่ไหน มี per-agent key หรือทุก agent ใช้ key เดียวกัน มี budget limit ต่อทีม ต่อ project หรือต่อ workflow หรือยัง

ชั้นที่ 4: Proof and incident path

เมื่อ agent ทำงานผิด เราไล่ย้อนหลังได้ไหมว่า:

• prompt หรือ request คืออะไร
• เรียก model ตัวไหน
• cost เท่าไร
• tool ไหนถูกเรียกต่อ
• ใคร approve
• log อยู่ที่ไหน
• rollback อย่างไร

ถ้าไม่มีชั้นนี้ AI จะดูเหมือนทำงานได้ดีมาก จนถึงวันที่มันพลาดแล้วไม่มีใครรู้ว่าพลาดตรงไหน

4) บทเรียนสำหรับธุรกิจไทย

ถ้าคุณเป็น SME หรือทีมเล็ก ไม่ได้แปลว่าต้องมีระบบ security ระดับ enterprise ตั้งแต่วันแรกครับ

แต่ถ้าเริ่มเอา AI ไปแตะงานจริง เช่น support, lead, contract, invoice, code, report หรือข้อมูลลูกค้า คุณควรเริ่มมี checklist ง่าย ๆ ก่อน

ผมแนะนำ 5 ข้อ

1) อย่า deploy gateway ด้วย latest แบบไม่รู้ version

2) เก็บ release note และ source URL ของ version ที่ใช้

3) ถ้า project มี signed image ให้เพิ่ม signature verification เข้า deployment checklist

4) แยก key ตาม environment และตาม agent เท่าที่ทำได้

5) เก็บ log ที่ตอบคำถามได้ว่า agent เรียก model อะไร เมื่อไร ด้วยเหตุผลอะไร

แค่นี้ก็ลดความเสี่ยงได้เยอะแล้ว

ไม่ต้องเริ่มจากระบบใหญ่ เริ่มจาก proof ที่ตรวจซ้ำได้ก่อน

5) แล้วควรทำอะไรต่อ

ถ้าทีมคุณใช้ LiteLLM หรือ gateway ลักษณะคล้ายกัน ผมจะไม่เริ่มจากการถามว่า “มี feature อะไรใหม่”

ผมจะถามว่า:

• gateway version ปัจจุบันคืออะไร
• deploy จาก image ไหน
• image นั้น verify ได้ไหม
• key อยู่ตรงไหน
• agent แต่ละตัวใช้สิทธิ์เท่ากันหมดหรือไม่
• มี cost cap หรือไม่
• มี fallback path หรือไม่
• มี log พอสำหรับ audit หรือ incident review หรือยัง

คำถามพวกนี้อาจไม่ sexy เท่า benchmark ใหม่ แต่เป็นคำถามที่ทำให้ AI ใช้ในงานจริงได้ปลอดภัยขึ้น

สรุป

ในความเห็นของผม LiteLLM v1.84.8 เป็น signal ที่ดี เพราะมันเตือนเราว่า infrastructure รอบ AI Agent สำคัญพอ ๆ กับตัว model

AI ที่เก่งขึ้นเรื่อย ๆ ต้องมีชั้นควบคุมที่พิสูจน์ได้มากขึ้นเรื่อย ๆ ด้วย

สำหรับ operator บทเรียนคือ:

อย่าดูแค่ว่า agent เรียก model ได้ไหม ให้ดูด้วยว่าประตูที่ agent ทุกตัวต้องผ่านนั้น verify ได้แค่ไหน

สุดท้าย AI Gateway ที่ดีไม่ใช่แค่ต่อ model ได้หลายเจ้า แต่ต้องทำให้ทีมตอบได้ว่า “ของที่รันอยู่มาจากไหน ใช้สิทธิ์อะไร และตรวจย้อนหลังได้อย่างไร”