ซ่อน API key จาก AI agent: environment variable ยังไม่ใช่ห้องนิรภัย

ถ้าต้องให้ AI agent เรียก API โดยไม่เปิดเผย API key ให้ออกแบบให้โมเดลเลือกเพียง connector ID กับรายละเอียดงาน แล้วส่งคำขอนั้นไปยังส่วนดำเนินการที่เชื่อถือได้ ส่วนนี้ตรวจสิทธิ์และปลายทางก่อนอ่านคีย์จาก secret store เติมข้อมูลยืนยันตัวตน และส่งคำขอจริง โมเดลควรเห็นผลที่จำเป็นต่อการตอบงานเท่านั้น โดยไม่เห็นคีย์หรือคำขอฉบับที่เติมคีย์แล้ว

Environment variable ช่วยกันคีย์ออกจากซอร์สโค้ด แต่ไม่ได้กันกระบวนการที่รันเครื่องมือของเอเจนต์จากการอ่านค่าในสภาพแวดล้อมเดียวกัน คำแนะนำเรื่อง API key ของ OpenAI เสนอให้ใช้ตัวแปรแวดล้อมแทนการฝังคีย์ในโค้ด และให้หลีกเลี่ยงคีย์ใน browser แอปมือถือ หรือ repository; สำหรับงาน production ยังแนะนำให้พิจารณาระบบจัดการความลับ สิทธิ์เฉพาะงาน วันหมดอายุ และการหมุนคีย์ด้วย

ขีดเส้นระหว่างสิ่งที่โมเดลสั่งได้กับสิ่งที่อ่านคีย์ได้

คำถามแรกไม่ใช่ว่าเก็บคีย์ไว้ที่ไฟล์ไหน แต่คือกระบวนการใดอ่านคีย์ได้จริง หากรันเอเจนต์และ connector ในกระบวนการเดียวกัน แล้วส่งคีย์ผ่าน environment variable เครื่องมือที่เอเจนต์เรียกเพื่อรันคำสั่งหรือโค้ดอาจอ่านค่าเดียวกันได้ การย้ายคีย์จากไฟล์ไปอยู่ในตัวแปรจึงแก้ปัญหาการฝังความลับใน repository แต่ยังไม่สร้างขอบเขตใหม่ในขณะรัน

ความเสี่ยงอีกด้านเกิดเมื่อคีย์ถูกใส่ในข้อความที่โมเดลเห็น เช่น prompt คำอธิบายเครื่องมือ ตัวอย่างคำขอ ไฟล์ที่เอเจนต์อ่าน หรือผลลัพธ์จาก API เมื่อข้อมูลนั้นเข้าบริบทโมเดล มันอาจถูกคัดลอกไปยังประวัติสนทนา memory trace โค้ดที่สร้างขึ้น หรือข้อความผิดพลาด การลบคีย์ออกจากข้อความต้นทางภายหลังไม่ได้ลบสำเนาที่ระบบเหล่านี้เก็บไว้แล้ว จึงควรหยุดคีย์ตั้งแต่ก่อนเข้าสู่ทางเดินข้อมูลของโมเดล

ต้องแยกสิทธิ์ของเครื่องมือออกจากความสามารถของโมเดลในการอ่านข้อความด้วย แม้จะไม่ได้แสดงค่าคีย์ใน prompt เอเจนต์ที่สั่ง shell ได้ก็อาจสั่งคำสั่งให้พิมพ์ตัวแปรแวดล้อม เปิดไฟล์ตั้งค่า หรือเรียกโปรแกรมที่สะท้อน header กลับมา หากผลของเครื่องมือกลับเข้าบทสนทนา คีย์ก็อาจข้ามไปสู่ log และ memory โดยไม่เคยถูกพิมพ์ใน prompt เริ่มต้น

สำหรับเอเจนต์ที่ต้องรันโค้ดทั่วไป ควรให้ runtime ของเอเจนต์มีเฉพาะข้อมูลที่ไม่เป็นความลับและสิทธิ์เครือข่ายเท่าที่จำเป็น ส่วนที่ถือข้อมูลรับรองควรเป็นกระบวนการหรือบริการอีกขอบเขตหนึ่ง ซึ่งเอเจนต์เรียกได้ผ่านสัญญาการทำงานที่จำกัด แต่ไม่สามารถอ่านหน่วยความจำ ตัวแปรแวดล้อม ไฟล์ลับ หรือคำขอภายในของส่วนนั้นได้ การแยกสิทธิ์ของกระบวนการและการแยกปลายทางที่ติดต่อได้ต้องทำพร้อมกัน

ในระบบที่ต่อเครื่องมือหลายชนิด ขอบเขตต้องครอบคลุมทั้งตัว agent runner, เครื่องมือที่รันโค้ด, เซิร์ฟเวอร์ MCP และบริการบันทึกผล หากเซิร์ฟเวอร์ MCP ถือคีย์ไว้เองและส่งผลลัพธ์ดิบกลับมา การซ่อนคีย์จาก prompt ยังอาจไม่พอ ต้องกำหนดว่าใครเป็นผู้รับผิดชอบการยืนยันตัวตน ใครอ่าน secret store ได้ และใครเห็นคำขอหลังเติมคีย์ ไม่ควรปล่อยให้คำอธิบายเครื่องมือที่โมเดลอ่านได้เป็นที่เก็บข้อมูลรับรอง

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

ถ้าระบบเดิมส่งคีย์ให้ agent runner ผ่าน environment variable การย้ายไปใช้ secret store ต้องเปลี่ยนทางส่งคีย์ด้วย ไม่ใช่แค่เปลี่ยนจุดเก็บ เริ่มโดยย้ายการเรียก API ไปยัง connector ที่แยกกระบวนการ ถอนตัวแปรจาก runtime ของเอเจนต์ และตรวจว่าเครื่องมือเดิมไม่มีทางเรียก API โดยใช้ข้อมูลรับรองชุดเก่าโดยตรง การเปลี่ยนนี้จะชัดเจนที่สุดเมื่อคำขอเดิมยังทำงานผ่าน connector ได้ แต่การอ่านตัวแปรและไฟล์จากฝั่งเอเจนต์ไม่พบคีย์แล้ว

ให้โมเดลเลือก connector แล้วตรวจคำขอก่อนเติมคีย์

โครงสร้างอ้างอิงคือ model → connector ID → trusted boundary → secret store โมเดลได้รับรายการ connector ที่อนุญาตพร้อมความสามารถที่อธิบายงานได้ แต่ไม่มี secret value หรือข้อมูลที่ใช้สร้างคีย์กลับมาได้ คำตอบของโมเดลเป็นเพียงคำขอให้ใช้ความสามารถหนึ่งรายการ ไม่ใช่สิทธิ์อนุมัติการเรียก API ด้วยตัวเอง

งานวิจัยของ Corvic AI Research อธิบายรูปแบบที่โมเดลเลือก connector ID แล้วชั้นที่เชื่อถือได้เติมข้อมูลยืนยันตัวตน และรายงานว่าการทดสอบ Corvic Security Vault ภายในระบบของผู้วิจัย 16 กรณีได้ผลตามเกณฑ์ที่ตั้งไว้ทั้งหมด รวมถึงคำขอ GitHub ที่ยืนยันตัวตนสำเร็จโดยกระบวนการของเอเจนต์ไม่เห็นคีย์ ผลนี้เป็นการทดสอบแบบจำกัดกับการตั้งค่าที่ตรวจ ไม่ใช่การรับรองทุก connector หรือการใช้งานทุกแบบ

เริ่มที่ทะเบียน connector ซึ่งระบุเจ้าของการเชื่อมต่อ ผู้ให้บริการ host ที่อนุญาต วิธี HTTP เส้นทาง API ขอบเขตข้อมูล และชนิดการยืนยันตัวตน ให้ระบุวิธีเติมคีย์ตามสัญญาของผู้ให้บริการนั้นโดยเฉพาะ เช่น header หรือพารามิเตอร์ที่ผู้ให้บริการกำหนด หากส่งคีย์ผิดตำแหน่ง คำขออาจถูกปฏิเสธแม้คีย์ไม่รั่ว ตัวอย่างที่ connector ส่งคีย์ผ่าน header ไปยังปลายทางที่คาดหวัง query parameter แสดงให้เห็นว่าการเก็บคีย์ถูกที่ยังไม่ทำให้การเชื่อมต่อทำงานได้

สัญญาระหว่างโมเดลกับ connector ควรสั้นพอให้ตรวจได้แน่นอน: ชื่อการกระทำ ตัวระบุทรัพยากร และพารามิเตอร์ที่มีรูปแบบตายตัว ตัวอย่างสมมติ หากเอเจนต์มีหน้าที่อ่านสถานะคำสั่งซื้อ ก็ส่งเพียง connector ID, รหัสคำสั่งซื้อ และการกระทำแบบอ่าน; host เส้นทางสำหรับลบข้อมูล และตำแหน่งวางคีย์ต้องมาจากการตั้งค่าที่ผู้ดูแลอนุมัติ ไม่ใช่ข้อความที่โมเดลสร้างขึ้น

กฎตรวจสอบต้องดูค่าที่จะถูกส่งจริง ไม่ใช่ตรวจแค่ชื่อเครื่องมือ หากพารามิเตอร์หนึ่งกลายเป็น URL หรือ path ของคำขอ ควรตรวจหลังแปลงรูปแบบและก่อนส่งออก เพื่อกันการเปลี่ยน host ผ่านการเข้ารหัสอักขระหรือเส้นทางอ้อม ตรวจด้วยว่าการกระทำเดียวกันใช้ได้เฉพาะ tenant หรือบัญชีที่ผู้ใช้มีสิทธิ์ และกำหนดขอบเขตของจำนวนรายการที่เรียกได้ในหนึ่งงาน

1. รับ connector ID และพารามิเตอร์งานจากเอเจนต์ โดยไม่รับ API key หรือ URL ปลายทางใหม่เป็นค่าที่โมเดลตั้งเอง ผูก ID กับระเบียน connector ที่ผู้ดูแลกำหนดไว้ก่อน เพื่อไม่ให้คำสั่งในเอกสารหรือผลลัพธ์เครื่องมือเปลี่ยนปลายทางของคีย์
2. ตรวจตัวตนผู้ใช้ที่เริ่มงานและสิทธิ์ของเอเจนต์ต่อ connector นั้น ตรวจการกระทำที่ร้องขอด้วยกฎที่แน่นอน เช่น host วิธี HTTP path ชนิดข้อมูล และขนาดงาน หากไม่ผ่านให้ปฏิเสธก่อนแตะ secret store
3. ให้ส่วนที่เชื่อถือได้อ่านคีย์จาก secret store ด้วยสิทธิ์เฉพาะ connector แล้วเติมค่าลงในคำขอที่กำลังจะออกไปยัง host ที่กำหนด การดึงคีย์และการเติมต้องอยู่หลังขอบเขตที่เอเจนต์ตรวจหน่วยความจำหรือคำขอฉบับสมบูรณ์ไม่ได้
4. ส่งคำขอผ่านทางออกเครือข่ายที่จำกัดปลายทาง ตรวจการเปลี่ยนเส้นทางก่อนตามต่อ และไม่ส่ง header ยืนยันตัวตนไปยัง host ใหม่เพียงเพราะปลายทางเดิมตอบกลับให้ย้ายที่อยู่
5. คืนเฉพาะข้อมูลที่งานต้องใช้ ตัด header ยืนยันตัวตน cookie URL ที่มี token และรายละเอียดข้อผิดพลาดที่อาจมีความลับ ก่อนส่งผลกลับให้โมเดลหรือผู้ใช้ บันทึก connector ID การตัดสินสิทธิ์ และรหัสติดตามคำขอ โดยไม่บันทึกค่าคีย์

ตำแหน่งที่เติมข้อมูลรับรองสำคัญพอ ๆ กับตำแหน่งที่เก็บคีย์ หากเครื่องมือของเอเจนต์เห็นคำขอก่อนเติมคีย์ก็ยังใช้ทดสอบฟังก์ชันได้ แต่ไม่ควรเห็นคำขอที่พร้อมส่งจริงหลังเติมคีย์แล้ว สำหรับผู้ให้บริการที่บังคับใส่ token ใน URL ต้องระวังเป็นพิเศษ เพราะ URL มักถูกเก็บใน log ของ proxy และระบบติดตามคำขอ ควรเลือกวิธียืนยันตัวตนที่ผู้ให้บริการรองรับและจัดการการกรอง log ให้ตรงกับตำแหน่งนั้น

หากปลายทางตอบกลับด้วยการเปลี่ยนเส้นทาง ส่วนที่ส่งคำขอต้องตรวจ origin ใหม่ก่อนติดตามต่อ และตัดข้อมูลยืนยันตัวตนเมื่อไม่ตรงกับ host ที่กำหนด เช่นเดียวกัน การให้โมเดลส่ง URL เต็มแทนตัวระบุทรัพยากรเปิดทางให้คำขอที่ถูกต้องตามรูปแบบไปยังปลายทางอื่นได้ การผูกคีย์กับ connector จึงต้องผูกกับปลายทางจริงของคำขอ ไม่ใช่ผูกกับชื่อที่แสดงให้โมเดลเลือกเท่านั้น

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

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

ส่งผลกลับโดยไม่พาความลับย้อนเข้าสู่บทสนทนา

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

แนวทางนี้ทำให้การแก้ปัญหาไม่ต้องพึ่งการเปิดเผยคีย์ หากการเรียกถูกปฏิเสธ โมเดลควรได้รับรหัสสถานะ ประเภทปัญหา และข้อมูลอ้างอิงคำขอที่ไม่เป็นความลับ ผู้ดูแลจึงนำรหัสอ้างอิงไปดู log ภายในได้ โดย log ภายในก็ต้องกรอง header cookie query parameter และ body ที่อาจมีข้อมูลรับรองก่อนจัดเก็บ

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

ลดอำนาจของคีย์และเตรียมเปลี่ยนคีย์โดยไม่หยุดงาน

การซ่อนคีย์ไม่ได้ลดสิทธิ์ที่คีย์มีต่อ API ปลายทาง คีย์ที่อ่านและลบข้อมูลได้ก็ยังทำเช่นนั้นได้เมื่อเอเจนต์เรียก connector สำเร็จ จึงควรออกข้อมูลรับรองแยกตามงาน สภาพแวดล้อม และระดับการกระทำ งานอ่านข้อมูลไม่ควรใช้ข้อมูลรับรองเดียวกับงานเขียนหรือลบข้อมูล และงานทดสอบไม่ควรใช้คีย์ production

แนวทาง AWS Secrets Manager แนะนำให้จำกัดสิทธิ์อ่านความลับตามความจำเป็น หมุนข้อมูลรับรอง และติดตามเหตุการณ์ผ่านระบบตรวจสอบ หลักนี้นำมาใช้กับ connector ได้โดยให้เฉพาะส่วนที่ส่งคำขอจริงอ่านความลับของ connector นั้น และให้ระบบตรวจสอบเก็บว่าใครเรียก connector ใด เมื่อใด และผลการตัดสินสิทธิ์เป็นอย่างไร

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

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

กำหนดเจ้าของคีย์ วันหมดอายุ ช่องทางเพิกถอน และรอบการเปลี่ยนไว้ในทะเบียน connector ก่อนใช้งานจริง เมื่อเปลี่ยนคีย์ ให้เพิ่มข้อมูลรับรองใหม่ ทดสอบคำขอที่ควรผ่านด้วยค่าทดสอบที่ปลอดภัย เปลี่ยน connector ให้ใช้คีย์ใหม่ แล้วเพิกถอนคีย์เดิมหลังยืนยันว่าการทำงานต่อเนื่อง การแก้ค่าคีย์ใน vault เพียงอย่างเดียวไม่พอ หาก connector ยังแคชค่าเก่าหรือมีสำเนาอยู่ในงานที่รันค้าง

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

หากผู้ให้บริการรองรับข้อมูลรับรองอายุสั้นหรือ workload identity federation ให้ประเมินใช้ตามชนิดงานที่รองรับ วิธีนี้ลดเวลาที่คีย์ถาวรใช้ซ้ำได้ แต่ยังต้องตรวจสิทธิ์การกระทำที่ปลายทางและป้องกัน token อายุสั้นไม่ให้เข้าสู่บริบทโมเดล การเลือกวิธีออกข้อมูลรับรองควรดูว่าผู้ให้บริการรองรับขอบเขตสิทธิ์ การเพิกถอน และการตรวจสอบย้อนหลังได้ละเอียดเพียงใด

พิสูจน์ทั้งคำขอที่ควรผ่านและทางที่คีย์ต้องไปไม่ถึง

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

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

หากมีการทดสอบ prompt injection ให้ใส่ข้อความสั่งเปลี่ยนปลายทางในข้อมูลที่เอเจนต์อ่าน ไม่ใช่ในคำสั่งของผู้ใช้ที่ได้รับอนุญาต แล้วตรวจว่าชั้นดำเนินการยังปฏิเสธ host หรือการกระทำที่ไม่อยู่ในนโยบาย การทดสอบนี้ตรวจการบังคับใช้กฎของ connector ไม่ได้ใช้คำตอบว่าโมเดลตั้งใจจะเก็บคีย์เป็นหลักฐานด้านความปลอดภัย

• Environment และไฟล์: ให้เครื่องมือที่เอเจนต์เรียกตรวจชื่อตัวแปรแวดล้อม ค่าในขอบเขตที่ตนอ่านได้ ตำแหน่งไฟล์ตั้งค่า และจุด mount ความลับที่ใช้งานจริง ผลที่ต้องการคือไม่พบค่าคีย์ใน runtime ของเอเจนต์ หากตรวจพบชื่อที่ชวนสงสัย ให้ตรวจข้างหลังขอบเขตโดยผู้ดูแล แทนการสั่งให้โมเดลพิมพ์ค่าออกมา
• คำขอก่อนออกเครือข่าย: ตรวจคำขอที่เครื่องมือของเอเจนต์ประกอบก่อนผ่าน trusted boundary ว่าไม่มี Authorization header หรือพารามิเตอร์คีย์ จากนั้นตรวจที่ฝั่ง connector ว่าข้อมูลยืนยันตัวตนถูกเติมเฉพาะเมื่อผ่านกฎ และคำขอที่ไม่ได้รับอนุญาตไม่ทำให้มีการอ่าน secret store
• Log, trace, memory และข้อผิดพลาด: ทำให้ API ทดสอบตอบข้อผิดพลาดที่ควบคุมได้ แล้วตรวจเส้นทางตั้งแต่เครื่องมือจนถึงประวัติสนทนาและระบบติดตามงาน ผลที่ส่งให้โมเดลควรมีสถานะและเหตุผลพอแก้ปัญหาได้ แต่ไม่มี header cookie query string ที่มี token หรือข้อความจากผู้ให้บริการที่สะท้อนคีย์
• Echo service และการเปลี่ยนเส้นทาง: ส่งคำขอทดสอบไปยังบริการสะท้อนคำขอที่ควบคุมได้ และตรวจว่าปลายทางอื่นไม่เห็นข้อมูลรับรองของ connector ทดสอบทั้งการเรียก host ผิดโดยตรงและการตอบกลับให้ย้ายไป host ใหม่ เพราะการผูกคีย์กับ origin ต้องยังทำงานเมื่อคำขอมีหลายทอด
• Metadata endpoint: ตรวจว่า runtime ของเอเจนต์เข้าไม่ถึงจุดให้ข้อมูลประจำตัวของระบบคลาวด์ที่ใช้จริง หากยังเข้าถึงได้ เอเจนต์อาจได้ข้อมูลรับรองจากช่องทางอื่นแม้คีย์ของ connector ถูกแยกแล้ว ต้องควบคุมทั้งสิทธิ์ของ workload และทางออกเครือข่าย
• คำขอที่ได้รับอนุญาต: เรียก endpoint ที่ปลอดภัยของผู้ให้บริการผ่าน connector แล้วตรวจว่าผลสำเร็จตรงกับสิทธิ์ที่ตั้งไว้ ทดสอบคู่กับคำขออ่านหรือเขียนนอกขอบเขต เพื่อแยกปัญหาการแมปข้อมูลรับรองผิดจากปัญหานโยบายกว้างเกินไป

สำหรับระบบที่ใช้ตัวกลางเครือข่ายหรือ proxy ควรตรวจทั้งคำขอที่เครื่องมือสร้างและคำขอที่ออกจากระบบจริง เพราะข้อมูลรับรองถูกเติมระหว่างสองจุดนั้น หากดูเฉพาะฝั่งเอเจนต์อาจพลาดการรั่วจาก proxy, redirect หรือระบบบันทึกเครือข่าย หากดูเฉพาะฝั่งปลายทางก็อาจไม่รู้ว่าคีย์เคยปรากฏใน trace ระหว่างทางหรือไม่

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

อย่าแปลผลการไม่พบคีย์จากการค้นหารูปแบบเดียวว่าไม่มีรอยรั่ว คีย์แต่ละผู้ให้บริการมีหน้าตาต่างกัน และระบบบันทึกบางชั้นอาจเข้าถึงไม่ได้จาก sandbox ทดสอบ ควรตรวจการตั้งค่าการกรองของ log ฝั่ง connector เอง รวมถึงเส้นทาง retry งานเบื้องหลัง และการส่งต่อผลระหว่างเอเจนต์ หากมีหลายตัวร่วมงาน

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

เกณฑ์ปล่อยใช้งานจึงควรระบุผลที่ตรวจได้จริง: การเรียกที่ได้รับอนุญาตสำเร็จโดยไม่เปิดเผยคีย์ การเรียกข้ามปลายทางไม่พาข้อมูลรับรองติดไป และการเรียกนอกสิทธิ์ถูกปฏิเสธก่อนอ่านความลับ ถ้าข้อใดไม่ผ่าน ให้แก้ขอบเขตหรือกฎ connector แล้วทดสอบซ้ำเฉพาะเส้นทางที่เกี่ยวข้อง พร้อมดูว่าการเปลี่ยนแปลงทำให้กรณีที่เคยผ่านเสียไปหรือไม่

เมื่อการทดสอบพบคีย์ในจุดที่เอเจนต์หรือผู้ใช้เห็นได้ ให้หยุดใช้ connector ที่เกี่ยวข้อง เพิกถอนหรือหมุนข้อมูลรับรอง แล้วตรวจสำเนาใน log trace memory โค้ดที่สร้างขึ้น และผลลัพธ์ที่เคยส่งออกไป การแก้เพียงรูปแบบการเก็บคีย์จะไม่ปิดทางรั่ว หาก runtime ของเอเจนต์ยังอ่านข้อมูลจากกระบวนการที่ถือคีย์ หรือส่งคำขอที่เติมคีย์แล้วไปยังปลายทางที่โมเดลเลือกเองได้

อ่านเพิ่มเติม:

• Docker หรือ DigitalOcean: sandbox สำหรับ AI agent คิดเงินคนละจังหวะ
• Postman หรือ Insomnia: ทีมใหญ่แลก RAM กับระบบกำกับ API
• กัน API key หลุดบน GitHub: Push Protection ข้ามไฟล์เกิน 50 MB