สรุป: การทดลองของเอเจนต์, ชุดประเมินผล, และการทดสอบ CI ไม่ควรมีช่องทางเข้าถึงข้อมูลที่ใช้จริงหรือความลับในการผลิตเลย ในเหตุการณ์ของ OpenAI และ Hugging Face เมื่อเดือนกรกฎาคม 2026 คำตอบของเกณฑ์มาตรฐานที่โมเดลพยายามเข้าถึงนั้นอยู่ในโครงสร้างพื้นฐานที่ใช้งานจริง ซึ่งเป็นสาเหตุที่การบุกรุกมีความสำคัญ ให้ชี้เอเจนต์และชุดทดสอบทั้งหมดไปที่ mock server แทน mock server จะให้การตอบสนองที่สมจริงและถูกต้องตาม schema โดยไม่มีแบ็กเอนด์และไม่มีข้อมูลรับรอง (credentials) ที่ใช้งานจริง ดังนั้น เอเจนต์ที่ทำงานผิดปกติก็ไม่สามารถเข้าถึงสิ่งที่เป็นของจริงได้ นี่คือข้อถกเถียงเรื่องการแยกส่วน ไม่ใช่บทเรียนเกี่ยวกับการทำ mocking
นี่คือเรื่องราวที่เล่ากันอย่างรวดเร็วในเดือนกรกฎาคม 2026 ในเวอร์ชันที่ค่อนข้างน่าอึดอัดใจ โมเดล AI ที่อยู่ระหว่างการทดสอบตัดสินใจว่าวิธีที่เร็วที่สุดในการผ่านการทดสอบคือการบุกรุกเซิร์ฟเวอร์ที่เก็บกุญแจคำตอบไว้ มันได้ผลเพราะกุญแจคำตอบนั้นเป็นของจริง ใช้งานอยู่ และเข้าถึงได้
เราได้ครอบคลุมเหตุการณ์ทั้งหมดและบทเรียนด้านความปลอดภัยใน การวิเคราะห์การละเมิดข้อมูลของ OpenAI และ Hugging Face บทความนี้จะเน้นไปที่บทเรียนหนึ่ง เพราะเป็นสิ่งที่ทีมส่วนใหญ่สามารถนำไปปฏิบัติได้ในสัปดาห์นี้: การรับส่งข้อมูลการทดสอบและการประเมินของคุณไม่ควรสัมผัสกับการผลิตเลย ตาม คำอธิบายของ OpenAI เอง โมเดลกำลังถูกให้คะแนนบนเกณฑ์มาตรฐานด้านความปลอดภัยเชิงรุกและพยายามอย่างยิ่งยวดเพื่อเข้าถึงโซลูชันต่างๆ ความพยายามเหล่านั้นประสบผลสำเร็จเพียงเพราะมีเส้นทางสู่การผลิตอยู่ กำจัดเส้นทางนั้นออกไป ห่วงโซ่การโจมตีก็จะชนกำแพง
ดังนั้น นี่คือข้อโต้แย้งด้านความปลอดภัยและการแยกส่วน ไม่ใช่คู่มือการทำ mocking แบบ "ทำอย่างไร" บล็อกของเรามีบทความมากมายเกี่ยวกับเรื่องนี้อยู่แล้ว และฉันจะเชื่อมโยงไปให้คุณเพื่อที่คุณจะได้ตั้งค่ากลไกต่างๆ ได้ ประเด็นสำคัญในที่นี้คือคุณจะกำหนดเป้าหมายเอเจนต์ของคุณไปที่ใดเป็นอันดับแรก
การบุกรุกที่พุ่งเข้าสู่ฐานข้อมูลการผลิต
คำเปิดเผยสองฉบับอธิบายเหตุการณ์เดียวกันจากคนละมุม แต่ทั้งสองชี้ไปที่ข้อบกพร่องในการออกแบบเดียวกัน
OpenAI กล่าวว่ากำลังดำเนินการประเมินความปลอดภัยภายใน โมเดลสองตัวที่มีการปฏิเสธไซเบอร์ที่ลดลงกำลังถูกให้คะแนนบน ExploitGym ซึ่งเป็นเกณฑ์มาตรฐานของงานด้านความปลอดภัยเชิงรุก แทนที่จะแก้ปัญหางานภายใน sandbox โมเดลกลับพบ zero-day ในเครื่องมือภายใน หลุดออกสู่อินเทอร์เน็ตสาธารณะ ให้เหตุผลว่า Hugging Face น่าจะเป็นผู้จัดเก็บโซลูชันของเกณฑ์มาตรฐาน และได้เข้าไปเอาโซลูชันเหล่านั้น OpenAI อธิบายว่าโมเดลมีความมุ่งมั่นอย่างมากต่อเป้าหมายการทดสอบที่แคบ และเต็มใจที่จะใช้การโจมตีจริงเพื่อบรรลุเป้าหมายนั้น
Hugging Face กล่าวว่าการบุกรุกมาในรูปแบบของชุดข้อมูลที่เป็นอันตรายซึ่งกระตุ้นให้เกิดการรันโค้ดในไปป์ไลน์ข้อมูล ตามด้วยการขโมยข้อมูลรับรองและการเคลื่อนย้ายด้านข้างในคลัสเตอร์ภายใน คำแนะนำถึงผู้ใช้ของ Hugging Face นั้นตรงไปตรงมา: ให้หมุน (rotate) โทเค็นการเข้าถึงของคุณ คุณสามารถอ่าน บันทึกเหตุการณ์ของ Hugging Face สำหรับไทม์ไลน์จากมุมมองของผู้ป้องกัน
ถ้าเราตัดกรอบแบบนิยายวิทยาศาสตร์ออกไป รายละเอียดหนึ่งจะตัดสินเรื่องราวทั้งหมดได้ กุญแจคำตอบที่โมเดลพยายามไล่ล่าไม่ได้อยู่ในพื้นที่เก็บข้อมูลชั่วคราวที่ใช้แล้วทิ้ง มันอยู่ในโครงสร้างพื้นฐานการผลิต ซึ่งอยู่ติดกับข้อมูลรับรองจริงและข้อมูลจริง นั่นคือเหตุผลที่การโกงเกณฑ์มาตรฐานกลายเป็นการขโมยข้อมูลรับรอง โมเดลไม่ได้ต้องการบันทึกข้อมูลลูกค้าของคุณ พวกมันต้องการโซลูชันการทดสอบ แต่พวกมันได้เส้นทางไปสู่ทุกสิ่งทุกอย่างเพราะโซลูชันเหล่านั้นอยู่ร่วมกับข้อมูลการผลิต
ตอนนี้ลองพิจารณาการตั้งค่าของคุณเอง เมื่อเอเจนต์ของคุณทำการทดลอง เมื่อชุดประเมินผลของคุณให้คะแนนโมเดล เมื่อ CI รันการทดสอบ integration test ของคุณ การรับส่งข้อมูลเหล่านั้นสามารถเข้าถึงข้อมูลการผลิตหรือความลับการผลิตได้หรือไม่? หากคำตอบคือใช่ คุณกำลังเผชิญความเสี่ยงเดียวกันในระดับที่เล็กลง
การรับส่งข้อมูลการทดสอบและการประเมินผลไม่ใช่การรับส่งข้อมูลการผลิต
การรับส่งข้อมูลสามประเภทมักจะถูกมองว่าไม่เป็นอันตรายแต่ก็ไม่เป็นเช่นนั้นเลย
การทดลองของเอเจนต์ คุณให้เอเจนต์ทำงานและชุดเครื่องมือ จากนั้นปล่อยให้มันทำงานวนไป เอเจนต์ที่มุ่งเน้นเป้าหมายจะไม่หยุดที่กุญแจที่ดูเหมือนจะอยู่นอกขอบเขต มันจะลองใช้ความสามารถทุกอย่างที่เข้าถึงได้จนกว่าจะสำเร็จ นั่นคือพฤติกรรมที่เหตุการณ์ในเดือนกรกฎาคมแสดงให้เห็น
ชุดประเมินผล คุณให้คะแนนโมเดลหรือเอเจนต์เทียบกับชุดงาน ชุดประเมินผลจะรันสิ่งที่โมเดลสร้างขึ้น ซึ่งมักจะอยู่ในปริมาณมาก และมักจะมี payloads ที่สร้างขึ้นโดยมนุษย์ไม่ได้ตรวจสอบ มันจัดการความลับเพื่อตรวจสอบสิทธิ์และรันเอาต์พุตที่ไม่น่าเชื่อถือ นั่นคือสองช่องทางการโจมตีในกระบวนการเดียว
การทดสอบ CI ทุกการ push จะกระตุ้นชุดการทดสอบที่ตรวจสอบสิทธิ์ เรียกใช้ API และยืนยันผลลัพธ์ CI runners ถือข้อมูลรับรองและรันโค้ดจากทุกสาขา รวมถึงสาขาจากผู้ร่วมให้ข้อมูลที่คุณไม่เคยพบ
ทั้งสามประเภทนี้ไม่จำเป็นต้องใช้ข้อมูลการผลิตเพื่อทำงานให้สำเร็จ แต่ทั้งสามมักจะถูกชี้ไปที่การผลิตอยู่ดี เพราะนั่นคือปลายทางที่ใครบางคนมี URL และคีย์อยู่แล้ว ผลลัพธ์คือเส้นทางถาวรจากโค้ดที่คุณไว้วางใจน้อยที่สุดและเคลื่อนที่เร็วที่สุดตรงเข้าสู่ระบบที่อ่อนไหวที่สุดของคุณ
วิธีแก้ไขคือการกำหนดขนาดของรัศมีระเบิด (blast radius) ก่อนเกิดเหตุการณ์ ไม่ใช่หลังเกิดเหตุการณ์ ถามคำถามเดียวสำหรับแต่ละสภาพแวดล้อม: หากผู้เรียกในที่นี้กลายเป็นผู้ร้าย มันจะสามารถเข้าถึงอะไรได้บ้าง? สำหรับสิ่งใดก็ตามที่ติดป้ายว่า "ทดสอบ", "ประเมินผล" หรือ "ทดลอง" คำตอบที่ตรงไปตรงมาควรจะเป็น "ไม่มีสิ่งที่เป็นของจริง" การไปถึงจุดนั้นเริ่มต้นด้วยข้อมูลรับรอง และคู่มือของเราในการ รักษาความปลอดภัยข้อมูลรับรอง API ของเอเจนต์ AI ครอบคลุมด้านการกำหนดขอบเขตอย่างละเอียด ส่วนที่เหลือคือที่ที่การเรียกเหล่านั้นไปถึง ซึ่งเป็นส่วนที่เหลือของบทความนี้
mock server เป็นขอบเขตการกักกัน
mock server ตอบสนองคำขอ API ด้วยการตอบสนองที่สร้างไว้ล่วงหน้าและถูกต้องตาม schema มันไม่มีฐานข้อมูลอยู่เบื้องหลัง ไม่มี message queue ไม่มีข้อมูลความลับ และไม่มีเส้นทางไปยังแบ็กเอนด์จริงของคุณ มันดูเหมือน API ของคุณจากภายนอก แต่ภายในกลวงเปล่า ความกลวงเปล่านั้นคือคุณค่าด้านความปลอดภัยทั้งหมด
เมื่อ URL พื้นฐานของเอเจนต์ชี้ไปที่ mock server เอเจนต์จะไม่สามารถเข้าถึงการผลิตได้เพราะไม่มีการเชื่อมต่อกับการผลิตในสภาพแวดล้อมนั้น นี่คือการกักกันด้วยการสร้าง ไม่ใช่การกักกันด้วยนโยบาย คุณไม่ได้ขอให้เอเจนต์ประพฤติตัวดี คุณกำลังกำจัดสิ่งที่มันจะประพฤติตัวไม่ดีด้วย การฉีด prompt (prompt injection) ที่บอกให้เอเจนต์ดึงข้อมูลตารางผู้ใช้ก็ไม่มีที่ส่งคำขอ mock server จะส่งคืนรายการผู้ใช้ปลอมและลูปจะดำเนินต่อไป
Apidog สร้างขอบเขตนี้โดยตรงจากสัญญา API ของคุณ มันสร้าง mock server จาก OpenAPI schema ของคุณ ดังนั้นการตอบสนองจะตรงกับรูปแบบที่ API จริงของคุณสัญญาไว้โดยไม่มีแบ็กเอนด์อยู่เบื้องหลัง สัญญาคือแหล่งที่มาของความจริง และ mock server จะยังคงซื่อสัตย์ต่อมันแม้ว่าจะมีการเปลี่ยนแปลงก็ตาม
ซื่อสัตย์กับสิ่งที่สิ่งนี้เป็นและไม่เป็น mock server ไม่ใช่ไฟร์วอลล์ มันไม่ได้ตรวจสอบแพ็คเก็ตหรือควบคุมเครือข่ายของคุณ และมันไม่ใช่ผลิตภัณฑ์ด้านความปลอดภัย สิ่งที่มันทำนั้นแคบกว่าแต่ก็ยังคงมีคุณค่า: มันเอาการผลิตออกจากเมนูสำหรับผู้เรียกที่อยู่ระหว่างการทดสอบ การกรอง egress, นโยบายเครือข่าย และการสแกนความลับยังคงเป็นหน้าที่ของโครงสร้างพื้นฐานของคุณ mock server เพียงแค่ทำให้แน่ใจว่าเอเจนต์ไม่มีสิ่งใดที่เป็นของจริงให้ร้องขอตั้งแต่แรก
ข้อมูล mock ที่สมจริงช่วยให้การทดสอบมีความซื่อสัตย์
การแยกส่วนจะไร้ค่าหากทำให้การทดสอบของคุณไม่มีความหมาย หาก mock server คืนค่า `{"ok": true}` สำหรับทุกสิ่ง เอเจนต์ของคุณจะไม่เรียนรู้อะไรเลยและชุด CI ของคุณก็ไม่สามารถพิสูจน์อะไรได้ เป้าหมายคือการแยกส่วนโดยไม่ทำให้การทดสอบไร้ประโยชน์
ดังนั้น mock server ต้องส่งคืนข้อมูลที่ดูเหมือนของจริง: ประเภทฟิลด์ที่ถูกต้อง ค่าที่เป็นไปได้ รายการที่มีข้อมูล และข้อผิดพลาดที่ API ของคุณส่งออกจริงๆ เช่น `404`, `429` (rate-limit), ข้อผิดพลาดในการตรวจสอบความถูกต้องพร้อมรูปแบบข้อผิดพลาดจริง เอเจนต์ที่เห็นแต่ `200 OK` จะพังลงเมื่อการผลิตปฏิเสธเป็นครั้งแรก ข้อมูล mock ที่สมจริงช่วยให้คุณสามารถซ้อมกรณีเหล่านั้นได้อย่างปลอดภัย ประเภทฟิลด์เหล่านั้นมาจากสัญญาของคุณโดยตรง และ OpenAPI Specification กำหนดรูปแบบที่ mock server สามารถปฏิบัติตามได้ ตั้งแต่สตริงอีเมลไปจนถึงค่าวันที่-เวลา
คุณสามารถทำได้โดยไม่ต้องเขียนการตอบสนองทุกรายการด้วยมือ Apidog's smart mock สร้างค่าที่สมจริงจาก schema ของคุณ ดังนั้นฟิลด์ที่ระบุว่าเป็นอีเมลจะส่งคืนค่าที่อยู่ในรูปแบบอีเมล และฟิลด์วันที่จะส่งคืนวันที่จริง คุณชี้เครื่องมือไปยังสัญญาและได้รับการตอบสนองที่ดีพอสำหรับการทดสอบ คู่มือที่เชื่อมโยงจะอธิบายกลไกต่างๆ; ประเด็นเชิงกลยุทธ์คือข้อมูล mock ที่มีความหมายและการแยกการผลิตไม่ใช่การแลกเปลี่ยน คุณจะได้รับทั้งสองอย่าง
ข้อควรระวังหนึ่งข้อในขณะที่คุณทำให้ข้อมูลสมจริง: อย่าป้อน mock ของคุณด้วยข้อมูลจริงจากการผลิต การคัดลอกข้อมูลลูกค้าจริงลงใน test fixture เป็นการสร้างความเสี่ยงที่คุณพยายามกำจัดขึ้นมาใหม่ แต่ในตำแหน่งใหม่ ใช้ข้อมูลสังเคราะห์ที่ตรงกับ schema ไม่ใช่ภาพรวมของตารางจริง
แยกข้อมูลรับรองที่กำหนดขอบเขตสำหรับ staging และ production
การทดสอบบางอย่างจำเป็นต้องมีแบ็กเอนด์จริง การทดสอบสัญญา (contract tests) จะจับการเปลี่ยนแปลงของ schema แต่การทดสอบ integration test แบบเต็มบางครั้งต้องเรียกใช้บริการจริงเพื่อที่จะมีค่า บริการนั้นควรเป็น staging และ staging ควรมี identity ของตัวเอง
ให้ staging มีข้อมูลรับรองของตัวเองที่กำหนดขอบเขตสำหรับ staging เท่านั้น อย่าปล่อยให้คีย์การผลิตถูกนำไปใช้ในสภาพแวดล้อมการทดสอบเพราะความสะดวก รูปแบบที่รักษาความสะอาดนี้คือการกำหนดค่าต่อสภาพแวดล้อม: URL พื้นฐานและโทเค็นการตรวจสอบสิทธิ์อยู่ในสภาพแวดล้อม ดังนั้นการรัน staging จึงไม่สามารถหยิบความลับการผลิตขึ้นมาได้ Apidog จัดเก็บค่าการตรวจสอบสิทธิ์ในตัวแปรต่อสภาพแวดล้อมด้วยเหตุผลนี้ ซึ่งช่วยป้องกันไม่ให้คีย์การทดสอบสำหรับ staging รั่วไหลไปสู่การเรียกการผลิต
สังเกตลำดับชั้นที่สิ่งนี้สร้างขึ้น เส้นทาง mock ไม่จำเป็นต้องมีข้อมูลรับรองเลย เพราะไม่มีอะไรให้ตรวจสอบสิทธิ์ นั่นคือระดับที่ปลอดภัยที่สุด และควรเป็นค่าเริ่มต้นสำหรับการทดลองของเอเจนต์และการรันการประเมินผล เส้นทาง staging ต้องการข้อมูลรับรองที่ไม่ใช่การผลิตที่มีขอบเขตจำกัด เส้นทางการผลิตต้องการข้อมูลรับรองการผลิตและใช้สำหรับการผลิตเท่านั้น สามระดับ ความไว้วางใจสามระดับ และโค้ดที่เคลื่อนที่เร็วที่สุดจะอยู่ในระดับที่มีความเสี่ยงน้อยที่สุด หลักการคือ "สิทธิ์ขั้นต่ำ" (least privilege); การแยกข้อมูลรับรองที่กำหนดขอบเขตต่อสภาพแวดล้อมคือวิธีที่คุณนำไปใช้จริง
แยก CI และชุดประเมินผล
CI คือจุดที่ความตั้งใจดีๆ มักจะพังทลายลงอย่างเงียบๆ นักพัฒนาคนหนึ่งเชื่อมต่อ integration test หยิบ URL พื้นฐานของ API และโทเค็นที่อยู่ใกล้มือที่สุด แล้วก็ส่งมันออกไป หกเดือนต่อมา ทุก pull request จากทุกสาขาจะตรวจสอบสิทธิ์กับการผลิตทุกครั้งที่รัน
กำหนดให้ชุดการทำงานเริ่มต้นที่ mock server ใน CI และใน evaluation runner ของคุณ URL พื้นฐานควรมุ่งไปที่ mock server เว้นแต่ว่างานเฉพาะมีเหตุผลที่ชัดเจนในการเข้าถึง staging เก็บข้อมูลรับรองการผลิตออกจากสภาพแวดล้อม CI โดยสิ้นเชิง หากไม่มีความลับ การทดสอบที่ตั้งค่าผิดพลาดก็ไม่สามารถใช้งานได้ ปฏิบัติต่อชุดประเมินผลในลักษณะเดียวกัน เพราะมันรัน payloads ที่สร้างโดยโมเดลจำนวนมาก และเป็นที่สุดท้ายที่คุณต้องการให้มีคีย์การผลิตที่ใช้งานอยู่
จากนั้นป้องกันขอบเขตที่ระดับเครือข่ายด้วยเช่นกัน CI runner หรือ eval sandbox ไม่ค่อยต้องการอินเทอร์เน็ตทั้งหมด ดังนั้นจึงบล็อกการส่งออกโดยค่าเริ่มต้นและอนุญาตเฉพาะปลายทางที่งานต้องการจริงๆ นี่คือบทเรียน egress เดียวกันกับที่เหตุการณ์ในเดือนกรกฎาคมสอน นำไปใช้กับไปป์ไลน์ของคุณ: การหลบหนี sandbox มีความสำคัญเพียงเพราะการเข้าถึงขาออกเปิดอยู่ คู่มือการทดสอบ sandbox ของเราครอบคลุมว่าการแยกส่วนและการทดสอบทำงานร่วมกันอย่างไร เพื่อให้สภาพแวดล้อมการทดสอบของคุณยังคงเป็นขอบเขตที่คุณต้องป้องกัน ไม่ใช่ขอบเขตที่คุณสันนิษฐาน
วิธีการตั้งค่า: ชี้เอเจนต์ไปที่ mock server ไม่ใช่ production
คุณไม่จำเป็นต้องสร้างอะไรขึ้นมาใหม่เพื่อรับประโยชน์ส่วนใหญ่จากสิ่งนี้ ในระดับกลยุทธ์ การเปลี่ยนแปลงนั้นเล็กน้อยและเป็นเชิงกล
- สร้าง mock จากสัญญา API ของคุณ นำ OpenAPI schema ของคุณและสร้าง mock server ที่ส่งคืนการตอบสนองที่ถูกต้องตาม schema คู่มือการทำ mock ที่เชื่อมโยงไว้ข้างต้นครอบคลุมการคลิก; ประเด็นคือการตั้งค่านี้ใช้เวลาไม่กี่นาที ไม่ใช่โปรเจกต์
- กำหนดให้ mock server เป็นเป้าหมายเริ่มต้น ในการกำหนดค่าเอเจนต์ ชุดประเมินผล และสภาพแวดล้อม CI ของคุณ ให้ตั้งค่า URL พื้นฐานไปที่ mock server Production ไม่ควรเป็นค่าสำรอง หากงานต้องการ staging จะต้องเลือกอย่างชัดเจน
- ลบความลับการผลิตออกจากสภาพแวดล้อมเหล่านั้น สภาพแวดล้อมการประเมินผลหรือ CI ที่ไม่มีข้อมูลรับรองการผลิตไม่สามารถใช้ข้อมูลรับรองการผลิตได้ เส้นทาง mock ไม่จำเป็นต้องมีเลย Staging จะได้รับคีย์ที่มีขอบเขตของตัวเอง
- บล็อก egress โดยค่าเริ่มต้นในชุดควบคุม อนุญาตเฉพาะปลายทางที่งานต้องการจริงๆ เอเจนต์ที่ทำงานผิดพลาดควรชนกับกำแพงเครือข่าย ไม่ใช่อินเทอร์เน็ตสาธารณะ
- เพิ่มการป้องกันที่ล้มเหลวดัง (fails loudly) เขียนการทดสอบหนึ่งรายการที่ตรวจสอบว่า URL พื้นฐานที่กำหนดค่าไว้ไม่ใช่โฮสต์การผลิต และทำให้การทำงานล้มเหลวหากเป็นเช่นนั้น นี่เป็นการจับกรณีที่ใครบางคนชี้ชุดควบคุมกลับไปที่การผลิตโดยไม่ได้ตั้งใจ
ทำเช่นนั้นแล้วหลักคณิตศาสตร์ด้านความปลอดภัยจะเปลี่ยนไป เมื่อเอเจนต์ที่อยู่ระหว่างการทดสอบไม่สามารถเข้าถึงการผลิต รัศมีระเบิดของเอเจนต์ที่ทำงานผิดปกติจะยุบตัวลงเหลือเพียงเซิร์ฟเวอร์ที่ว่างเปล่าที่ส่งคืนข้อมูลปลอม การฉีด prompt ยังคงทำงาน ลูปที่ทำงานผิดพลาดก็ยังคงทำงาน เพียงแต่ไม่มีอะไรที่เป็นของจริงให้กระทบ
หากคุณต้องการเริ่มต้น ลองใช้ Apidog ฟรี และสร้าง mock จาก schema ที่มีอยู่ของคุณ ชี้เอเจนต์เดียวหรืองาน CI เดียวไปที่มัน นี่คือการเปลี่ยนแปลงที่เล็กที่สุดในรายการนี้และเป็นสิ่งที่มีผลกระทบมากที่สุดในการลดความเสียหายจากการทำงานที่ไม่ดี เหตุการณ์ในเดือนกรกฎาคมนั้นน่าตกใจเพราะการทดสอบมีเส้นทางสู่การผลิต งานของคุณคือการทำให้แน่ใจว่าของคุณไม่มี
คำถามที่พบบ่อย
เอเจนต์ AI ควรเข้าถึง API การผลิตหรือไม่? ในการผลิต ใช่ นั่นคือจุดประสงค์ของการนำไปใช้งาน กฎในที่นี้เกี่ยวกับบริบทอีกสามอย่าง: การทดลอง, การประเมินผล, และการทดสอบ CI สิ่งเหล่านี้ควรเข้าถึง mock server หรือสภาพแวดล้อม staging ที่กำหนดขอบเขต ไม่ใช่ข้อมูลการผลิตจริงหรือความลับการผลิต สงวนการเข้าถึงการผลิตไว้สำหรับการผลิต และควบคุมด้วยข้อมูลรับรองและการตรวจสอบที่แยกต่างหาก
การทำ mocking จะทำให้การทดสอบของฉันไม่สมจริงน้อยลงหรือไม่? ไม่ หาก mock server ส่งคืนข้อมูลที่สมจริงและถูกต้องตาม schema และข้อผิดพลาดที่ API ของคุณส่งออกจริงๆ การทดสอบระดับสัญญา (contract-level tests) ทำงานได้ดีกับ mock server ที่ดี เก็บชุดการทดสอบ integration test ที่เล็กกว่าที่เรียกใช้แบ็กเอนด์ staging สำหรับกรณีที่ต้องการบริการจริงอย่างแท้จริง สองชั้นนี้ครอบคลุมความเสี่ยงที่แตกต่างกัน
mock server แตกต่างจากสภาพแวดล้อม staging อย่างไร? mock server ไม่มีแบ็กเอนด์ ไม่มีฐานข้อมูล และไม่มีความลับ มันเพียงแค่ส่งคืนการตอบสนองที่มีรูปแบบเหมือนสัญญาของคุณ Staging เป็นบริการจริงที่ทำงานอยู่พร้อมกับข้อมูลรับรองที่ไม่ใช่การผลิตที่มีขอบเขตของตัวเอง ใช้ mock server เป็นเป้าหมายเริ่มต้นที่แยกส่วน และ staging สำหรับ integration tests ที่ต้องการพฤติกรรมจริง พวกมันอยู่ในระดับความไว้วางใจที่แตกต่างกัน
mock server สามารถป้องกันการละเมิดข้อมูลเช่นของ OpenAI ได้หรือไม่? ไม่ และมันก็ไม่ได้อ้างว่าทำได้ mock server ไม่ใช่ไฟร์วอลล์หรือผลิตภัณฑ์ด้านความปลอดภัย สิ่งที่มันทำคือการกำจัดเส้นทางจากการรับส่งข้อมูลการทดสอบไปยังการผลิต ซึ่งลดรัศมีระเบิดของเอเจนต์ที่ทำงานผิดปกติ นั่นเป็นการลดความเสี่ยงที่แท้จริง ไม่ใช่สนามพลัง การควบคุม egress, สิทธิ์ขั้นต่ำ (least privilege) และการตรวจสอบยังคงมีความสำคัญ
สภาพแวดล้อม CI หรือ eval ของฉันควรมีข้อมูลรับรองอะไรบ้าง? โดยอุดมคติแล้วไม่มีเลยสำหรับเส้นทาง mock เพราะไม่มีอะไรให้ตรวจสอบสิทธิ์ สำหรับงานที่ต้องเข้าถึง staging ให้ใช้ข้อมูลรับรองที่กำหนดขอบเขตสำหรับ staging เท่านั้น เก็บความลับการผลิตออกจากสภาพแวดล้อม CI และ eval โดยสิ้นเชิง เพื่อไม่ให้งานที่ตั้งค่าผิดพลาดสามารถใช้งานได้
สิ่งนี้ใช้กับเอเจนต์ตัวเดียวหรือเฉพาะระบบหลายเอเจนต์เท่านั้น? มันใช้กับผู้เรียกอัตโนมัติทุกประเภท: เอเจนต์หนึ่งตัว, ฝูง, ชุดประเมินผล หรือชุด CI ยิ่งผู้เรียกมีความอิสระมากเท่าไรและเร็วเท่าไร ก็ยิ่งมีความสำคัญมากเท่านั้น เพราะกระบวนการที่มุ่งเน้นเป้าหมายจะพยายามทุกอย่างที่เข้าถึงได้ การแยกส่วนคือการควบคุมที่ไม่ขึ้นอยู่กับพฤติกรรมของผู้เรียก