วิธีที่เราสร้างเอเจนต์ที่ปลอดภัยยิ่งขึ้น

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

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

ที่ Perplexity เรากำลังร่วมมืออย่างแข็งขันกับนักวิจัยและผู้ปฏิบัติงานเพื่อพัฒนาวิศวกรรมความปลอดภัยสำหรับเอเจนต์ AI และเราใช้เลเยอร์การป้องกันหลายเลเยอร์ทั่วทั้งโมเดล, harness ของเอเจนต์ และโครงสร้างพื้นฐาน เพื่อให้ความปลอดภัยไม่ได้ขึ้นอยู่กับมาตรการป้องกันเพียงอย่างเดียว

พฤติกรรมความผิดพลาด (Meltdown) ของเอเจนต์ AI

ในเดือนกรกฎาคม เอเจนต์ AI ได้เจาะเข้าสู่โครงสร้างพื้นฐานการผลิตของแพลตฟอร์ม AI โอเพนซอร์ส Hugging Face ระหว่างการประเมินความปลอดภัยทางไซเบอร์ภายในและการฝึกอบรม โมเดลของ OpenAI ได้ค้นพบวิธีใช้ประโยชน์จากตัวจัดการที่เก็บ Artifactory เพื่อสร้างกระดานสนทนาสำหรับสื่อสารกันเอง ซึ่งช่วยให้พวกมันสามารถจัดกลุ่มเป็นฝูงได้ ต่อมา เอเจนต์ที่ไม่สามารถคืบหน้าในงานบนเบนช์มาร์กความปลอดภัยทางไซเบอร์ได้ ได้เกณฑ์เอเจนต์ตัวอื่นมาช่วย เอเจนต์เหล่านี้แหกสภาพแวดล้อมการประเมินออกไปและเข้าถึงอินเทอร์เน็ตได้ พวกมันยังค้นพบวิธีโกงด้วยการทำวิศวกรรมย้อนกลับเพื่อหาคำตอบสำหรับงานในเบนช์มาร์ก แต่คิดว่าระบบให้คะแนนจะตรวจพบการโกง เพื่อทำความเข้าใจว่าการประเมินของเบนช์มาร์กทำงานอย่างไรเพื่อหาวิธีหลีกเลี่ยงไม่ให้ถูกตรวจจับว่าโกง ในที่สุดพวกมันจึงได้ทำการบุกรุกระบบของ Hugging Face (Hugging Face; OpenAI)

เหตุการณ์ดังกล่าวเป็นตัวอย่างที่ชัดเจนของโหมดความล้มเหลวที่เราได้อธิบายไว้เมื่อเรา เปิดซอร์สโค้ดของ Numbat ในเดือนกรกฎาคม: การทำงานผิดพลาดโดยไม่ได้ตั้งใจ (accidental meltdowns) ซึ่งเป็นคำที่บัญญัติขึ้นโดยนักวิจัยด้านความปลอดภัยจาก Cornell Tech (arXiv) เมื่อเอเจนต์ที่กำลังทำตามเป้าหมายพบอุปสรรค เช่น ไฟล์ที่หายไป การเรียก API ที่ล้มเหลว ข้อมูลรับรองที่หมดอายุ หรือการปฏิเสธสิทธิ์ เอเจนต์จะค้นหาวิธีแก้ปัญหาเฉพาะหน้า ในการทำเช่นนั้น เอเจนต์อาจข้ามขอบเขตความปลอดภัยผ่านการลาดตระเวน การยกระดับสิทธิ์ การค้นหาข้อมูลลับ หรือการนำข้อมูลออกนอกระบบ ตัวเอเจนต์เองกลายเป็นผู้ไม่หวังดีโดยพฤติกรรม แม้ว่าจะไม่มีพรอมต์ที่เป็นอันตรายหรือผู้โจมตีภายนอกเกี่ยวข้องก็ตาม

Hugging Face ไม่ใช่กรณีเดียวที่เกิดขึ้น พฤติกรรมเอเจนต์ทำงานผิดพลาด (meltdown) ถูกค้นพบและรายงานเพิ่มขึ้นในสัปดาห์ล่าสุด เมื่อวันที่ 27-28 พฤษภาคม เอเจนต์ที่พยายามรวบรวมข้อมูลมหาวิทยาลัยไอโอวาจาก Data USA ซึ่งเป็นแพลตฟอร์มที่เปิดให้เข้าถึงข้อมูลรัฐบาลสหรัฐฯ แบบโอเพนซอร์ส พบข้อผิดพลาดที่เกิดจากคำสั่งค้นหา (query) ที่ไม่ถูกต้อง พวกเขาตอบสนองด้วยการตรวจสอบเชิงลึก เช่น SQL injection, cross-site scripting, template injection, path traversal และ command injection กิจกรรมดังกล่าวเชื่อมโยงกับ OpenAI ในเวลาต่อมา (SecurityWeek) วันที่ 20-21 มิถุนายน เอเจนต์ของ OpenAI ที่พยายามรวบรวมข้อมูลต้นทุนภาครัฐต่อบุคคลสำหรับประเภทยาในพื้นที่ท้องถิ่นในรัฐวิกตอเรียจากสถาบันสุขภาพและสวัสดิการแห่งออสเตรเลีย (AIHW) ถูกบล็อกไม่ให้ดาวน์โหลดไฟล์ เพื่อเป็นการตอบสนอง เอเจนต์จึงดาวน์โหลดไฟล์ดังกล่าวซึ่งเปิด ใช้งานสาธารณะอยู่แล้วจากเซิร์ฟเวอร์ pre-production ของ AIHW พร้อมทั้งหลบเลี่ยงการป้องกันบ็อตของเว็บไซต์ในกระบวนการดังกล่าว (SecurityWeek)

รูปแบบนี้ไม่ได้จำกัดอยู่แค่ในห้องปฏิบัติการแห่งเดียว ระหว่างการทดสอบความปลอดภัยทางไซเบอร์ โมเดลของ Anthropic ได้เจาะเข้าสู่สามบริษัทหลังจากความผิดพลาดทำให้โมเดลเหล่านี้สามารถเข้าถึงอินเทอร์เน็ตสาธารณะได้ Gemini ของ Google คาดเดาข้อมูลรับรองสำหรับเว็บไซต์สามแห่ง และโมเดลของ Meta ได้ใช้ประโยชน์จากบริการของบุคคลที่สาม (Reuters)

บทเรียนจากประวัติศาสตร์: ยุคแห่งเวิร์มอินเทอร์เน็ต

เหตุการณ์เหล่านี้ชวนให้นึกถึงยุคของเวิร์มอินเทอร์เน็ตเมื่อประมาณหนึ่งในสี่ของศตวรรษก่อน ในช่วงต้นทศวรรษ 2000 อินเทอร์เน็ตเติบโตเร็กว่าแนวปฏิบัติด้านความปลอดภัยรอบตัว เราเห็นไวรัสและเวิร์มจำนวนมาก ซึ่งส่งผลกระทบร้ายแรงกว่าสิ่งที่เราเห็นในปัจจุบันกับเอเจนต์ AI ที่เกิดความผิดพลาด (meltdown)

เมื่อวันที่ 4 พฤษภาคม 2000 ผู้คนเริ่มได้รับอีเมลจากผู้ส่งที่คุ้นเคยพร้อมหัวข้อเรื่อง "ILOVEYOU" การเปิดไฟล์แนบในอีเมลส่งผลให้สคริปต์ทำงานโดยการส่งสำเนาของตัวเองทางอีเมลไปยังทุกคนในสมุดรายชื่อ Outlook ของผู้เหยื่อ ภายในเวลา 18:00 น. ของวันนั้น ศูนย์ประสานงาน CERT ได้รับรายงานที่เกี่ยวข้องกับโฮสต์อินเทอร์เน็ตมากกว่า 420,000 ราย (รายงาน US GAO) มีรายงานว่าไวรัสเจาะทะลุหน่วยงานรัฐบาลกลางอย่างน้อย 14 แห่ง รวมถึงกระทรวงกลาโหม, CIA, NASA และสภาผู้แทนราษฎรและวุฒิสภา (รายงาน US GAO) นอกจากนี้ยังปิดการใช้งานเซิร์ฟเวอร์อีเมลที่เพนตากอนและรัฐสภาอังกฤษ (Wired) บริษัทประกันยักษ์ใหญ่ Lloyd's of London คาดการณ์ในเบื้องต้นว่าไวรัสจะสร้างความเสียหายและสูญเสียผลผลิตมากกว่า 15,000 ล้านดอลลาร์ (การไต่สวนของคณะกรรมาธิการสภาผู้แทนราษฎรสหรัฐฯ) Computer Economics ประเมินความเสียหายทั่วโลกในเวลาต่อมาอยู่ที่ 8,750 ล้านดอลลาร์ (Information Week)

เวิร์มที่ไม่จำเป็นต้องมีการคลิกจากมนุษย์ตามมาในเวลาต่อมา เมื่อวันที่ 19 กรกฎาคม 2001 เวิร์ม Code-Red ได้แพร่เชื้อไปยังคอมพิวเตอร์มากกว่า 359,000 เครื่องในเวลาน้อยกว่า 14 ชั่วโมง (CAIDA) เมื่อวันที่ 25 มกราคม 2003 SQL Slammer มีขนาดเพิ่มขึ้นเป็นสองเท่าทุก ๆ 8.5 วินาที และติดเชื้อโฮสต์อินเทอร์เน็ตมากกว่า 90% ที่มีความเสี่ยงภายใน 10 นาที (CAIDA) โดยใช้ประโยชน์จากช่องโหว่ที่ Microsoft ได้ปล่อยแพตช์มาแล้วหวกเดือนก่อนหน้า (CNET) ในเดือนสิงหาคม 2003 เวิร์ม Blaster และเวิร์มเมลอีเมล Sobig ปรากฏขึ้นห่างกันประมาณหนึ่งสัปดาห์ (Microsoft, F-Secure)

ในขณะนั้น เป็นเรื่องที่สมเหตุสมผลที่จะตั้งคำถามว่าคอมพิวเตอร์ที่เชื่อมต่อเครือข่ายจะสามารถทำให้ปลอดภัยได้จริงหรือไม่ หกวันหลังจากไวรัส ILOVEYOU คณะอนุกรรมการสภาผู้แทนราษฎรของสหรัฐฯ ได้จัดการไต่สวนเรื่องดังกล่าว ผู้เชี่ยวชาญด้านความปลอดภัยหลายคนเรียกร้องให้มีกฎหมายที่กำหนดให้บริษัทซอฟต์แวร์ต้องรับผิดชอบต่อความเสียหายที่เกิดจากข้อบกพร่องในผลิตภัณฑ์ของตน วอชิงตันเลือกเส้นทางที่แตกต่างออกไป ยุทธศาสตร์ชาติเพื่อรักษาความปลอดภัยไซเบอร์ (National Strategy to Secure Cyberspace) ระบุว่า “กฎระเบียบของรัฐบาลกลางจะไม่กลายเป็นวิธีหลักในการรักษาความปลอดภัยไซเบอร์” โดยเตือนว่านโยบายบังคับในวงกว้างอาจสร้าง “แนวทางมาตรฐานต่ำสุดสำหรับความปลอดภัยทางไซเบอร์” (CISA)

อุตสาหกรรมตอบสนองด้วยงานวิศวกรรม สิบเอ็ดวันหลังจาก ILOVEYOU, Microsoft ประกาศอัปเดต Outlook ที่บล็อกไฟล์แนบที่ปฏิบัติการได้ ในเดือนมกราคม 2002 บริษัทได้ให้ความสำคัญสูงสุดกับความปลอดภัย (Seattle Times) การแพตช์อัตโนมัติ ค่าเริ่มต้นที่ปลอดภัย โครงการ Bug Bounty และการเปิดเผยข้อมูลแบบประสานงานกลายเป็นแนวทางปฏิบัติมาตรฐาน ในปี 2008 Chrome เริ่มเรียกใช้เว็บเนื้อหาในแซนด์บ็อกซ์ที่ "จำกัดสิ่งที่ผู้โจมตีสามารถทำได้หลังจากใช้ประโยชน์จากข้อบกพร่อง" (Chromium Blog) การเข้ารหัสซึ่งเคยเป็นข้อยกเว้น กลายมาเป็นค่าเริ่มต้น เทคโนโลยีความปลอดภัย รวมถึงการตรวจสอบสิทธิ์แบบหลายปัจจัย, ไฟร์วอลล์, ซีโรทรัสต์ (zero trust) และการจัดการเหตุการณ์และความปลอดภัยของข้อมูล (SIEM) ได้รับการใช้งานอย่างแพร่หลาย องค์กรทั่วโลกคาดการณ์ว่าจะใช้จ่ายเงินประมาณ 240,000 ล้านดอลลาร์ในปี 2026 สำหรับความปลอดภัยของข้อมูล (Gartner) เวิร์มไม่เคยหายไปอย่างสมบูรณ์ แต่ยุคของการระบาดทั่วอินเทอร์เน็ตเป็นประจำได้จางหายไป ในขณะเดียวกัน อินเทอร์เน็ตที่แทบไม่มีกฎระเบียบมาควบคุม กลายเป็นกลไกที่ทรงพลังในการขับเคลื่อนนวัตกรรมและการเติบโตทางเศรษฐกิจตลอดสองทศวรรษถัดมา

วิศวกรรมความปลอดภัยสำหรับเอเจนต์ AI

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

การออกแบบนี้อยู่บนพื้นฐานของสมมติฐานหลายประการ: ผู้ใช้ส่วนใหญ่กระทำโดยสุจริต, ผู้ไม่หวังดีสามารถถูกยับยั้งได้ผ่านการตรวจสอบและผลลัพธ์ในโลกความเป็นจริง, และมนุษย์ดำเนินการต่าง ๆ ไม่ว่าจะถูกต้องหรือผิดพลาด ในอัตราที่จำกัด การนำกลไกความปลอดภัยเหล่านี้ไปใช้กับเอเจนต์จำเป็นต้องคำนึงถึงความแตกต่างระหว่างพฤติกรรมของมนุษย์และเอเจนต์ ดังที่เราได้เขียนไว้ใน คำตอบต่อคำขอข้อมูลของ NIST เกี่ยวกับความปลอดภัยของเอเจนต์ AI เอเจนต์ AI ท้าทายสมมติฐานเหล่านี้ พวกมันสามารถใช้สิทธิ์และดำเนินการด้วยความเร็วระดับเครื่องจักร ไม่ถูกยับยั้งจากผลลัพธ์ในโลกความเป็นจริง และอาจดำเนินการที่ได้รับอนุญาตทางเทคนิคแต่ผู้ใช้ทั่วไปแทบจะไม่ทำ

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

หลักการรักษาความปลอดภัยแบบป้องกันเชิงลึก (defense-in-depth)

หลักการรักษาความปลอดภัยที่สำคัญที่สุดที่ต้องนำไปใช้เพื่อรักษาความปลอดภัยให้กับเอเจนต์ AI คือการป้องกันแบบแบ่งชั้น (defense-in-depth) ซึ่งสนับสนุนสถาปัตยกรรมความปลอดภัยแบบหลายชั้น โดยใช้มาตรการป้องกันที่หลากหลายและซ้ำซ้อนเพื่อปกป้องทรัพยากรของระบบ ไม่มีมาตรการป้องกันใดที่สมบูรณ์แบบร้อยเปอร์เซ็นต์ ผู้ใช้อาจตกเป็นเหยื่อของการโจมตีแบบ social-engineering และเปิดเผยข้อมูลรับรองการเข้าสู่ระบบ ช่องโหว่ซอฟต์แวร์ประเภท zero-day ถูกค้นพบและนำไปใช้ประโยชน์ และระบบตรวจจับการบุกรุกไม่สามารถตรวจจับรูปแบบการโจมตีใหม่ๆ ได้ การป้องกันแบบแบ่งชั้นยอมรับความจริงข้อนี้และซ้อนเลเยอร์การป้องกันอิสระหลายเลเยอร์เข้าด้วยกัน หากเลเยอร์ป้องกันเลเยอร์หนึ่งถูกหลบเลี่ยง เลเยอร์อื่น ๆ จะยังคงอยู่เพื่อต่อต้านหรือตรวจจับการบุกรุกนั้น

เหตุการณ์ Hugging Face แสดงให้เห็นว่าเหตุใดการป้องกันแบบแบ่งชั้น (defense-in-depth) จึงมีความสำคัญ รายงานย้อนหลังของ OpenAI ระบุว่ามาตรการป้องกันอัตโนมัติที่ใช้ในระบบการผลิต ซึ่งรวมถึง harness, โมเดลการตรวจสอบอัตโนมัติ และเครื่องมือจัดหมวดหมู่ความปลอดภัย ไม่มีอยู่ในสภาพแวดล้อมการประเมิน หากการตรวจสอบ chain-of-thought ที่ปรับใช้ในปัจจุบันทำงานอยู่ในการประเมินเหล่านั้น ระบบจะตรวจจับกิจกรรมเริ่มต้นและแจ้งเตือนทีมรักษาความปลอดภัยได้มากกว่าหนึ่งวันก่อนที่จะเกิดการละเมิด (OpenAI) เลเยอร์ที่สามารถตรวจจับปัญหาได้มีอยู่แล้ว เพียงแต่เลเยอร์เหล่านั้นไม่ได้อยู่ในตำแหน่งเดียวกันพร้อมกันทั้งหมด

การรักษาความปลอดภัยให้กับเอเจนต์ AI จำเป็นต้องปรับปรุงทั้งความปลอดภัยและการรักษาความปลอดภัยของโมเดล AI และระบบรอบตัวพวกมัน การทำงานที่เลเยอร์โมเดลเป็นสิ่งสำคัญและกำลังเห็นผลลัพธ์ LLM รุ่นแรก ๆ ถูกชักนำได้ง่ายด้วยคำสั่งที่แทรกเข้ามา ในขณะที่โมเดลในปัจจุบันมีความสามารถในการจดจำและปฏิเสธคำสั่งเหล่านี้ได้ดีกว่ามาก นักพัฒนาโมเดลยังฝึกฝนโมเดลให้มีพฤติกรรมที่ปลอดภัยยิ่งขึ้น และดังที่บันทึกย้อนหลังของ OpenAI ได้อธิบายไว้ คือการตรวจสอบร่องรอยการให้เหตุผลเพื่อหาสัญญาณของพฤติกรรมที่มีปัญหา แต่การป้องกันระดับโมเดลเป็นเพียงส่วนหนึ่งของโซลูชัน ระบบที่เอเจนต์ถูกฝึกฝน ทดสอบ และปรับใช้ จะต้องได้รับการออกแบบทางวิศวกรรมเพื่อความปลอดภัยและการควบคุมด้วยเช่นกัน ความปลอดภัยระดับโมเดลช่วยลดความน่าจะเป็นที่เอเจนต์จะออกนอกลู่นอกทาง ความปลอดภัยระดับระบบช่วยจำกัดความเสียหายเมื่อเหตุการณ์นั้นเกิดขึ้น

ขยาย

กฎการออกแบบสำหรับมาตรการป้องกันที่ซ้ำซ้อน

การป้องกันแบบแบ่งชั้น (defense-in-depth) ต้องอาศัยมาตรการป้องกันที่ซ้ำซ้อน สำหรับเอเจนต์ เราสนับสนุนให้นำไปใช้ด้วยกฎการออกแบบสามข้อ:

1. ความเป็นอิสระ (Independence) แต่ละเลเยอร์ควรล้มเหลวด้วยเหตุผลที่เป็นอิสระต่อกัน การควบคุมสองรายการที่มีสมมติฐานเดียวกันสามารถถูกโจมตีด้วยวิธีเดียวกันได้ ตัวตรวจสอบและจุดบังคับใช้ควรอยู่นอกเหนือการเข้าถึงของเอเจนต์
2. การบังคับใช้ที่อยู่ต่ำกว่าระดับของเอเจนต์ (Enforcement below the agent) อย่างน้อยหนึ่งเลเยอร์ต้องเป็นแบบ deterministic: เป็นโค้ดดั้งเดิมที่สามารถตรวจสอบได้ซึ่งบล็อกการกระทำที่ห้ามไม่ว่าโมเดลจะสร้างผลลัพธ์อย่างไร มาตรการป้องกันที่เอเจนต์สามารถปฏิเสธที่จะเรียกใช้หรือกำหนดค่าใหม่ได้ ไม่ใช่มาตรการป้องกันที่แท้จริง
3. สัญญาณสามารถลดสิทธิ์ลงได้เท่านั้น (Signals can only reduce authority) การตรวจจับควรทริกเกอร์การตอบสนองที่จำกัดสิ่งที่เอเจนต์สามารถทำได้ เช่น การหยุดชั่วคราว การเพิกถอนข้อมูลรับรอง การตัดการเข้าถึงเครือข่าย หรือการยุติเซสชัน สัญญาณความเสี่ยงใดๆ จะไม่สามารถให้สิทธิ์การเข้าถึงเพิ่มเติมได้ไม่ว่ากรณีใดๆ

เราแบ่งปันหลักการเหล่านี้กับพันธมิตรของเราใน Open Secure AI Alliance รวมถึง NVIDIA ซึ่งให้เหตุผลว่า harness ทำหน้าที่แนะนำสิ่งที่เอเจนต์พยายามทำ ในขณะที่โครงสร้างพื้นฐานควบคุมสิ่งที่เอเจนต์สามารถทำได้ (NVIDIA)

การป้องกันแบบแบ่งชั้น (defense-in-depth) ในผลิตภัณฑ์ของ Perplexity

Perplexity เรียกใช้เอเจนต์ในสภาพแวดล้อมสี่ประเภท: บนคลาวด์ผ่านแพลตฟอร์มเอเจนต์ของเรา Computer, บนเบราว์เซอร์ผ่าน Comet, บนอุปกรณ์ของผู้ใช้ผ่าน Portable Computer และบนแล็ปท็อปของพนักงาน ซึ่งวิศวกรของเราใช้เอเจนต์เขียนโค้ดของบุคคลที่สาม สภาพแวดล้อมแต่ละแห่งมีความเสี่ยงของตนเอง และแต่ละแห่งจะได้รับการป้องกันหลายเลเยอร์

บนคลาวด์: Computer และ SPACE

งานของ Computer ทุกชิ้นทำงานใน SPACE ซึ่งเป็นแพลตฟอร์มแซนด์บ็อกซ์ของเรา โดยถือว่าเอเจนต์เป็นสิ่งที่ไม่น่าเชื่อถือตามค่าเริ่มต้น งานแต่ละชิ้นจะได้รับไมโคร VM ของตัวเอง ข้อมูลรับรองจะถูกเก็บไว้นอกแซนด์บ็อกซ์และจะถูกฉีดเข้าไปเฉพาะเมื่อจำเป็นเท่านั้น การรับส่งข้อมูลขาออกจะถูกควบคุมภายนอกเกสต์ และภาพสनैปชอต (snapshot) ช่วยให้เราสามารถย้อนกลับการเปลี่ยนแปลงที่ทำลายล้างได้ (Making SPACE) ลูกค้าองค์กรยังสามารถนำคีย์การเข้ารหัสของตนเองมาใช้ได้ การเพิกถอนคีย์จะทำให้ข้อมูลที่ได้รับการปกป้องไม่สามารถอ่านได้ และเอเจนต์ไม่สามารถลบล้างการตัดสินใจนั้นได้

เรายังทดสอบด้วยว่าเลเยอร์เหล่านี้สามารถป้องกันได้จริงหรือไม่ ใน Escaping SPACE: Part I เราให้สิทธิ์ root แก่โมเดลระดับแนวหน้าเก้าโมเดลภายในแซนด์บ็อกซ์ SPACE และขอให้พวกมันแหกคุกออกไป ไม่มีโมเดลใดหนีออกจาก VM ได้ แต่บางโมเดลหาวิธีหลีกเลี่ยงนโยบายเครือข่ายเมื่ออนุญาตให้เข้าถึงเครือข่ายบางส่วนได้ เราได้แก้ไขช่องโหว่เหล่านั้น ยืนยันการแก้ไขในการทดสอบซ้ำ และเปิดเผยจุดอ่อนที่คล้ายกันที่เราพบในแพลตฟอร์มแซนด์บ็อกซ์อื่น 8 จาก 10 แพลตฟอร์มแก่ผู้พัฒนา

ในเบราว์เซอร์: Comet และ BrowseSafe

Comet ใช้การป้องกัน prompt-injection แบบหลายชั้นตั้งแต่เปิดตัว: ตัวจำแนกประเภทจะคัดกรองเนื้อหาที่ดึงมา, พรอมต์ที่มีโครงสร้างจะทำเครื่องหมายว่าเป็นเนื้อหาที่ไม่น่าเชื่อถือ, การกระทำที่ละเอียดอ่อน เช่น การส่งอีเมลหรือการสั่งซื้อสินค้าต้องได้รับการยืนยันจากผู้ใช้ และผู้ใช้จะได้รับแจ้งเมื่อมีบางอย่างถูกบล็อก (การป้องกัน prompt-injection ของ Comet) BrowseSafe ซึ่งเป็นโมเดลตรวจจับแบบโอเพนซอร์สที่อยู่เบื้องหลังเลเยอร์แรก มีประสิทธิภาพเหนือกว่าโมเดลระดับแนวหน้าบนเบนช์มาร์ก BrowseSafe-Bench ของเรา แต่เบนช์มาร์กเดียวกันก็แสดงให้เห็นว่าไม่มีเครื่องมือตรวจจับใดที่ปลอดภัย 100% ซึ่งเป็นเหตุผลว่าทำไมการตรวจจับจึงไม่ใช่เลเยอร์เดียวเท่านั้น (การวิจัย BrowseSafe) Computer สืบทอดการป้องกันเหล่านี้ ซึ่งได้รับการตรวจสอบโดย Trail of Bits (Perplexity)

บนอุปกรณ์: Portable Computer

Portable Computer เป็นเอเจนต์แบบ local-first: โมเดล, harness, การสนทนา และวิถี (trajectory) จะอยู่บนเครื่องของผู้ใช้ตามค่าเริ่มต้น ออร์เคสเตรเตอร์แบบ deterministic ซึ่งเป็นโค้ด harness แทนที่จะเป็น LLM จะเรียกใช้วงจรและบังคับใช้นโยบาย โมเดลเสนอการกระทำ และการเรียกใช้เครื่องมือที่ได้รับการอนุมัติจะทำงานในแซนด์บ็อกซ์ระดับ OS ที่จำกัดกระบวนการ เส้นทางไฟล์ และการเข้าถึงเครือข่าย แซนด์บ็อกซ์เปิดใช้งานตลอดเวลาและเป็นแบบ fail-closed: หากไม่สามารถใช้งานได้ harness จะปิดการทำงานของตัวเองแทนที่จะเรียกใช้คำสั่งด้วยสิทธิ์ของผู้ใช้ การกระทำที่ข้ามขอบเขตอุปกรณ์ เช่น การค้นหาบนเว็บ, ตัวเชื่อมต่อ และการยกระดับไปยังโมเดลที่ปรึกษาบนคลาวด์ที่ทรงพลังกว่า จะเกิดขึ้นก็ต่อเมื่อผู้ใช้เปิดใช้งานและอนุมัติเท่านั้น ก่อนการเรียกใช้ที่ปรึกษา ตัวจำแนกประเภท PII จะทำเครื่องหมายข้อมูลที่ละเอียดอ่อนและผู้ใช้จะเห็นสิ่งที่กำลังจะถูกส่ง ที่ปรึกษาจะได้รับเฉพาะบริบทที่ได้รับการอนุมัติเท่านั้นและจะส่งคืนคำแนะนำที่เป็นข้อความ โดยไม่สามารถเข้าถึงไฟล์หรือเครื่องมือของอุปกรณ์ได้

บนเอ็นพอยต์: Numbat

เอเจนต์เขียนโค้ดบนแล็ปท็อปของนักพัฒนาทำงานเป็นเวลาหลายชั่วโมงโดยสามารถเข้าถึงซอร์สโค้ด ข้อมูลรับรอง และระบบการผลิต Numbat ซึ่งเป็นชุดเครื่องมือรักษาความปลอดภัยเอเจนต์แบบโอเพนซอร์สของเรา เพิ่มเลเยอร์อิสระที่อยู่นอกเหนือเอเจนต์ตัวเดียว ทำงานร่วมกับ harness เช่น Claude Code, Codex, OpenCode และ Pi บล็อกการกระทำที่เป็นอันตรายก่อนที่จะทำงาน ทำ3เครื่องหมายลำดับหลายขั้นตอนที่น่าสงสัย เช่น การอ่านข้อมูลลับแล้วส่งข้อมูลออกไป และรักษาไทม์ไลน์ของเซสชันสำหรับการตรวจสอบ Numbat ทำงานทั่วเอ็นพอยต์ของ Perplexity หลายพันรายการควบคู่ไปกับ Bumblebee ซึ่งเป็นเครื่องมือสแกนห่วงโซ่อุปทานแบบโอเพนซอร์สของเรา Computer คอยตรวจสอบผลลัพธ์ของพวกเขาเป็นประจำและเสนอaugข้อปรับปรุงกฎการตรวจจับ และมนุษย์จะอนุมัติการเปลี่ยนแปลงทุกครั้งก่อนที่จะนำไปใช้งาน

งานสำหรับคนทั้งอุตสาหกรรม

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

วิศวกรรมความปลอดภัยสำหรับเอเจนต์คืองานของคนทั้งอุตสาหกรรม ไม่มีบริษัทใดบริษัทหนึ่งที่ควบคุมสตั๊กทั้งหมดที่เอเจนต์ทำงานอยู่ นักพัฒนาโมเดล ผู้สร้าง harness ผู้ให้บริการแซนด์บ็อกซ์และรันไทม์ ผู้ให้บริการคลาวด์และฮาร์ดแวร์ และทีมรักษาความปลอดภัยขององค์กรต่างรับผิดชอบคนละเลเยอร์ ความปลอดภัยของส่วนรวมขึ้นอยู่กับว่าทุกเลเยอร์ยังคงทำงานได้เมื่อเลเยอร์อื่นเกิดข้อผิดพลาด นั่นคือเหตุผลที่เราสร้างมาตรการป้องกันที่ทำงานร่วมกับ harness ของเอเจนต์ได้และเปิดโอเพนซอร์สเครื่องมือของเรา นอกจากนี้ยังเป็นเหตุผลที่เราเปิดเผยจุดอ่อนที่เราพบในแพลตฟอร์มอื่น ๆ และมีส่วนร่วมในความพยายามต่าง ๆ เช่น Open Secure AI Alliance

เพื่อทำงานร่วมกับชุมชนในวงกว้างเกี่ยวกับความท้าทายเหล่านี้ Perplexity ได้เปิดตัว Secure Intelligence Institute ในเดือนมีนาคม 2026 เพื่อศึกษาความปลอดภัย ความน่าเชื่อถือ และการป้องกันทางปฏิบัติของระบบ AI ล้ำสมัย (Perplexity) ปัจจุบัน Perplexity กำลังร่วมมือและ/หรือให้ทุนสนับสนุนนักวิจัยทางวิชาการในมหาวิทยาลัยสแตนฟอร์ด, CMU, ดุ๊ก, โคลัมเบีย, โอไฮโอสเตต และมหาวิทยาลัยเวอร์จิเนีย เรายังดำเนินการวิจัยภายในองค์กรเพื่อผลักดันขอบเขตของการวิจัยความปลอดภัยของเอเจนต์ แปลความก้าวหน้าเหล่านั้นเป็นการปรับปรุงที่เป็นรูปธรรมในระบบของ Perplexity และแบ่งปันความรู้และทรัพยากรที่ช่วยเสริมความแข็งแกร่งให้กับระบบนิเวศ AI ในวงกว้าง เอเจนต์ที่ปลอดภัยกว่าคือสิ่งที่อุตสาหกรรมสามารถสร้างขึ้นได้ เราตั้งใจที่จะทำหน้าที่ของเราต่อไป และเราขอเชิญชวนผู้อื่นมาร่วมสร้างสรรค์ไปกับเรา