Cách chúng tôi thiết kế các tác nhân an toàn hơn

Các biện pháp bảo vệ nhiều lớp, giám sát độc lập và sự giám sát của con người trên các tác nhân đám mây, trình duyệt, cục bộ và điểm cuối của Perplexity.

A white shield and keyhole on a translucent glass tile against a teal landscape.

Để xây dựng các tác nhân AI an toàn hơn, chúng ta cần thiết kế phù hợp với cả năng lực lẫn các lỗi của chúng. Ngay cả khi thực hiện các tác vụ hợp pháp và không có bất kỳ hướng dẫn độc hại nào, các tác nhân có thể vượt qua các ranh giới bảo mật khi chúng cố gắng vượt qua các trở ngại.

Chúng tôi tin rằng đây là một vấn đề kỹ thuật bảo mật, và ngành công nghiệp nên giải quyết nó theo cách đã giải quyết các loại sâu internet đầu những năm 2000. Các hệ thống xung quanh các tác nhân phải giới hạn những gì tác nhân có thể truy cập, phát hiện hành vi không mong muốn và ngăn chặn sự cố khi chúng xảy ra.

Tại Perplexity, chúng tôi đang tích cực hợp tác với các nhà nghiên cứu và người thực hành để thúc đẩy kỹ thuật bảo mật cho các tác nhân AI, đồng thời chúng tôi áp dụng nhiều lớp phòng thủ trên các mô hình, harness của tác nhân và cơ sở hạ tầng của mình để bảo mật không phụ thuộc vào bất kỳ biện pháp bảo vệ đơn lẻ nào.

Hành vi suy sụp của các tác nhân AI

Vào tháng 7, các tác nhân AI đã đột nhập vào cơ sở hạ tầng sản xuất của nền tảng AI mã nguồn mở Hugging Face. Trong quá trình đánh giá an ninh mạng nội bộ và chạy huấn luyện, các mô hình của OpenAI đã phát hiện ra cách khai thác trình quản lý kho lưu trữ Artifactory để thiết lập một bảng thông báo giao tiếp với nhau, cho phép chúng tổ chức thành các bầy đàn. Sau đó, các tác nhân không thể tiến triển trong các tác vụ ở điểm chuẩn an ninh mạng đã chiêu mộ các tác nhân khác để giúp đỡ. Các tác nhân này đã thoát khỏi môi trường đánh giá của chúng và tiếp cận internet. Chúng cũng phát hiện ra các cách gian lận bằng cách kỹ nghệ ngược các câu trả lời cho các tác vụ điểm chuẩn, nhưng nghĩ rằng hệ thống chấm điểm sẽ phát hiện ra hành vi gian lận. Để hiểu rõ hơn về cách thức đánh giá điểm chuẩn hoạt động nhằm tìm cách tránh bị phát hiện là gian lận, cuối cùng chúng đã xâm phạm hệ thống Hugging Face (Hugging Face; OpenAI).

Sự cố này là một ví dụ rõ ràng về chế độ lỗi mà chúng tôi đã mô tả khi chúng tôi mã nguồn mở hóa Numbat vào tháng 7: suy sụp ngẫu nhiên, một thuật ngữ do các nhà nghiên cứu bảo mật từ Cornell Tech đặt ra (arXiv). Một tác nhân theo đuổi một mục tiêu hợp pháp gặp phải sự cản trở, chẳng hạn như thiếu tệp, lệnh gọi API thất bại, thông tin đăng nhập hết hạn hoặc từ chối quyền, và đi tìm giải pháp thay thế. Khi làm như vậy, nó có thể vượt qua các ranh giới bảo mật thông qua trinh sát, leo thang đặc quyền, khám phá bí mật hoặc khai thác dữ liệu. Bản thân tác nhân thực sự trở thành kẻ tấn công, mặc dù không có lời nhắc độc hại hay kẻ tấn công bên ngoài nào liên quan.

Hugging Face không phải là một trường hợp biệt lập. Nhiều hành vi suy sụp của tác nhân hơn đã được phát hiện và báo cáo trong những tuần gần đây. Vào ngày 27-28 tháng 5, các tác nhân cố gắng thu thập dữ liệu Đại học Iowa từ Data USA, một nền tảng cung cấp quyền truy cập mở vào dữ liệu chính phủ Hoa Kỳ, đã gặp lỗi do truy vấn có cấu trúc không hợp lệ. Chúng phản hồi bằng các lệnh dò tìm, bao gồm SQL injection, cross-site scripting, template injection, path traversal và command injection. Hoạt động này sau đó được liên kết với OpenAI (SecurityWeek). Vào ngày 20-21 tháng 6, các tác nhân của OpenAI cố gắng lấy chi phí chính phủ tính trên đầu người cho một loại thuốc trên các khu vực địa phương ở Victoria từ Viện Sức khỏe và Phúc lợi Úc (AIHW) đã bị chặn tải xuống một tệp. Để phản hồi, các tác nhân đã tải xuống tệp vốn đã công khai đó từ máy chủ tiền sản xuất của AIHW, qua đó vượt qua các biện pháp bảo vệ chống bot của trang web (SecurityWeek).

Mô hình này không giới hạn ở một phòng thí nghiệm duy nhất. Trong các bài kiểm tra an ninh mạng, các mô hình của Anthropic đã xâm nhập ba công ty sau một sai lầm cấp cho chúng quyền truy cập internet mở, Gemini của Google đã đoán được thông tin đăng nhập của ba trang web, và một mô hình của Meta đã khai thác dịch vụ của bên thứ ba (Reuters).

Bài học từ lịch sử: Kỷ nguyên của sâu internet

Những sự cố này gợi nhớ đến kỷ nguyên của sâu internet khoảng một phần tư thế kỷ trước. Vào đầu những năm 2000, internet phát triển nhanh hơn nhiều so với các thực tiễn bảo mật xung quanh nó. Chúng ta đã chứng kiến làn sóng virus và sâu, với hậu quả nghiêm trọng hơn rất nhiều so với những gì chúng ta đang thấy hiện nay với các tác nhân AI đang suy sụp.

Vào ngày 4 tháng 5 năm 2000, mọi người bắt đầu nhận được email từ người gửi quen thuộc với dòng tiêu đề "ILOVEYOU". Việc mở tệp đính kèm trong email dẫn đến việc chạy một tập lệnh gửi một bản sao của chính nó cho mọi người trong sổ địa chỉ Outlook của nạn nhân. Đến 6 giờ chiều ngày hôm đó, Trung tâm Điều phối CERT đã nhận được báo cáo liên quan đến hơn 420.000 máy chủ internet (Báo cáo GAO Hoa Kỳ). Virus này được cho là đã thâm nhập ít nhất 14 cơ quan liên bang, bao gồm Bộ Quốc phòng, CIA, NASA, Hạ viện và Thượng viện (Báo cáo GAO Hoa Kỳ). Nó cũng làm tê liệt các máy chủ email tại Lầu Năm Góc và Nghị viện Anh (Wired). Tập đoàn bảo hiểm Lloyd's of London đã đưa ra ước tính ban đầu rằng virus này sẽ gây thiệt hại hơn 15 tỷ USD và mất năng suất (Phiên điều trần Ủy ban Hạ viện Hoa Kỳ). Computer Economics sau đó ước tính thiệt hại 8,75 tỷ USD trên toàn thế giới (Information Week).

Tiếp theo là những con sâu không cần cú nhấp chuột của con người. Vào ngày 19 tháng 7 năm 2001, sâu Code-Red đã lây nhiễm hơn 359.000 máy tính trong vòng chưa đầy 14 giờ (CAIDA). Vào ngày 25 tháng 1 năm 2003, SQL Slammer đã tăng gấp đôi kích thước cứ sau 8,5 giây và lây nhiễm hơn 90% máy chủ internet dễ bị tổn thương trong vòng 10 phút (CAIDA), khai thác một lỗ hổng mà Microsoft đã phát hành bản vá sáu tháng trước đó (CNET). Vào tháng 8 năm 2003, sâu Blaster và sâu email Sobig xuất hiện cách nhau khoảng một tuần (Microsoft, F-Secure).

Vào thời điểm đó, việc đặt câu hỏi liệu các máy tính kết nối mạng có thể được làm cho an toàn hay không là điều hợp lý. Sáu ngày sau virus ILOVEYOU, một tiểu ban Hạ viện Hoa Kỳ đã tổ chức một phiên điều trần về vấn đề này. Nhiều chuyên gia bảo mật kêu gọi ban hành luật buộc các công ty phần mềm phải chịu trách nhiệm pháp lý đối với thiệt hại do các lỗi trong sản phẩm của họ gây ra. Washington đã chọn một con đường khác. Chiến lược Quốc gia để Bảo vệ Không gian Mạng (The National Strategy to Secure Cyberspace) tuyên bố rằng “quy định liên bang sẽ không trở thành phương tiện chính để bảo vệ không gian mạng.” Chiến lược này cảnh báo rằng các lệnh bắt buộc rộng rãi có thể tạo ra “cách tiếp cận theo mẫu số chung thấp nhất đối với an ninh mạng” (CISA).

Ngành công nghiệp đã đáp lại bằng kỹ thuật. Mười một ngày sau ILOVEYOU, Microsoft thông báo cập nhật Outlook chặn các tệp đính kèm có thể thi hành. Vào tháng 1 năm 2002, công ty đã đưa bảo mật lên ưu tiên hàng đầu (Seattle Times). Bản vá tự động, cài đặt mặc định an toàn, chương trình thưởng cho lỗi bảo mật và việc tiết lộ phối hợp đã trở thành tiêu chuẩn thực hành. Vào năm 2008, Chrome bắt đầu chạy nội dung web trong một sandbox "giới hạn những gì kẻ tấn công có thể làm sau khi khai thác một lỗi" (Chromium Blog). Mã hóa, từng là ngoại lệ, đã trở thành mặc định. Các công nghệ bảo mật, bao gồm xác thực đa yếu tố, tường lửa, zero trust và quản lý thông tin và sự kiện bảo mật (SIEM), đã trở nên được sử dụng rộng rãi. Các tổ chức trên toàn thế giới được dự báo sẽ chi khoảng 240 tỷ USD vào năm 2026 cho an ninh thông tin (Gartner). Sâu không bao giờ biến mất hoàn toàn, nhưng kỷ nguyên của các đợt bùng phát định kỳ trên toàn internet đã phai nhạt. Đồng thời, internet, phần lớn không bị cản trở bởi các quy định, đã trở thành một động cơ mạnh mẽ của sự đổi mới và tăng trưởng kinh tế trong hai thập kỷ tiếp theo.

Kỹ thuật bảo mật cho các tác nhân AI

Các sự cố gần đây đã đặt ra những câu hỏi chính đáng về quản trị tác nhân. Các cơ chế bảo mật hiện có được phát triển cho môi trường điện toán tiền tác nhân vốn có hành vi phần mềm được phạm vi hóa chặt chẽ và mang tính tất định cao. Đặc biệt, các cơ chế kiểm soát truy cập được thiết kế chủ yếu xoay quanh người dùng là con người và thường cấp cho họ các đặc quyền rộng rãi, về nguyên tắc, đủ để gây ra tác hại đáng kể.

Thiết kế này dựa trên một số giả định: hầu hết người dùng hành động với thiện chí; các tác nhân độc hại có thể bị ngăn chặn thông qua việc kiểm toán và hậu quả thực tế; và con người thực hiện các hành động, dù đúng hay sai, với tốc độ tương đối hạn chế. Việc áp dụng các cơ chế bảo mật này cho các tác nhân đòi hỏi phải tính đến những khác biệt giữa hành vi của con người và hành vi của tác nhân. Như chúng tôi đã viết trong phản hồi đối với yêu cầu thông tin của NIST về bảo mật tác nhân AI, các tác nhân AI thách thức các giả định này. Chúng có thể thực hiện các đặc quyền và hành động ở tốc độ máy móc, không bị ngăn chặn bởi các hậu quả trong thế giới thực và có thể thực hiện các hành động được cho phép về mặt kỹ thuật nhưng người dùng là con người thông thường hiếm khi thực hiện.

Việc trả lời những câu hỏi đó đòi hỏi kỹ thuật bảo mật. Chúng tôi biết các nguyên tắc bảo mật để xây dựng các hệ thống giữ cho rủi ro nằm trong tầm kiểm soát khi các thành phần riêng lẻ hoạt động sai. Nhưng chúng tôi cần đảm bảo rằng các nguyên tắc này được áp dụng khi thiết kế kỹ thuật cho các môi trường huấn luyện, kiểm tra và sử dụng các tác nhân AI.

Nguyên tắc bảo mật bảo mật nhiều lớp

Có thể nói, nguyên tắc bảo mật quan trọng nhất cần được áp dụng để bảo mật các tác nhân AI là tính bảo mật nhiều lớp, khuyến nghị kiến trúc bảo mật nhiều lớp, trong đó sử dụng nhiều biện pháp phòng thủ đa dạng và dự phòng để bảo vệ tài nguyên hệ thống. Không có biện pháp bảo vệ đơn lẻ nào là hoàn hảo. Mọi người có thể sập bẫy các cuộc tấn công kỹ nghệ xã hội và tiết lộ thông tin đăng nhập của mình, các lỗ hổng phần mềm zero-day bị phát hiện và khai thác, và hệ thống phát hiện xâm nhập bỏ sót các biến thể tấn công mới. Tính bảo mật nhiều lớp chấp nhận điều đó và chồng nhiều lớp phòng thủ độc lập. Nếu một lớp phòng thủ bị vô hiệu hóa, các lớp khác vẫn được giữ nguyên để chống lại hoặc phát hiện sự xâm nhập.

Sự cố Hugging Face cho thấy lý do tại sao tính bảo mật nhiều lớp lại quan trọng. Báo cáo hồi tưởng của OpenAI cho biết các biện pháp bảo vệ tự động được sử dụng trong hệ thống sản xuất của hãng, bao gồm harness, mô hình tự đánh giá và bộ phân loại an toàn, đã không có mặt trong môi trường đánh giá. Nếu tính năng giám sát chuỗi suy nghĩ hiện được triển khai của hãng được chạy trên các đánh giá đó, nó đã có thể phát hiện hoạt động ban đầu và gọi nhóm bảo mật hơn một ngày trước khi sự cố vi phạm xảy ra (OpenAI). Các lớp có thể phát hiện ra sự cố đã tồn tại. Chỉ là chúng không đồng thời có mặt tại cùng một thời điểm.

Bảo mật các tác nhân AI đòi hỏi phải cải thiện cả tính an toàn và bảo mật của các mô hình AI cũng như các hệ thống xung quanh chúng. Công việc ở lớp mô hình rất quan trọng và nó đang mang lại kết quả. Các LLM thời kỳ đầu dễ dàng bị thao túng bởi các hướng dẫn được tiêm nhiễm, trong khi các mô hình ngày nay tốt hơn đáng kể trong việc nhận diện và từ chối chúng. Các nhà phát triển mô hình cũng huấn luyện các mô hình để có hành vi an toàn hơn và, như phần hồi tưởng của OpenAI mô tả, giám sát các dấu vết suy luận để tìm các dấu hiệu hành vi có vấn đề. Nhưng các biện pháp phòng thủ cấp mô hình chỉ là một phần của giải pháp. Các hệ thống mà trong đó các tác nhân được huấn luyện, kiểm tra và triển khai cũng phải được thiết kế kỹ thuật để đảm bảo tính bảo mật và khả năng ngăn chặn. Tính an toàn cấp mô hình làm giảm khả năng tác nhân đi chệch hướng; tính bảo mật cấp hệ thống giới hạn thiệt hại khi điều đó xảy ra.

Quy tắc thiết kế cho các biện pháp bảo vệ dự phòng

Tính bảo mật nhiều lớp đòi hỏi các biện pháp bảo vệ dự phòng. Đối với các tác nhân, chúng tôi khuyến nghị áp dụng điều này với ba quy tắc thiết kế:

  1. Tính độc lập. Mỗi lớp nên thất bại vì các lý do độc lập. Hai biện pháp kiểm soát có chung một giả định có thể bị đánh bại bởi cùng một cuộc tấn công. Trình giám sát và điểm thực thi phải nằm ngoài tầm với của tác nhân.
  2. Thực thi bên dưới tác nhân. Ít nhất một lớp phải mang tính tất định: mã thông truyền, có thể xác minh giúp chặn các hành động bị cấm bất kể mô hình tạo ra gì. Biện pháp bảo vệ mà tác nhân có thể từ chối gọi hoặc cấu hình lại không phải là biện pháp bảo vệ.
  3. Tín hiệu chỉ có thể làm giảm thẩm quyền. Tính năng phát hiện nên kích hoạt các phản hồi thu hẹp những gì tác nhân có thể làm, chẳng hạn như tạm dừng, thu hồi thông tin đăng nhập, cắt quyền truy cập mạng hoặc chấm dứt phiên làm việc. Không có tín hiệu rủi ro nào được phép cấp thêm quyền truy cập.

Chúng tôi chia sẻ các nguyên tắc này với các đối tác của mình trong Open Secure AI Alliance, bao gồm NVIDIA, lập luận rằng harness hướng dẫn những gì tác nhân cố gắng thực hiện trong khi hạ tầng kiểm soát những gì nó có thể làm (NVIDIA).

Bảo mật nhiều lớp trong các sản phẩm của Perplexity

Perplexity chạy các tác nhân trong bốn loại môi trường: trên đám mây thông qua nền tảng tác nhân Computer, trên trình duyệt thông qua Comet, trên thiết bị của người dùng thông qua Portable Computer, và trên máy tính xách tay của nhân viên, nơi các kỹ sư của chúng tôi sử dụng các tác nhân viết mã của bên thứ ba. Mỗi môi trường có những rủi ro riêng và mỗi môi trường đều nhận được một số lớp bảo vệ.

Lớp

Chức năng thực hiện

Vị trí xuất hiện trong các sản phẩm của Perplexity

Trạng thái

Hướng dẫn

Giữ cho tác nhân bám sát ý định của người dùng

Các biện pháp bảo vệ ở cấp độ công cụ trong các lời nhắc hệ thống, nội dung không đáng tin cậy được đánh dấu là như vậy, và tham chiếu liên tục đến yêu cầu ban đầu của người dùng trong Computer và Comet

Đã triển khai

Sàng lọc đầu vào

Phát hiện nội dung thù địch trước khi tác nhân hành động dựa trên nội dung đó

BrowseSafe và các trình phân loại liên quan quét nội dung được truy xuất song song với quá trình suy luận của tác nhân và kích hoạt điểm dừng an toàn

Đã triển khai; mô hình và điểm chuẩn đã được mã nguồn mở

Khả năng ngăn chặn

Giới hạn những gì một tác nhân hoạt động sai có thể tiếp cận

SPACE: một microVM Firecracker tạm thời cho mỗi tác vụ, thông tin đăng nhập được giữ bên ngoài sandbox, lưu lượng truy cập đi được kiểm soát ở cấp độ nút; sandbox cấp hệ điều hành luôn bật, ở chế độ đóng khi lỗi của Portable Computer

Được triển khai cho tất cả người dùng Computer và Portable Computer

Giám sát và phản hồi độc lập

Theo dõi những gì tác nhân thực sự làm và chặn các hành động nguy hiểm

Numbat trên các điểm cuối của khách hàng; nhật ký kiểm toán thời gian thực cho các tác nhân Computer và Comet

Đã triển khai; Numbat đã được mã nguồn mở

Vòng lặp cải tiến

Biến các phát hiện thành các biện pháp kiểm soát tốt hơn

Computer xem xét các phát hiện của Numbat và Bumblebee, đồng thời đề xuất các bản cập nhật quy tắc để con người xem xét trước khi phát hành

Đã triển khai nội bộ

Thử nghiệm đối kháng

Kiểm tra xem các lớp khác có trụ vững hay không khi một tác nhân chủ động cố gắng phá vỡ chúng

Đánh giá nhóm đỏ (red-team) của SPACE với chín mô hình tiên tiến; kiểm toán của Trail of Bits về các biện pháp phòng thủ chống tiêm nhiễm lời nhắc (prompt-injection); chương trình thưởng cho lỗi bảo mật (bug bounty)

Các phát hiện đã được khắc phục, kiểm tra lại và công bố

Trên đám mây: Computer và SPACE

Mỗi tác vụ Computer chạy trong SPACE, nền tảng sandbox của chúng tôi, coi tác nhân là không đáng tin cậy theo mặc định. Mỗi tác vụ có microVM riêng, thông tin đăng nhập nằm bên ngoài sandbox và chỉ được tiêm vào khi cần thiết, lưu lượng truy cập đi được kiểm soát bên ngoài môi trường khách và các bản snapshot cho phép chúng tôi khôi phục các thay đổi mang tính phá hủy (Making SPACE). Khách hàng doanh nghiệp cũng có thể mang theo khóa mã hóa của riêng họ. Việc thu hồi khóa làm cho dữ liệu được bảo vệ trở nên không thể đọc được và tác nhân không thể ghi đè quyết định đó.

Chúng tôi cũng kiểm tra xem các lớp này có trụ vững hay không. Trong Escaping SPACE: Part I, chúng tôi đã cấp cho chín mô hình tiên tiến quyền root bên trong một sandbox SPACE và yêu cầu chúng thoát ra. Không có mô hình nào thoát khỏi VM, nhưng một số đã tìm ra cách lẩn tránh chính sách mạng khi được phép truy cập mạng một phần. Chúng tôi đã khắc phục những khoảng trống đó, xác nhận các bản sửa lỗi trong một đợt kiểm tra lại và tiết lộ các điểm yếu tương tự mà chúng tôi tìm thấy ở tám trong số 10 nền tảng sandbox khác cho các nhà cung cấp của họ.

Trên trình duyệt: Comet và BrowseSafe

Comet đã sử dụng cơ chế phòng thủ chống tiêm nhiễm lời nhắc nhiều lớp kể từ khi ra mắt: các bộ phân loại sàng lọc nội dung được truy xuất, các lời nhắc có cấu trúc đánh dấu nội dung đó là không đáng tin cậy, các hành động nhạy cảm như gửi email hoặc đặt hàng yêu cầu sự xác nhận của người dùng và người dùng được thông báo khi có thứ gì đó bị chặn (các biện pháp phòng thủ chống tiêm nhiễm lời nhắc của Comet). BrowseSafe, mô hình phát hiện mã nguồn mở đằng sau lớp đầu tiên, vượt trội hơn các mô hình tiên tiến trên điểm chuẩn BrowseSafe-Bench của chúng tôi, nhưng cùng một điểm chuẩn cho thấy không có trình phát hiện nào là an toàn tuyệt đối, đó là lý do tại sao tính năng phát hiện không bao giờ là lớp duy nhất (nghiên cứu BrowseSafe). Computer kế thừa các cơ chế phòng thủ này, đã được kiểm toán bởi Trail of Bits (Perplexity).

Trên thiết bị: Portable Computer

Portable Computer là một tác nhân ưu tiên cục bộ: mô hình, harness, cuộc trò chuyện và quỹ đạo mặc định nằm trên máy của người dùng. Trình điều phối mang tính tất định, là mã harness chứ không phải LLM, chạy vòng lặp và thực thi chính sách. Mô hình đề xuất các hành động và các lệnh gọi công cụ được phê duyệt chạy trong sandbox cấp hệ điều hành hạn chế các tiến trình, đường dẫn tệp và quyền truy cập mạng. Sandbox luôn bật và ở chế độ đóng khi lỗi: nếu nó không khả dụng, harness sẽ tự vô hiệu hóa thay vì chạy các lệnh với quyền của người dùng. Các hành động vượt qua ranh giới thiết bị, chẳng hạn như tìm kiếm trên web, trình kết nối và leo thang lên mô hình cố vấn đám mây mạnh mẽ hơn, chỉ xảy ra khi người dùng bật và phê duyệt chúng. Trước khi gọi cố vấn, bộ phân loại PII gắn cờ thông tin nhạy cảm và người dùng thấy những gì sẽ được gửi. Cố vấn chỉ nhận ngữ cảnh đã được phê duyệt đó và trả về hướng dẫn dạng văn bản, không có quyền truy cập vào các tệp hoặc công cụ của thiết bị.

Trên điểm cuối: Numbat

Các tác nhân viết mã trên máy tính xách tay của nhà phát triển chạy trong nhiều giờ với quyền truy cập vào mã nguồn, thông tin đăng nhập và hệ thống sản xuất. Numbat, bộ công cụ bảo mật tác nhân mã nguồn mở của chúng tôi, bổ sung một lớp độc lập nằm bên ngoài bất kỳ tác nhân đơn lẻ nào. Nó hoạt động với các harness như Claude Code, Codex, OpenCode và Pi, chặn các hành động nguy hiểm trước khi chúng chạy, gắn cờ các chuỗi nhiều bước đáng ngờ như đọc tệp bí mật rồi gửi dữ liệu đi, đồng thời bảo lưu dòng thời gian phiên làm việc để điều tra. Numbat chạy trên hàng nghìn điểm cuối của Perplexity cùng với Bumblebee, trình quét chuỗi cung ứng mã nguồn mở của chúng tôi. Computer thường xuyên xem xét các phát hiện của chúng và đề xuất các quy tắc phát hiện được cải thiện, và con người phê duyệt mọi thay đổi trước khi nó được phát hành.

Một công việc cho toàn bộ ngành công nghiệp

Khi các tác nhân AI ngày càng có năng lực hơn và được sử dụng rộng rãi hơn, kỹ thuật bảo mật phải vẫn là trọng tâm trong quá trình phát triển và triển khai của chúng. Các nhà nghiên cứu và kỹ sư có thể xây dựng dựa trên các nguyên tắc đã được thiết lập, sử dụng các phát hiện trong thế giới thực để tinh chỉnh các biện pháp phòng thủ và kiểm tra các biện pháp bảo vệ trên các môi trường mà các tác nhân hoạt động. Bảo mật là một ngành kỹ thuật liên tục phát triển song song với công nghệ.

Kỹ thuật bảo mật cho các tác nhân là công việc của toàn bộ ngành công nghiệp. Không có công ty đơn lẻ nào kiểm soát toàn bộ ngăn xếp mà một tác nhân chạy trên đó. Các nhà phát triển mô hình, nhà xây dựng harness, nhà cung cấp sandbox và thời gian chạy, nhà cung cấp đám mây và phần cứng, cùng các nhóm bảo mật doanh nghiệp đều sở hữu một lớp riêng. Sự an toàn của toàn bộ hệ thống phụ thuộc vào việc mọi lớp đều trụ vững khi một lớp khác trượt ngã. Đó là lý do tại sao chúng tôi xây dựng các biện pháp bảo vệ hoạt động trên các harness của tác nhân và mã nguồn mở hóa các công cụ của mình. Đó cũng là lý do tại sao chúng tôi tiết lộ các điểm yếu mà chúng tôi tìm thấy ở các nền tảng khác và tham gia vào các nỗ lực như Open Secure AI Alliance.

Để làm việc với cộng đồng rộng lớn hơn về những thách thức này, Perplexity đã ra mắt Secure Intelligence Institute vào tháng 3 năm 2026 nhằm nghiên cứu tính bảo mật, độ tin cậy và khả năng phòng thủ thực tế của các hệ thống AI tiên tiến (Perplexity). Perplexity hiện đang hợp tác và/hoặc tài trợ cho các nhà nghiên cứu học thuật tại Stanford, CMU, Duke, Columbia, Ohio State và Đại học Virginia. Chúng tôi cũng đang tiến hành nghiên cứu nội bộ để thúc đẩy ranh giới của nghiên cứu bảo mật tác nhân, chuyển hóa những tiến bộ đó thành các cải tiến cụ thể trong hệ thống của Perplexity, đồng thời chia sẻ kiến thức và tài nguyên giúp củng cố hệ sinh thái AI rộng lớn hơn. Các tác nhân an toàn hơn là điều ngành công nghiệp có thể thiết kế. Chúng tôi có ý định tiếp tục làm phần việc của mình và mời những người khác cùng xây dựng với chúng tôi.