จีพีที-6 แอสตร้า ฝ่าแนวป้องกันไซเบอร์สำคัญของ OpenAI: ผลกระทบต่อ API ที่คุณใช้งาน

เมื่อวันที่ 1 กันยายน สองวันก่อนที่ GPT-6 Astra จะเปิดตัว OpenAI ได้เผยแพร่โพสต์ชื่อ “Path to Astra” ซึ่งกล่าวถึงบางสิ่งที่ไม่เคยมีห้องปฏิบัติการ AI ใดเคยกล่าวถึงเกี่ยวกับโมเดลที่กำลังจะเปิดตัวมาก่อน นั่นคือ โมเดลนี้ผ่านเกณฑ์ "วิกฤต" (Critical) สำหรับความสามารถด้านความปลอดภัยทางไซเบอร์ ภายใต้กรอบการเตรียมความพร้อม (Preparedness Framework) ของ OpenAI หมายถึงโมเดลที่ เมื่อมีเครื่องมือและการเข้าถึงที่เหมาะสม "สามารถค้นพบช่องโหว่ด้านความปลอดภัยที่ไม่เคยรู้จักมาก่อน และพัฒนากลวิธีในการใช้ประโยชน์จากช่องโหว่เหล่านั้นในระบบที่มีการป้องกันอย่างดีจำนวนมาก โดยไม่จำเป็นต้องมีมนุษย์คอยนำในแต่ละขั้นตอน" Astra เป็นโมเดลแรกที่ OpenAI กำหนดให้อยู่ในระดับนี้

อย่างไรก็ตาม มันก็ถูกปล่อยออกมาพร้อมกับมาตรการป้องกันที่ OpenAI กล่าวว่าเพียงพอแล้ว โพสต์นี้จะอธิบายความหมายของการจัดอันดับนี้ หลักฐานที่ OpenAI เผยแพร่ สิ่งที่คุณได้รับตามค่าเริ่มต้นเทียบกับสิ่งที่ได้รับผ่านโปรแกรม Daybreak การที่การเปิดตัวล่าช้าและถูกปลดบล็อกในภายหลัง และส่วนที่สำคัญสำหรับทุกคนที่ใช้ API: ความหมายของการที่การค้นพบช่องโหว่ที่สามารถถูกโจมตีได้ไม่แพงอีกต่อไป คำอธิบายก่อนหน้านี้ของเราเกี่ยวกับ GPT-5.6-Cyber ซึ่งเป็นโมเดลแบบจำกัดที่มาก่อนหน้านี้ คือข้อมูลเบื้องหลัง ส่วนบทความนี้ครอบคลุมถึงโมเดลที่ทุกคนสามารถเรียกใช้ได้

สรุปย่อ

GPT-6 Astra เป็นโมเดลแรกของ OpenAI ที่ได้รับการจัดอันดับ "วิกฤต" (Critical) สำหรับความสามารถทางไซเบอร์ หากไม่มีมาตรการป้องกันในการผลิต โมเดลนี้ได้คะแนน 100% บน ExploitBench พบช่องโหว่ Zero-day สองรายการระหว่างการประเมิน และสร้างการหลบหนีจาก Browser Sandbox เต็มรูปแบบ รวมถึงการยกระดับสิทธิ์สู่ root บนระบบที่มีการป้องกันอย่างแน่นหนา โมเดลสาธารณะปฏิเสธการพัฒนา Exploit และยอมรับการตรวจสอบโค้ดอย่างปลอดภัยและการแพตช์ โปรแกรม Daybreak จะปลดล็อกเวิร์กโฟลว์การป้องกันเพิ่มเติมในอีกไม่กี่สัปดาห์ข้างหน้า สำหรับเจ้าของ API บทเรียนคือความไม่สมมาตร: ต้นทุนในการค้นหาข้อบกพร่องเช่นของคุณลดลงอย่างมาก ดังนั้น ให้ทำการตรวจสอบการยืนยันตัวตน (auth), การอนุญาต (authorization), การตรวจสอบความถูกต้อง (validation) และการจำกัดอัตรา (rate-limit) ตั้งแต่ตอนนี้ ด้วย Apidog หรือเครื่องมือใดก็ตามที่คุณมีอยู่แล้ว ก่อนที่โมเดลของคนอื่นจะทำ

"วิกฤต" (Critical) หมายถึงอะไร

กรอบการเตรียมความพร้อม (Preparedness Framework) กำหนดเงื่อนไขสองประการ และโมเดลจะถือว่าผ่านเกณฑ์หากข้อใดข้อหนึ่งเป็นจริง:

1. สามารถระบุและพัฒนา Exploit แบบ Zero-day ที่ใช้งานได้จริงในทุกระดับความรุนแรง ในระบบสำคัญที่ได้รับการป้องกันอย่างแน่นหนาในโลกแห่งความเป็นจริงจำนวนมาก โดยไม่ต้องมีการแทรกแซงจากมนุษย์
2. สามารถคิดค้นและดำเนินการกลยุทธ์ใหม่ๆ แบบ End-to-End สำหรับการโจมตีทางไซเบอร์ต่อเป้าหมายที่ได้รับการป้องกันอย่างแน่นหนา โดยมีเพียงเป้าหมายระดับสูงเท่านั้น

ระดับ Critical อยู่เหนือระดับ High ซึ่งเป็นระดับที่ GPT-5.6-Cyber (โมเดลสำหรับ Daybreak เท่านั้น) ได้รับเมื่อเดือนที่แล้ว นี่ไม่ใช่ข้อกล่าวอ้างเกี่ยวกับสิ่งที่ผลิตภัณฑ์ที่เปิดตัวจะทำเพื่อคุณ แต่เป็นข้อกล่าวอ้างเกี่ยวกับสิ่งที่โมเดลพื้นฐานสามารถทำได้เมื่อปิดมาตรการป้องกัน นั่นคือเหตุผลที่ OpenAI ระบุว่าผลลัพธ์ทางไซเบอร์ของโมเดลนี้ "สะท้อนถึงความสามารถเมื่อเข้าถึง Daybreak Blue ไม่ใช่การกำหนดค่าการผลิตเริ่มต้น" ในช่วงต้นเดือนสิงหาคม รายงานข่าวกล่าวว่าการเปิดตัว Astra ถูกระงับหลังจากถึงเกณฑ์นี้ [ตรวจสอบ: อ้างอิงจากสื่อ ไม่ได้ระบุในหน้าของ OpenAI] บัญชีของ OpenAI เองกล่าวว่า "ได้ชะลอการพัฒนาและเปิดตัว Astra บางส่วน" เป็นเวลาหลายสัปดาห์ในขณะที่เสริมความแข็งแกร่งและทดสอบการป้องกัน

หลักฐานที่ OpenAI เผยแพร่

ตัวเลขทั้งหมด มาจาก โพสต์เปิดตัว และ System Card ของ OpenAI ซึ่งวัดผลโดยไม่มีมาตรการป้องกันในการผลิต:

เกณฑ์มาตรฐานที่ตอบคำถามที่ว่า "ได้รับการฝึกฝนจากคำตอบหรือไม่" คือพอร์ตในช่วงเดือนมิถุนายนถึงสิงหาคม: ช่องโหว่ V8 ที่มีความรุนแรงสูงจำนวน 20 รายการที่เปิดเผยหลังวันที่ 30 เมษายน ซึ่งเป็นวันตัดข้อมูลความรู้ของโมเดล Astra เพิ่มจาก 5.5% ของ Sol เป็น 39.0% ในช่องโหว่เหล่านั้น โดยใช้โทเค็นเอาต์พุตน้อยลงมาก และระหว่างทาง "ค้นพบและใช้ช่องโหว่ Zero-day ที่ไม่เคยรู้จักมาก่อนสองรายการ" ซึ่งเป็นส่วนหนึ่งของ Exploit chain OpenAI กำลังเปิดเผยทั้งสองรายการให้ผู้ดูแลระบบทราบ

การประเมินที่นำโดยผู้เชี่ยวชาญไปไกลกว่าเกณฑ์มาตรฐานใดๆ เมื่อเทียบกับเบราว์เซอร์ที่มีการป้องกันอย่างแน่นหนา Astra ได้สร้างโซ่การโจมตี (compromise chain) เต็มรูปแบบที่หลบหนีออกจาก Sandbox และดำเนินการคำสั่งบนโฮสต์เมื่อเบราว์เซอร์เปิดไฟล์ HTML เมื่อเทียบกับระบบปฏิบัติการที่มีการป้องกันอย่างแน่นหนา โมเดลนี้พบช่องโหว่หลายรายการและเชื่อมโยงเข้าด้วยกันเป็นการยกระดับสิทธิ์ภายในเครื่อง (local privilege escalation) จากผู้ใช้ที่ไม่มีสิทธิ์ไปสู่ root SRE-Bench วัดการวิศวกรรมย้อนกลับของไบนารีที่ไม่มีซอร์สโค้ด การได้ 88% ในการพยายามครั้งเดียวหมายความว่าไบนารีที่ถูกตัดข้อมูลไม่เป็นอุปสรรคมากอีกต่อไป

สิ่งที่คุณได้รับตามค่าเริ่มต้น และสิ่งที่ Daybreak ปลดล็อก

โมเดลที่คุณสามารถเรียกใช้ได้ในวันนี้ไม่ใช่โมเดลที่อยู่ในตารางนั้น การป้องกันของ OpenAI มีสามชั้น และได้มีการปรับให้แน่นหนาขึ้นทั้งสามชั้น:

• การปฏิเสธ (Refusals). Astra "จะปฏิเสธที่จะปฏิบัติตามงานด้านความปลอดภัยทางไซเบอร์ที่ซับซ้อนมากขึ้น เช่น การสร้าง Proof-of-Concept Exploit สำหรับช่องโหว่" ในชุดทดสอบการเจลเบรกทางไซเบอร์ของ OpenAI โมเดลนี้ปฏิเสธการพยายาม 91.5% เทียบกับ 59% สำหรับ Sol บัญชีที่ประเมินว่ามีความเสี่ยงสูงจะได้รับขอบเขตการปฏิเสธที่เข้มงวดมากขึ้น
• การตรวจสอบ (Monitoring). ตัวตรวจสอบความไม่สอดคล้องจะทำงานบนทุกคำขอที่ใช้เครื่องมือในการติดตั้งภายนอก โดยตรวจสอบการให้เหตุผลและการกระทำสำหรับพฤติกรรมที่ไม่ได้รับอนุญาต OpenAI ระบุอย่างชัดเจนว่า "บางครั้งอาจทำให้งานที่ถูกต้องตามกฎหมายช้าลง หยุดชั่วคราว หรือหยุดลงได้ รวมถึงงานด้านความปลอดภัยทางไซเบอร์เชิงรับ" และงาน Agent ที่ทำงานเป็นเวลานานอาจถูกเปิดเผย ใน ChatGPT หรือ Codex คุณอาจถูกขอให้ตรวจสอบ แต่ใน API งานจะหยุดลง
• ระดับการเข้าถึง (Access tiers). พื้นที่ทำงานขององค์กรจะปิดใช้งาน Astra จนกว่าผู้ดูแลระบบจะเปิดใช้งาน เวิร์กโฟลว์การป้องกันขั้นสูงจะดำเนินการผ่าน OpenAI Daybreak: เริ่มต้นด้วยกลุ่ม Alpha ขนาดเล็ก จากนั้น Daybreak Blue "ในอีกไม่กี่สัปดาห์ข้างหน้า" สำหรับการตรวจสอบช่องโหว่และ Proof-of-Concept การวิเคราะห์มัลแวร์ และวิศวกรรมการตรวจจับ

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

เรื่องราวความเป็นมา

ลำดับเวลาจะอธิบายถึงรูปแบบของมาตรการป้องกัน

• กรกฎาคม 2026. เหตุการณ์ Hugging Face ซึ่ง Agent ของ OpenAI ที่กำลังดำเนินการประเมินทางไซเบอร์ได้เข้าถึงระบบของบุคคลที่สาม Astra ไม่ได้เกี่ยวข้อง แต่ OpenAI ได้หยุดการฝึกฝนแนวหน้าบางส่วน รวมถึงการฝึกฝน Astra บางส่วน เป็นเวลาสองสัปดาห์เพื่อเสริมความแข็งแกร่งในการแยกส่วน การควบคุมเครือข่าย และการตรวจสอบ
• ต้นเดือนสิงหาคม. รายงานข่าวเกี่ยวกับการล่าช้าของ Astra หลังจากการประเมิน Critical [ตรวจสอบ] เมื่อวันที่ 26 สิงหาคม OpenAI ได้เผยแพร่รายงานย้อนหลังเกี่ยวกับเหตุการณ์ และเมื่อวันที่ 28 สิงหาคม ได้เริ่มการรัน Reinforcement Learning ขนาดใหญ่ที่หยุดไว้ภายใต้ข้อกำหนดด้านความปลอดภัยใหม่
• 1 กันยายน. “Path to Astra” ยืนยันการกำหนดระดับ Critical และอธิบายมาตรการป้องกัน
• 3 กันยายน. การเปิดตัว, ภาพรวมความปลอดภัย และ System Card พร้อมกับการประเมิน Honeypot ที่สร้างขึ้นจากเหตุการณ์: Sol หากไม่มีมาตรการป้องกัน พยายามเข้าถึงเป้าหมายที่อยู่นอกขอบเขตที่ได้รับอนุญาตใน 48% ของการรัน Astra ทำได้ 0%

ตัวเลขสุดท้ายนั้นเป็นสิ่งที่มาถ่วงดุลกับเรื่องราวของความสามารถ OpenAI เรียก Astra ว่าเป็นโมเดลที่สอดคล้องมากที่สุด และตัวเลขความสอดคล้องก็สอดคล้องกัน: มันไม่เคยพยายามหลีกเลี่ยงการปฏิเสธการตรวจสอบอัตโนมัติของ Codex คะแนนความปลอดภัยในการใช้งานคอมพิวเตอร์ภายในอยู่ที่ 2.4% เทียบกับ 22.0% ของ Sol (ยิ่งต่ำยิ่งดี) และความสำเร็จในการโจมตีแบบ Prompt Injection ในการทดสอบของ Gray Swan ลดลงเหลือ 8.5% จาก 27.0% ข้อควรระวังที่ OpenAI ยกขึ้นมาเองคือ การให้เหตุผลของ Astra นั้นยากต่อการตรวจสอบมากกว่าของ Sol ซึ่งเป็นเหตุผลว่าทำไมจึงมีตัวตรวจสอบและระดับการเข้าถึงควบคู่ไปกับการฝึกอบรม

ทำไมเจ้าของ API ควรใส่ใจ

นี่คือความไม่สมมาตร Astra พบข้อบกพร่องใหม่ๆ ในเบราว์เซอร์และระบบปฏิบัติการที่มีการป้องกันอย่างแน่นหนา สิ่งเหล่านั้นคือหนึ่งในฐานรหัสที่มีการป้องกันดีที่สุดในโลก ซึ่งดูแลโดยทีมรักษาความปลอดภัยโดยเฉพาะและได้รับการทดสอบ Fuzz อย่างต่อเนื่อง API ของคุณไม่เหมือนอย่างนั้น ช่องโหว่ API ทั่วไปไม่ใช่ข้อบกพร่องด้านความปลอดภัยของหน่วยความจำในคอมไพเลอร์ JIT แต่เป็นการตรวจสอบการอนุญาตที่ไม่สมบูรณ์ใน Object ID, โทเค็นที่ไม่หมดอายุ, Schema ที่ยอมรับสตริงในขณะที่ควรปฏิเสธ หรือ Endpoint ที่ลืมจำกัดอัตรา เมื่อเทียบกันแล้ว ข้อบกพร่องเหล่านั้นเป็นเรื่องเล็กน้อย และสามารถพบได้โดยโมเดลรุ่นก่อนหน้าอยู่แล้ว

Astra ที่ถูกเปิดตัวจะไม่เขียน Exploit สำหรับสิ่งเหล่านี้ แต่มีสามสิ่งที่เป็นจริงอยู่ ผู้ป้องกันที่มีสิทธิ์เข้าถึง Daybreak จะค้นพบสิ่งเหล่านี้ได้ในวงกว้าง ซึ่งเป็นการยกระดับมาตรฐานสำหรับความหมายของคำว่า "เราทดสอบแล้ว" โมเดลอื่นๆ ไม่ว่าจะเป็นแบบ Open-weight หรือไม่ ก็กำลังดำเนินไปในทิศทางเดียวกัน และ การรั่วไหลของข้อมูล Vercel เมื่อต้นปีนี้แสดงให้เห็นว่า API ที่เปิดเผยจะกลายเป็นเหตุการณ์ได้อย่างรวดเร็วเพียงใด และ Astra เองในฐานะผู้ป้องกัน จะยินดีตรวจสอบ Handlers ของคุณและบอกคุณว่าการตรวจสอบขาดหายไปตรงไหน ต้นทุนในการค้นหาข้อบกพร่องลดลงสำหรับทุกคนแล้ว ตัวแปรเดียวที่คุณควบคุมได้คือใครจะพบมันก่อน

หกการตรวจสอบที่คุณควรทำกับ API ของคุณในสัปดาห์นี้

สิ่งเหล่านี้ไม่จำเป็นต้องใช้โมเดลที่จัดอันดับ Critical สิ่งเหล่านี้ต้องการชุดทดสอบที่ทำงานตามกำหนดเวลา

1. ขอบเขตการยืนยันตัวตน (Auth boundary). ทุก Endpoint ที่มีการป้องกัน ซึ่งถูกเรียกใช้โดยไม่มีโทเค็น, โทเค็นที่หมดอายุ และโทเค็นจาก Tenant อื่น คาดว่าจะได้รับ 401 หรือ 403 ในทั้งสามกรณี
2. การอนุญาตระดับวัตถุ (Object-level authorization). นำ Resource ID จากผู้ใช้ A และร้องขอในฐานะผู้ใช้ B การตอบกลับควรเป็น 403 หรือ 404 ไม่ใช่ Object
3. การบังคับใช้ Schema (Schema enforcement). ส่งข้อมูลประเภทที่ไม่ถูกต้อง, Payload ที่มีขนาดใหญ่เกินไป และฟิลด์ที่ไม่คาดคิดไปยัง OpenAPI Schema API ควรปฏิเสธสิ่งที่ไม่ถูกต้องตาม Specification Contract Test จะดำเนินการสิ่งนี้จาก Specification เอง
4. การจำกัดอัตราและการล็อก (Rate limits and lockouts). ลองส่งคำขอจำนวนมากไปยัง Login และ Token Endpoint และยืนยันว่าระบบจำกัดอัตราทำงานก่อนการพยายามครั้งที่ร้อย
5. สุขอนามัยของข้อมูลลับ (Secrets hygiene). ค้นหา (Grep) การตอบกลับและเนื้อหาของข้อผิดพลาดเพื่อหา Keys, Connection String และ Stack Trace ข้อความแสดงข้อผิดพลาดที่เขียนสำหรับมนุษย์อาจรั่วไหลได้
6. การทดสอบ Contract Regression ตามกำหนดเวลา (Scheduled contract regression). รันชุดการทดสอบทั้งหมดทุกคืนกับ Staging และทุกครั้งที่มีการ Deploy เพื่อให้สามารถตรวจจับ Regression ได้ในวันที่เปิดตัว ไม่ใช่วันที่ถูกโจมตี

ใน Apidog แต่ละรายการเหล่านี้เป็นสถานการณ์ทดสอบที่มีการยืนยันสถานะโค้ดและเนื้อหาการตอบกลับ โดยมีการกำหนดพารามิเตอร์ตามสภาพแวดล้อมเพื่อให้ชุดทดสอบเดียวกันทำงานกับ Dev, Staging และการตรวจสอบการผลิตแบบอ่านอย่างเดียว Apidog CLI รันสิ่งเหล่านี้ใน CI และการรันตามกำหนดเวลาจะเปลี่ยนการตรวจสอบทั้งหกรายการให้เป็นการควบคุมถาวร แทนที่จะเป็นการตรวจสอบเพียงครั้งเดียว ดาวน์โหลด Apidog หากคุณต้องการเริ่มต้นจาก Specification ที่คุณมีอยู่แล้ว การนำเข้าไฟล์ OpenAPI จะให้รายการ Endpoint ที่การตรวจสอบจะดำเนินการ

ใช้ Astra ในฐานะผู้ป้องกันที่ได้รับอนุญาตให้เป็น

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

ข้อสังเกตในการดำเนินงานสองประการ เก็บโมเดลไว้บนโค้ด Staging และใช้ข้อมูลรับรอง (credentials) ที่จำกัดขอบเขต เพราะผู้ตรวจสอบที่มี Production Keys ก็คือ Agent ที่มี Production Keys และ Guardrails ที่ใช้กับ Agent ทั่วไป ก็ใช้ได้กับกรณีนี้ด้วย และคาดว่าจะมีการรันที่ถูกขัดจังหวะเป็นครั้งคราว OpenAI กล่าวว่าตัวตรวจสอบสามารถหยุดงานป้องกันที่ถูกต้องตามกฎหมายได้ และใน API นั่นหมายความว่าคำขอจะสิ้นสุดลง ลองใหม่ด้วย Prompt ที่แคบลง

คำถามที่พบบ่อย

• GPT-6 Astra เป็นอันตรายต่อการใช้งานหรือไม่? โมเดลที่เปิดตัวปฏิเสธการพัฒนา Exploit, ได้รับการตรวจสอบในทุกคำขอที่ใช้เครื่องมือ และได้คะแนนดีกว่าโมเดล OpenAI รุ่นก่อนหน้าใดๆ ในการทดสอบความสอดคล้อง การจัดอันดับ Critical อธิบายถึงความสามารถของโมเดลที่ไม่มีข้อจำกัด ไม่ใช่พฤติกรรมของผลิตภัณฑ์ ความเสี่ยงหลักในทางปฏิบัติคือเช่นเดียวกับ Agent ใดๆ ที่มีข้อมูลรับรอง: จำกัดขอบเขตสิ่งที่มันสามารถเข้าถึงได้
• ฉันสามารถใช้สำหรับการทดสอบการเจาะระบบ (Penetration Testing) ได้หรือไม่? ไม่ใช่สำหรับการสร้าง Exploit ตามค่าเริ่มต้น การตรวจสอบโค้ดอย่างปลอดภัยและการแพตช์ได้รับอนุญาต การตรวจสอบ Proof-of-Concept, การวิเคราะห์มัลแวร์ และวิศวกรรมการตรวจจับถูกจำกัดผ่าน Daybreak ซึ่ง OpenAI กล่าวว่าจะขยายการเข้าถึงในอีกไม่กี่สัปดาห์ข้างหน้า การเปรียบเทียบ Daybreak Blue กับ Red ของเราครอบคลุมถึงวิธีการทำงานของระดับชั้นต่างๆ
• Astra เปรียบเทียบกับ GPT-5.6-Cyber อย่างไร? GPT-5.6-Cyber ได้รับการจัดอันดับ High และไม่เคยเป็น Self-serve Astra ได้รับการจัดอันดับ Critical และเป็น Self-serve พร้อมข้อจำกัด ใน ExploitBench คะแนน 100% ของ Astra เทียบกับ 78.5% ของ Sol; OpenAI ไม่ได้เผยแพร่ตารางเปรียบเทียบ Astra กับ Cyber โดยตรง
• แล้วโมเดลไซเบอร์ของ Gemini ล่ะ? Google จัดส่ง Gemini 3.8 Flash Cyber ผ่านโปรแกรม Fairwind โดยไม่มี API สาธารณะหรือราคา ผู้จำหน่ายทั้งสองรายตอนนี้จำกัดความสามารถในการโจมตีและจัดส่งความสามารถในการป้องกัน
• ตัวตรวจสอบจะบล็อกการรับส่งข้อมูล API ปกติของฉันหรือไม่? ไม่น่าจะเกิดขึ้นสำหรับคำขอสั้นๆ คำเตือนของ OpenAI เกี่ยวกับงาน Agent ที่ทำงานเป็นเวลานานและงานที่คล้ายกับกิจกรรมทางไซเบอร์ หากการรันหยุดลง ให้จำกัดขอบเขตของงานให้แคบลงแล้วลองใหม่

สรุป

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