API key

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

รูปแบบของแต่ละเจ้าต่างกันแต่หลักการเดียวกัน ตัวอย่างที่เห็นชัดคือฝั่ง anthropic ซึ่งเอกสารทางการระบุว่าคีย์เป็นค่าคงที่ขึ้นต้นด้วย sk-ant-api และต้องแนบมาในเฮดเดอร์ชื่อ x-api-key ของทุกคำขอ หรือจะตั้งเป็น environment variable ชื่อ ANTHROPIC_API_KEY ให้ SDK หยิบไปใช้เองก็ได้ ฝั่ง openai เอกสาร production best practices ก็แนะนำแนวเดียวกันคือให้ส่งคีย์เข้าแอปผ่าน environment variable หรือ secret management service แทนการฝังไว้ในโค้ด ทางเลือกที่ตัดคีย์ถาวรออกจากระบบไปเลยก็เริ่มมีแล้ว เอกสารของ Anthropic อธิบายวิธีที่ชื่อ Workload Identity Federation ว่าเป็นการให้ระบบงานเอา token จาก identity provider ที่องค์กรใช้อยู่แล้วไปแลก access token อายุสั้น จึงไม่มีสาย sk-ant-api ให้ต้องสร้าง แจกจ่าย หรือหมุนอีกต่อไป โดยเอกสารกำกับไว้ด้วยว่าวิธีนี้ไม่ได้การันตีความปลอดภัยครบวงจรด้วยตัวมันเอง เพราะห่วงโซ่ความเชื่อถือแข็งแรงเท่ากับการตั้งค่า identity provider ของเราเท่านั้น หน้า API overview ของ Anthropic ยังระบุว่าเมื่อเรียกโมเดลผ่านแพลตฟอร์มคลาวด์ การพิสูจน์ตัวตนจะไปผูกกับระบบ IAM ของผู้ให้บริการคลาวด์แทน เส้นทางคลาวด์แบบนี้ก็คือของอย่าง amazon-bedrock ฝั่ง AWS ที่ให้บริการโมเดลของ Anthropic และ azure-openai ฝั่ง Microsoft ที่ให้บริการโมเดลของ OpenAI

เหตุผลที่คำนี้กลายเป็นความเสี่ยงอันดับต้นๆ ตอนองค์กรเริ่มต่อ AI เข้าระบบตัวเอง คือคีย์มักหลุดออกไปโดยไม่มีใครรู้ตัว รายงาน State of Secrets Sprawl 2026 ของ GitGuardian ที่เผยแพร่วันที่ 17 มีนาคม 2026 นับได้ว่ามี secret ที่ถูกฝังตรงๆ ในโค้ดโผล่ขึ้น public GitHub ถึง 28.65 ล้านรายการภายในปี 2025 เพิ่มขึ้น 34% จากปีก่อนหน้า ส่วนคีย์ของบริการ AI รายงานนับได้ 1,275,105 รายการในปี 2025 เพิ่มขึ้น 81% จากปีก่อน รายงานฉบับเดียวกันยังพบว่า commit บน public GitHub ที่มี Claude Code ร่วมเขียนมีอัตราการหลุด secret 3.2% เทียบกับค่าฐาน 1.5% ของ commit ทั้งหมด หรือราวสองเท่า โดยรายงานวัดผู้ช่วยเขียนโค้ดตัวนี้ตัวเดียว ไม่ได้ครอบคลุมโค้ดที่มี AI ช่วยทุกแบบ และของเก่าก็ไม่ได้หายไปไหน เพราะเมื่อเอา credential ที่เคยยืนยันว่ายังใช้งานได้ในปี 2022 กลับมาทดสอบซ้ำในเดือนมกราคม 2026 พบว่ายังใช้งานได้อยู่เกิน 64%

คำแนะนำของทั้งสองเจ้าไปในทางเดียวกันเป็นส่วนใหญ่ ข้อแรกคืออย่าฝังคีย์ไว้ในโค้ดหรือใน repository สาธารณะ ให้เก็บใน secrets manager แล้วดึงมาใช้ตอนรัน ข้อสองคือเอกสารของ Anthropic แนะนำให้หมุนคีย์เป็นระยะ และข้อสามคือถ้าสงสัยว่าคีย์หลุด ให้เพิกถอนทันทีแล้วออกใบใหม่ ไม่ต้องรอหลักฐานว่ามีคนใช้จริง เอกสารความปลอดภัยของ OpenAI ใช้คำว่าให้ revoke โดยเร็วแล้วแทนที่ด้วยคีย์ใหม่เมื่อเชื่อว่าคีย์ถูกเปิดเผยหรือถูกใช้ในทางที่ผิด

เครื่องมือช่วยจำกัดความเสียหายก็มีเพิ่มขึ้น ฝั่ง Anthropic ตอนสร้างคีย์ในคอนโซลจะให้เลือกอายุของคีย์ได้ตั้งแต่แบบสำเร็จรูปคือ 3 ชั่วโมง 1 วัน 7 วัน หรือ 30 วัน จะกำหนดเองก็ได้ หรือเลือก Never สำหรับคีย์ที่เก็บใน secrets manager และหมุนเองอยู่แล้ว โดยถ้าองค์กรตั้งนโยบายอายุคีย์สูงสุดไว้ คอนโซลจะจำกัดตัวเลือกไม่ให้เกินนโยบายนั้นและจะไม่มีตัวเลือก Never ให้เลือก จุดที่ต้องรู้ล่วงหน้าคืออายุคีย์ถูกกำหนดตอนสร้างและแก้ทีหลังไม่ได้ พอหมดอายุแล้วคำขอที่ใช้คีย์นั้นจะได้ error 401 กลับมา และคีย์ที่หมดอายุไปแล้วปลุกคืนไม่ได้ ต้องสร้างใหม่อย่างเดียว เอกสารยังเตือนไว้ตรงๆ ว่าการตั้งวันหมดอายุช่วยจำกัดอายุของคีย์ที่หลุดเท่านั้น ไม่ได้ใช้แทนวินัยการเก็บความลับได้ ส่วนการแบ่ง workspace มีไว้แยกคีย์ตามโปรเจกต์หรือตามสภาพแวดล้อมและคุมค่าใช้จ่ายแยกกัน ซึ่งฝั่ง OpenAI ก็แนะนำให้แยกโปรเจกต์ระหว่าง staging กับ production เพราะตั้งเพดาน rate limit และเพดานค่าใช้จ่ายแยกรายโปรเจกต์ได้ จุดนี้ต่อตรงกับเรื่อง ai-spend-cap เพราะคีย์ที่ไม่มีเพดานคือใบเบิกที่ไม่มีวงเงิน

อีกชั้นที่หลายองค์กรไม่รู้ว่ามีอยู่แล้วคือ secret scanning ของ GitHub ซึ่งทำงานอัตโนมัติและไม่มีค่าใช้จ่ายสำหรับ repository สาธารณะ และเมื่อพบคีย์ของผู้ให้บริการที่เข้าร่วมโครงการพันธมิตร GitHub จะแจ้งผู้ให้บริการเจ้านั้นเพื่อให้จัดการต่อ เช่นเพิกถอนคีย์ ข้อดีคือมันเป็นตาข่ายรองรับจริง ข้อควรระวังคือมันเป็นด่านสุดท้าย ไม่ใช่ด่านแรก และครอบคลุมเฉพาะสิ่งที่อยู่บน GitHub คือประวัติ Git ทุก branch รวมถึงหัวข้อและคอมเมนต์ใน issue ใน pull request ใน Discussions และใน wiki ส่วนคีย์ที่หลุดผ่านช่องทางอื่นอย่างการแปะในแชท ในระบบตั๋วงานภายนอก หรือในสไลด์นำเสนอ ระบบนี้มองไม่เห็น อีกช่องทางที่องค์กรมักมองข้ามคือ shadow-ai แบบที่พนักงานสมัครบัญชีส่วนตัวแล้วออกคีย์เอง เพราะคีย์แบบนั้นองค์กรมองไม่เห็น เพิกถอนไม่ได้ และไม่รู้ด้วยซ้ำว่าข้อมูลอะไรถูกส่งออกไปแล้วบ้าง

ตัวอย่างจากบทสนทนาจริง

ฝ่ายจัดซื้อ: "เดือนนี้บิลค่า AI ขึ้นมาสามเท่า ทั้งที่ทีมบอกว่าใช้เท่าเดิม เกิดอะไรขึ้น"

ทีม IT: "กำลังไล่อยู่ครับ ตอนนี้เราใช้คีย์เดียวกันทั้งระบบทดสอบและระบบจริง เลยแยกไม่ออกว่ายอดมาจากตรงไหน ขอแยก workspace หรือโปรเจกต์ตามการใช้งาน ออกคีย์แยกกันคนละใบ แล้วตั้งเพดานค่าใช้จ่ายของแต่ละ workspace หรือแต่ละโปรเจกต์ก่อน จะได้เห็นว่าใครใช้เท่าไหร่ ถ้าเป็นคีย์ที่หลุดออกไปข้างนอกจริง จะได้เพิกถอนเฉพาะตัวนั้นโดยไม่ต้องหยุดทั้งระบบ"

หัวหน้าฝ่ายการตลาด: "น้องในทีมทำ automation ต่อกับโมเดลไว้เอง เขาบอกว่าใส่คีย์ไว้ในไฟล์โค้ดแล้วมันก็ทำงานได้ปกติ ต้องแก้ไหม"

ทีมความปลอดภัย: "ต้องแก้ครับ ทำงานได้กับปลอดภัยเป็นคนละเรื่องกัน ถ้าไฟล์นั้นถูกอัปขึ้น repo หรือส่งต่อให้ vendor เมื่อไหร่ คีย์ก็หลุดทันที และคนที่ได้ไปยิงค่าใช้จ่ายเข้าบัญชีบริษัทเราได้เลย ย้ายไปเก็บใน secrets manager แล้วออกคีย์ใหม่ ส่วนคีย์เดิมเพิกถอนทิ้งครับ"

ระวังสับสนกับ

• api : API คือช่องทางที่ผู้ให้บริการเปิดให้ระบบอื่นเรียกใช้งาน ส่วน API key คือกุญแจที่ใช้เปิดช่องทางนั้นและใช้ระบุว่าคำขอนี้ต้องคิดเงินกับบัญชีไหน มี API แต่ไม่มีคีย์หรือ credential อื่นที่ผู้ให้บริการรับรอง ก็เรียกไม่ได้
• dlp : DLP คุมว่าข้อมูลประเภทไหนออกจากองค์กรได้บ้าง ส่วน API key คุมว่าใครเรียกใช้โมเดลได้ คนละด่านกัน คนที่ถือคีย์ถูกต้องยังส่งข้อมูลลับออกไปได้อยู่ดีถ้าไม่มี DLP คุมอีกชั้น
• zero-data-retention : เป็นข้อตกลงว่าผู้ให้บริการจะไม่เก็บข้อมูลที่เราส่งเข้าไป เป็นคนละเรื่องกับการปกป้องคีย์ ต่อให้มีข้อตกลงนี้ คีย์ที่หลุดก็ยังถูกเอาไปใช้ยิงค่าใช้จ่ายเข้าบัญชีเราได้เหมือนเดิม