คีย์ AI API ที่ถูกขโมยไปตอนนี้กลายเป็นตัวจ่ายเงินให้การแฮ็กของคนอื่น ในเดือนตุลาคม 2026 ทีมข่าวกรองภัยคุกคามของ Bitsight ได้อธิบายถึง MONST3R-AI เครื่องมือที่ขายในฟอรัมอาชญากรรม ซึ่งรันการสแกนทดสอบเจาะระบบแบบอัตโนมัติบนคีย์ OpenAI, Anthropic และ Google ที่ถูกขโมยมา ผู้ซื้อนำคีย์มา เอเจนต์ทำการสแกน และเจ้าของคีย์เป็นคนรับบิล คู่มือนี้ครอบคลุมว่าคีย์รั่วไหลได้อย่างไร จะสังเกตการใช้งานในทางที่ผิดได้อย่างไร และการควบคุมที่แต่ละผู้ให้บริการมีให้ในปัจจุบัน
การปกป้องคีย์ OpenAI, Anthropic หรือ Gemini ให้จำกัดขอบเขตให้อยู่กับโปรเจกต์หรือเวิร์กสเปซเดียว ตั้งเพดานการใช้จ่ายรายเดือนแบบตายตัว จำกัดว่าสามารถเรียกใช้ได้จากที่ใด ตั้งวันหมดอายุหรือหมุนเวียนคีย์ เก็บคีย์ให้ห่างจากโค้ดฝั่งไคลเอนต์และรีโป และเปิดใช้การสแกนหาความลับพร้อมการป้องกันการพุช หากคีย์รั่วไหล ให้สร้างคีย์ใหม่ นำไปใช้งาน แล้วปิดการใช้งานคีย์เก่าและตรวจสอบการใช้งาน
LLMjacking คืออะไร?
LLMjacking คือการนำข้อมูลรับรองของโมเดลภาษาขนาดใหญ่ที่ถูกขโมยมา โดยปกติจะเป็น API key ไปใช้ในทางที่ผิดเพื่อรันการประมวลผล (inference) ที่เจ้าของคีย์ต้องเป็นคนจ่ายเงิน ผู้โจมตีจะขายต่อการเข้าถึงนั้น นำไปใช้จนหมดกับงานของตัวเอง หรือในตอนนี้ ตามข้อมูลของ Bitsight ใช้มันเป็นพลังให้เอเจนต์โจมตีแบบอัตโนมัติ เหยื่อจะเห็นกิจกรรมนี้เพียงในรูปแบบของการใช้งานที่คิดค่าบริการในบัญชีของตัวเองเท่านั้น
สิ่งที่ Bitsight ค้นพบเกี่ยวกับ MONST3R-AI
ข้อเท็จจริงด้านล่างมาจากการรายงานข่าวเกี่ยวกับงานวิจัยของ Bitsight โดย Help Net Security และ AI Weekly ซึ่งเผยแพร่เมื่อวันที่ 17 ตุลาคม 2026 บทความของ Bitsight เองเกี่ยวกับเครื่องมือนี้ยังไม่เปิดเผยต่อสาธารณะในเวลาที่เขียนบทความนี้
- มันคืออะไร: ผู้ขายรายหนึ่งในฟอรัมอาชญากรรมแบบจำกัดการเข้าถึง โฆษณา MONST3R-AI ว่าเป็น "แพลตฟอร์มทดสอบเจาะระบบแบบอัตโนมัติ"
- คีย์ของใคร: มันทำงานบนคีย์ OpenAI, Anthropic และ Google API ที่ถูกขโมยมา
- ใครจ่าย: ผู้ซื้อวางคีย์ที่ขโมยมาลงในแผงควบคุมของเครื่องมือ ตั้งงบประมาณ และชี้เป้าเอเจนต์ไปที่รายการเป้าหมาย ผู้ขายไม่ได้โฮสต์โมเดลใด ๆ ดังนั้นบิลค่าประมวลผลจึงตกอยู่กับเจ้าของคีย์ที่ถูกต้องตามกฎหมาย
- ผลลัพธ์ที่อ้าง: แดชบอร์ดของผู้ขายอ้างว่าพบช่องโหว่ 1,072 รายการจากโฮสต์ที่สแกน 199 เครื่อง Bitsight กล่าวว่าไม่สามารถตรวจสอบตัวเลขนั้นได้อย่างอิสระ ดังนั้นให้ถือว่าเป็นโฆษณา ไม่ใช่หลักฐาน
- แนวโน้มที่กว้างขึ้น: จากฟอรัมใต้ดิน 16 แห่ง ระหว่างเดือนกุมภาพันธ์ถึงสิงหาคม 2026 การกล่าวถึงเอเจนต์ AI, การฉีดพรอมป์ทางอ้อม และ Model Context Protocol เพิ่มขึ้น 67 เปอร์เซ็นต์

คีย์ที่รั่วไหลไม่ใช่แค่ใบแจ้งหนี้ที่มาแบบไม่คาดคิดอีกต่อไป มันสามารถเป็นทุนให้แคมเปญโจมตีของคนอื่นได้ และทุกคำขอจะดูเหมือนทราฟฟิกปกติของคุณ
คีย์ AI API รั่วไหลได้อย่างไร
คีย์ที่ถูกขโมยส่วนใหญ่ไม่เคยถูก "แฮ็ก" เลย พวกมันถูกเปิดเผยโดยอุบัติเหตุ เส้นทางที่พบบ่อย:
| เส้นทางรั่วไหล | เกิดขึ้นได้อย่างไร | วิธีแก้ |
|---|---|---|
| รีโปสาธารณะ | คีย์ถูกคอมมิตในโค้ด .env หรือโน้ตบุ๊ก |
สแกนหาความลับพร้อมการป้องกันการพุช |
| โค้ดฝั่งไคลเอนต์ | คีย์ถูกส่งไปในเว็บบันเดิลหรือแอปมือถือ | เรียกโมเดลจากแบ็กเอนด์ของคุณเท่านั้น |
| ล็อก CI | ขั้นตอนบิลด์แสดงค่าตัวแปรสภาพแวดล้อมหรือเอาต์พุตดีบัก | ปิดบังความลับ อย่าใช้ set -x กับส่วนนั้นเด็ดขาด |
| อิมเมจคอนเทนเนอร์ | .env ถูกคัดลอกเข้าไปในเลเยอร์ของอิมเมจ |
ใช้ .dockerignore และฉีดค่าในขณะรันไทม์ |
| คอนฟิกของเอเจนต์และ MCP | คีย์ถูกวางในคอนฟิกของ MCP เซิร์ฟเวอร์หรือไฟล์ตั้งค่าเอเจนต์ แล้วถูกซิงก์หรือแชร์ | อ้างอิงตัวแปรสภาพแวดล้อม ไม่ใช่คีย์แบบเป็นตัวอักษร |
| แชทและตั๋วงาน | คีย์ถูกวางใน Slack, issue หรือตั๋วซัพพอร์ต | หมุนเวียนคีย์ใดก็ตามที่ออกจากที่เก็บความลับของคุณ |
คู่มือ Gemini API key ของ Google ระบุกฎฝั่งไคลเอนต์ไว้อย่างชัดเจนว่า คีย์ที่คอมไพล์เข้าไปในเว็บหรือแอปมือถือสามารถถูกผู้ใช้ดึงออกมาได้ ดังนั้นให้รันพร็อกซีฝั่งแบ็กเอนด์ที่ทำการเรียกจริง คู่มือของเราเกี่ยวกับการจัดเก็บ API key ครอบคลุมด้านการจัดเก็บไว้อย่างละเอียดยิ่งขึ้น
คอนฟิกของเอเจนต์ควรได้รับการดูแลเป็นพิเศษ: ไฟล์ตั้งค่าของ MCP และเอเจนต์มักไปจบอยู่ในรีโปดอตไฟล์ การแชร์หน้าจอ และรายงานบั๊ก
จะรู้ได้อย่างไรว่าคีย์ของคุณถูกใช้ในทางที่ผิด
ไม่มีคำเตือนใดบอกว่า "อาชญากรกำลังใช้คีย์นี้" ให้เฝ้าดูข้อมูลการใช้งานและบิลเพื่อหาสัญญาณเหล่านี้:
- ค่าใช้จ่ายพุ่งขึ้นโดยไม่มีการดีพลอยใด ๆ รองรับ ค่าใช้จ่ายรายวันที่เคยคงที่แล้วกลับเพิ่มเป็นสองเท่าในชั่วข้ามคืนคือสัญญาณที่ชัดเจนที่สุด
- โมเดลที่คุณไม่ได้ใช้ มีการใช้งานในตระกูลโมเดลที่ผลิตภัณฑ์ของคุณไม่เคยเรียกเลย
- ทราฟฟิกนอกเวลาทำงาน คำขอที่สม่ำเสมอตอนตี 3 ตามเขตเวลาของคุณจากคีย์ที่แอปใช้งานตอนกลางวัน
- ข้อผิดพลาด rate-limit ที่คุณไม่ได้ก่อ มีคนอื่นกำลังใช้โควตาต่อนาทีของคุณ
- คีย์หรือโปรเจกต์ที่ไม่รู้จักในหน้าดูการใช้งาน หน้า Usage ของ Google AI Studio จะจัดกลุ่มคำขอที่ไม่สามารถจับคู่กับคีย์ที่มีชื่อไว้ใน "(unknown keys)"
แยกคีย์ให้ละเอียดพอที่การพุ่งขึ้นครั้งหนึ่งจะชี้ไปที่คีย์เดียวได้
วิธีปกป้อง OpenAI API key ของคุณ
ตรวจสอบเมื่อวันที่ 28 ตุลาคม 2026 เทียบกับเอกสารนักพัฒนาของ OpenAI
- เพดานการใช้จ่ายแบบตายตัว: ตามคู่มือเพดานการใช้จ่าย คุณสามารถตั้งวงเงินรายเดือนสำหรับองค์กรหรือโปรเจกต์เดียว และเปิด "Enforce a hard limit" เมื่อการใช้จ่ายที่ติดตามถึงขีดนั้น คำขอจะล้มเหลวด้วย 429 และโค้ด
organization_spend_limit_exceededหรือproject_spend_limit_exceededการบังคับใช้ไม่ได้เกิดขึ้นทันที ดังนั้นการใช้จ่ายอาจเกินเพดานไปเล็กน้อย - การแจ้งเตือนการใช้จ่าย: การแจ้งเตือนจะบอกคุณแต่ไม่ได้หยุดทราฟฟิก ให้ใช้ทั้งสองอย่าง โดยตั้งการแจ้งเตือนไว้ต่ำกว่าเพดานแบบตายตัวมาก ๆ
- รายการ IP ที่อนุญาต: IP allowlist จะปฏิเสธคำขอจาก IP อื่นแม้จะมีคีย์ที่ถูกต้อง รองรับสูงสุด 50 แอดเดรสหรือช่วง CIDR ใช้ได้ทั้งระดับโปรเจกต์หรือทั้งองค์กร และคำขอที่ถูกบล็อกจะได้ HTTP 401 พร้อม
ip_not_authorizedการเปลี่ยนแปลงใช้เวลาถึง 15 นาที - หนึ่งโปรเจกต์ต่อหนึ่งแอปและสภาพแวดล้อม: เพดานและรายการที่อนุญาตระดับโปรเจกต์จะช่วยได้ก็ต่อเมื่อแยกคีย์ตามโปรเจกต์
- สิทธิ์ของคีย์แบบจำกัด: คู่มือโปรเจกต์ของ OpenAI ระบุสิทธิ์แบบ All (ค่าเริ่มต้น), Restricted และ Read Only สำหรับคีย์ที่ผู้ใช้เป็นเจ้าของ ให้แต่ละคีย์มีเฉพาะสิ่งที่แอปของมันต้องใช้
- การเข้าถึงโมเดลต่อโปรเจกต์: ภายใต้ Limits ของโปรเจกต์ ส่วน Model usage ใช้เลือกว่าโปรเจกต์จะเรียกโมเดลใดได้บ้าง คีย์ที่ถูกขโมยจึงไม่สามารถกระโดดไปใช้โมเดลที่แพงกว่าซึ่งคุณไม่เคยใช้ได้
ดูคู่มือ OpenAI API key ของเรา
วิธีปกป้อง Anthropic API key ของคุณ
ตรวจสอบเมื่อวันที่ 28 ตุลาคม 2026 เทียบกับเอกสาร Claude Platform
- เพดานการใช้จ่ายต่อเวิร์กสเปซ: ตามเอกสาร Workspaces คุณสามารถจำกัดการใช้จ่ายรายเดือนต่อเวิร์กสเปซและตั้งการแจ้งเตือนที่ระดับต่าง ๆ ได้ คุณไม่สามารถตั้งเพดานการใช้จ่ายบน Default Workspace ได้ ดังนั้นให้วางคีย์โปรดักชันไว้ในเวิร์กสเปซของตัวเอง
- ขีดจำกัดอัตราต่อเวิร์กสเปซ: จำกัดคำขอ, โทเคนอินพุต และโทเคนเอาต์พุตต่อนาทีสำหรับแต่ละเวิร์กสเปซ
- วันหมดอายุของคีย์: เอกสารการรับรองความถูกต้อง ให้คุณเลือกวันหมดอายุตอนสร้างได้: 3 ชั่วโมง, 1 วัน, 7 วัน, 30 วัน, ระยะเวลาที่กำหนดเอง หรือ Never และไม่สามารถเปลี่ยนแปลงภายหลังได้
- คีย์ที่ผูกกับตัวตน: คีย์ส่วนบุคคลและคีย์บัญชีบริการจะหยุดทำงานเมื่อเจ้าของถูกนำออก Anthropic เรียกคีย์เวิร์กสเปซว่าแบบเดิม (legacy) และแนะนำให้ใช้ Workload Identity Federation สำหรับโปรดักชันบนแพลตฟอร์มคลาวด์และ CI
- ปิดการใช้งานเทียบกับการลบ: Disable นั้นย้อนกลับได้และจะแสดงคีย์เป็น
inactiveส่วน Delete เป็นการถาวร เมื่อไม่แน่ใจให้ปิดการใช้งานก่อน
ดูคู่มือ Anthropic API key ของเรา
วิธีปกป้อง Google Gemini API key ของคุณ
ตรวจสอบเมื่อวันที่ 28 ตุลาคม 2026 เทียบกับเอกสาร Gemini API key และเอกสารการเรียกเก็บเงินของ Google
- คีย์สำหรับการรับรองความถูกต้อง (Auth keys): ตั้งแต่ 28 พฤษภาคม 2026 คีย์ใหม่ที่สร้างใน Google AI Studio จะเป็นคีย์สำหรับการรับรองความถูกต้องที่ผูกกับบัญชีบริการ ซึ่งถูกจำกัดให้ใช้กับ Gemini API โดยค่าเริ่มต้น Google กล่าวว่าคีย์เหล่านี้มาพร้อมการบังคับใช้ที่รวดเร็วต่อคีย์ที่รั่วไหลซึ่งระบบของ Google ตรวจพบ
- ไม่มีคีย์แบบไม่จำกัด: Gemini API จะปฏิเสธคำขอจากคีย์มาตรฐานที่ไม่จำกัดขอบเขต ให้จำกัดคีย์เก่าให้ใช้กับ Gemini API ใน AI Studio หรือย้ายไปใช้คีย์สำหรับการรับรองความถูกต้อง
- ข้อจำกัดระดับแอปพลิเคชัน: ในหน้า credentials ของคอนโซล Cloud ให้จำกัดคีย์ให้ใช้กับที่อยู่ IP ที่ระบุเท่านั้น
- เพดานการใช้จ่ายต่อโปรเจกต์: ตั้งเพดานรายเดือนต่อโปรเจกต์ได้ในหน้า Spend ของ AI Studio Google ติดป้ายว่าเป็นฟีเจอร์ทดลองและเตือนเรื่องค่าใช้จ่ายเกินในช่วงความล่าช้าในการเรียกเก็บเงินประมาณ 10 นาที

เช็กลิสต์ล็อกดาวน์สำหรับทุกผู้ให้บริการ
ทำตามนี้หนึ่งครั้งต่อคีย์หนึ่งคีย์ที่คุณเป็นเจ้าของ:
- ทำบัญชีรายการ ระบุทุกคีย์ แอปที่ใช้มัน และสถานที่จัดเก็บ
- แยก หนึ่งโปรเจกต์หรือเวิร์กสเปซต่อหนึ่งแอปและสภาพแวดล้อม เพื่อให้การพุ่งขึ้นครั้งหนึ่งบอกได้ว่ามาจากไหน
- จำกัดวงเงิน ตั้งเพดานรายเดือนแบบตายตัวและการแจ้งเตือนที่เร็วกว่า
- จำกัดขอบเขต ใช้ IP allowlist หรือข้อจำกัดระดับแอปพลิเคชันทุกที่ที่ทราฟฟิกขาออกของคุณคงที่
- ตั้งวันหมดอายุหรือหมุนเวียนคีย์ ใช้อายุสั้น ๆ ในที่ที่ผู้ให้บริการรองรับ และใช้ตารางการหมุนเวียนในที่ที่ไม่รองรับ
- สแกน แพตเทิร์นการสแกนหาความลับของ GitHub ครอบคลุมคีย์ OpenAI, Anthropic และ Google Gemini API และคีย์ OpenAI รองรับการป้องกันการพุช บทความของเราเกี่ยวกับการตรวจสอบ API key ที่รั่วไหล ครอบคลุมตัวสแกนที่คุณรันเองในเครื่องได้
- เลือกใช้ข้อมูลรับรองอายุสั้น ทั้ง Anthropic และ OpenAI ต่างมีเอกสารเรื่อง workload identity federation สำหรับโปรดักชัน
สำหรับด้านนโยบาย ดูแนวปฏิบัติที่ดีที่สุดในการจัดการ API key
สิ่งที่ต้องทำในชั่วโมงแรกหลังคีย์รั่วไหล
ความเร็วสำคัญกว่ารากของปัญหา เรียงตามลำดับ:

- สร้างคีย์ทดแทน ในโปรเจกต์หรือเวิร์กสเปซใหม่
- ดีพลอยคีย์นั้น ไปยังแอปที่ต้องใช้
- ปิดการใช้งานคีย์ที่รั่วไหล เช็กลิสต์การรั่วไหลของ Google ระบุให้ปิดการใช้งานคีย์เก่าหลังจากตรวจสอบคีย์ใหม่แล้วเท่านั้น เพื่อหลีกเลี่ยงการหยุดให้บริการ หากค่าใช้จ่ายพุ่งขึ้นอย่างรวดเร็ว ให้ปิดการใช้งานก่อนและยอมรับการหยุดให้บริการ
- ลดเพดานการใช้จ่าย ของโปรเจกต์ที่ได้รับผลกระทบระหว่างการสอบสวน
- ตรวจสอบการใช้งาน ตามโมเดล ชั่วโมง และคีย์ สำหรับช่วงเวลาตั้งแต่เกิดการรั่วไหล
- ค้นหาเส้นทางที่รั่วไหล โดยใช้ตารางด้านบน และลบมันออกจากประวัติ git
- ติดต่อผู้ให้บริการ เกี่ยวกับการใช้งานที่ฉ้อโกงเมื่อคุณมีไทม์ไลน์แล้ว
ให้เอเจนต์เขียนโค้ดของคุณทดสอบการจัดการคีย์ด้วย Apidog CLI
พร็อกซีฝั่งแบ็กเอนด์ของคุณที่เชื่อมไปยัง OpenAI, Anthropic หรือ Gemini คือจุดที่การจัดการคีย์มักพัง: มันรับคำขอที่ไม่มีการรับรองความถูกต้อง หรือสะท้อนคีย์ของผู้ให้บริการออกมาในบอดี้ของข้อผิดพลาด ให้เอเจนต์เขียนโค้ดของคุณเขียนและรันการทดสอบสำหรับส่วนนี้ด้วย Apidog CLI โดยเก็บความลับไว้ห่างจากนิยามของการทดสอบ
ตั้งค่าครั้งเดียว:
npm install -g apidog-cli@latest
apidog login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com # pick your agent when prompted
จากนั้นให้พรอมป์หนึ่งข้อกับเอเจนต์ของคุณ:
In Apidog project <id>, create a test case for POST /v1/ai/chat on our proxy.
Assert: no Authorization header returns 401, a bad token returns 401, a valid
token returns 200, and no response body contains "sk-" or "AIza". Read the
token from the {{PROXY_TOKEN}} environment variable, never hardcode it.
Then run it against the staging environment and summarize failures.
เอเจนต์จะอ่านสคีมาของเพย์โหลด ตรวจสอบความถูกต้อง สร้างเคสและรันมัน:
apidog cli-schema get test-case-create
apidog test-case category --project <id>
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <id> --file case.json
apidog run --test-case <caseId> --project <id> -e <envId> \
--env-var "PROXY_TOKEN=$PROXY_TOKEN" -r cli,junit
--env-var ส่งโทเคนในขณะรัน ดังนั้นมันจึงไม่เคยอยู่ในสเปกหรือในรีโป บรรทัด apidog run แบบเดียวกันนี้ใส่เข้าไปใน CI ได้เลย ดู Apidog CLI ในไปป์ไลน์ CI/CD และ Apidog CLI ใน Claude Code
คำถามที่พบบ่อย
LLMjacking คืออะไร? คือการใช้ข้อมูลรับรอง LLM ที่ถูกขโมยมา โดยปกติเป็น API key เพื่อรันการประมวลผลที่เจ้าของต้องเป็นคนจ่ายเงิน ผู้โจมตีจะขายต่อการเข้าถึงนั้น หรืออย่างกรณี MONST3R-AI ก็ใช้มันเป็นพลังให้เอเจนต์โจมตี
คีย์ AI API ที่ถูกขโมยสามารถจ่ายเงินให้เครื่องมือแฮ็กได้จริงหรือ? ใช่ Bitsight รายงานว่าผู้ซื้อ MONST3R-AI วางคีย์ OpenAI, Anthropic หรือ Google ที่ขโมยมาลงในแผงควบคุมของมัน และผู้ขายไม่ได้โฮสต์โมเดลใด ๆ เหยื่อจึงเป็นคนจ่าย ผลลัพธ์ที่ผู้ขายอ้างนั้นยังไม่ได้รับการตรวจสอบ
เพดานการใช้จ่ายหยุดคีย์ที่ถูกขโมยได้ไหม? เพดานแบบตายตัวจะหยุดการใช้จ่ายที่ขีดนั้น แต่ไม่ใช่ทันที ทั้ง OpenAI และ Google ต่างระบุว่าจะมีค่าใช้จ่ายเกินเล็กน้อยระหว่างที่เพดานมีผล ส่วนการแจ้งเตือนการใช้จ่ายเพียงอย่างเดียวไม่เคยหยุดทราฟฟิกได้
ฉันวาง OpenAI API key ไว้ในโค้ดฝั่งฟรอนต์เอนด์ได้ไหม? ไม่ได้ อะไรก็ตามที่ถูกส่งไปยังเบราว์เซอร์หรือแอปมือถือสามารถถูกดึงออกมาได้ ให้เรียกโมเดลจากแบ็กเอนด์ของคุณ
GitHub จะจับคีย์ AI ที่รั่วไหลได้ไหม? การสแกนหาความลับของ GitHub ตรวจจับแพตเทิร์นคีย์ OpenAI, Anthropic และ Google Gemini API ได้ ให้เปิดการป้องกันการพุชเพื่อให้คอมมิตที่มีคีย์ถูกบล็อกก่อนที่จะเป็นสาธารณะ
