Giải thích về Red Teaming AI: Red Team kiểm thử những gì và những gì còn lại phía sau

Hầu hết các đợt red teaming AI đều bị đánh giá bằng sai sản phẩm đầu ra. Một tuần làm việc tạo ra một bộ slide, bộ slide nói rằng có thể dụ trợ lý viết một email phishing, và sau đó không ai có thể nói liệu hành vi đó có tái lập được không, nó tệ đến mức nào, hay biện pháp kiểm soát nào lẽ ra đã chặn được nó. Lĩnh vực này có một đầu ra thực sự, và đó không phải là một bộ slide: đó là một tập hợp các phát hiện vẫn đứng vững khi chạy lại, mỗi phát hiện gắn với một ranh giới đã bị vượt qua và với bằng chứng đã vượt qua ranh giới đó. Đó cũng là hình dạng của bản ghi mà kho lưu trữ sự cố AI lưu giữ — 400 mục bao quát từ tháng 12 năm 2024 đến tháng 10 năm 2026, được rút ra từ 743 nguồn riêng biệt, kèm theo một phán quyết cho từng mục về việc liệu có ai thực sự bị tổn hại hay không.

Sự nhầm lẫn là dễ hiểu, vì “red teaming” được dùng cho hai công việc chỉ chia sẻ từ vựng và hầu như không chia sẻ gì khác. Đây là hướng dẫn cho cả hai, về bằng chứng mà mỗi bên cần tạo ra, và về bốn điểm mà red teaming AI thực sự khác với phiên bản mạng mà hầu hết đội ngũ bảo mật đã biết cách triển khai.

Câu hỏi về khung: ai sở hữu bài kiểm thử?

Trước khi bàn đến phạm vi, có câu hỏi về việc ai đang điều hành bài tập và nhằm chống lại điều gì. Microsoft công bố một trong những quan điểm công khai đầy đủ hơn về vấn đề này, và đáng đọc như một tấm bản đồ hơn là một trang sản phẩm. Trung tâm AI Red Team của hãng tách khái niệm về red teaming AI khỏi cách thực hiện, rồi sắp xếp cách thực hành này theo một thứ tự mà bản thân nó đã là một lập luận: tổng quan, rồi hướng dẫn xây dựng một đội red team LLM, rồi tài liệu tham khảo — một bug bar để phân loại ưu tiên các cuộc tấn công vào hệ thống học máy, một hệ thống phân loại các thất bại của học máy, một mô hình trách nhiệm chung, và hướng dẫn mô hình hóa mối đe dọa dành cho nhà phát triển.

Đọc trình tự và phương pháp luận sẽ hiện ra. Một hệ thống phân loại quyết định điều gì được tính là thất bại. Một ngưỡng lỗi quyết định lỗi nào trong số đó đáng để sửa. Một mô hình trách nhiệm chia sẻ quyết định ai phải chịu trách nhiệm về nó khi nó được phát hiện. Mô hình hóa mối đe dọa quyết định nơi cần tìm tiếp theo. Không có bốn thứ đó, một nhóm red team chỉ đang tạo ra những giai thoại với một cột mức độ nghiêm trọng gắn thêm vào, và cột mức độ nghiêm trọng đó chính là bất cứ điều gì mà người kiểm thử cảm thấy vào chiều hôm đó.

PyRIT, khung tự động hóa mã nguồn mở của Microsoft, được xếp cùng một ngăn kệ, và chính cách xếp đó mới là phần hữu ích. Một bộ công cụ điều phối không phải là một phương pháp luận; nó là thứ bạn nhắm vào một mục tiêu sau khi đã có phân loại học và tiêu chuẩn lỗi. Những nhóm khởi đầu bằng khung này thường kết thúc với một kho prompt đồ sộ mà không có cách nào để xếp hạng kết quả.

Hai đội red team, hai câu hỏi khác nhau

Khác biệt hữu ích nhất trong lĩnh vực này là điều gần như không ai chịu viết ra: một red team kiểm thử một mô hình và một red team kiểm thử một hệ thống đang trả lời những câu hỏi khác nhau, với những đơn vị được kiểm thử khác nhau, những đầu ra khác nhau và những chủ sở hữu khác nhau. Trộn lẫn hai thứ này chính là cách một vụ jailbreak bị báo cáo như một phát hiện bảo mật, và cũng là cách một lỗi leo thang đặc quyền thực sự bị ghi nhận thành một khiếu nại về chất lượng mô hình.

Đánh giá an toàn ở cấp độ mô hình là một bài toán đo lường. Bạn đang hỏi liệu một mô hình có tạo ra một loại nội dung nào đó hay không, và cách trung thực để trả lời là dùng một mẫu đủ lớn để nói lên điều gì đó về một tỷ lệ. Đơn vị được kiểm thử là mô hình nằm sau một API mỏng, phương pháp là nhắc lệnh đối kháng — jailbreak, tấn công bằng persona, áp lực qua nhiều lượt — và đầu ra là một bản ghi hội thoại kèm một đánh giá về mức độ gây hại. Khi trọng số thay đổi hoặc lớp an toàn của nhà cung cấp thay đổi, toàn bộ kết quả trở nên lỗi thời. Đó là lý do loại kiểm thử này thường được nhà xây dựng mô hình hoặc một bên đánh giá độc lập thực hiện, và lý do các phát hiện của nó hiếm khi ánh xạ tới một bản sửa cụ thể trong ứng dụng của bạn.

Mô phỏng đối thủ ở cấp hệ thống là một bài toán kỹ thuật. Bạn đang hỏi liệu kẻ tấn công có thể khiến thứ đã được triển khai hành động hay không — đọc một tệp mà nó không nên đọc, gọi một công cụ mà nó không nên gọi, tiêu tiền mà nó không nên tiêu. Đơn vị được kiểm thử là agent cùng với các công cụ, khả năng truy xuất và thông tin xác thực được gắn kèm. Các phương pháp là những phương pháp quen thuộc, được nhắm lại mục tiêu: tiêm nhiễm qua nội dung được truy xuất thay vì qua lượt của người dùng, lạm dụng công cụ, chuỗi đặc quyền được lắp ghép từ những quyền riêng lẻ có vẻ hợp lý, các đường dẫn dữ liệu rò rỉ qua ranh giới tenant. Đầu ra là một phát hiện kèm bản tái hiện, một ranh giới bị vượt qua, và một chủ sở hữu có thể thay đổi cấu hình vào ngày mai.

Hai loại tạo ra những tạo tác không tương thích, và sự không tương thích đó mang tính chẩn đoán chứ không chỉ gây phiền toái. Kết quả ở cấp mô hình không thể được nhóm của bạn "khắc phục" ngoại trừ bằng cách chuyển sang mô hình khác. Kết quả ở cấp hệ thống hoàn toàn không thể được nhà cung cấp khắc phục. Nếu một báo cáo không nói rõ đó là loại nào trong hai loại, bạn không thể gán bất kỳ mục nào của nó.

Bề mặt tấn công sẽ trở thành gì khi mô hình có công cụ

Bề mặt mà hầu hết các nhóm vẫn kiểm thử là prompt. Đây cũng là bề mặt kém thú vị nhất, vì nó là thứ mà nhà cung cấp mô hình đã dồn nhiều công sức nhất để gia cố và cũng là thứ mà kẻ tấn công có ít đòn bẩy nhất. Những bề mặt thực sự đáng giá là những bề mặt do ứng dụng bổ sung: các công cụ mà tác tử có thể gọi, chỉ mục truy xuất mà nó đọc, bộ nhớ mà nó mang giữa các lượt, và chính kênh đầu ra.

Công cụ là nơi một mô hình ngôn ngữ trở thành một tác nhân, và câu hỏi thú vị không bao giờ là "liệu nó có thể gọi công cụ hay không" mà là "công cụ này lẽ ra có thể có đặc quyền tối thiểu nào". Một công cụ tra cứu ticket chấp nhận truy vấn văn bản tự do thường có thể bị dụ chấp nhận mã định danh của một khách hàng khác. Truy xuất là một kênh nội dung đi vào ngữ cảnh của mô hình, nghĩa là bất kỳ ai có thể ghi vào kho ngữ liệu — một ổ đĩa dùng chung, một macro hỗ trợ, một trang web mà bộ tìm nạp truy cập tới — đều đang ghi vào prompt. Bộ nhớ biến một lượt đơn lẻ thành sự tồn tại dai dẳng: một chỉ thị được cài ở lượt hai vẫn còn đó ở lượt bốn mươi. Đầu ra là nơi văn bản của mô hình rơi vào một nơi nào đó diễn giải nó, và việc kết xuất, markdown, xem trước liên kết và các pipeline gần với shell đều diễn giải văn bản.

Một cuộc đánh giá chỉ kiểm tra prompt sẽ báo cáo kết quả sạch và đúng về thứ sai lầm.

Vì sao bản ghi lời nói không phải là một phát hiện

Một phát hiện cần ba thuộc tính mà ảnh chụp màn hình cửa sổ chat không có. Thuộc tính đầu tiên là khả năng tái tạo: chạy lại từ trạng thái sạch và nó lại xảy ra. Mô hình không tất định, nên khả năng tái tạo là một tỷ lệ chứ không phải giá trị boolean — "chín trên mười lần thử" là một phát hiện, "nó đã xảy ra một lần" là một tin đồn. Thuộc tính thứ hai là một ranh giới bị vượt qua: gọi tên điều đáng lẽ không nên xảy ra theo chính thuật ngữ của ứng dụng, không phải theo thuật ngữ của mô hình. Không phải "mô hình đã thô lỗ", mà là "tác nhân đã đọc một tài liệu thuộc về tenant B". Thuộc tính thứ ba là một mức độ nghiêm trọng truy vết được tới tác động thay vì tới trực giác của người kiểm thử, đó là mục đích của thanh chuẩn lỗi (bug bar).

Mọi thứ khác — bản ghi, lời nhắc, lập luận của mô hình — là bằng chứng hỗ trợ ba điều đó. Đó không phải là bản thân phát hiện, và đây là lý do tại sao một kho ngữ liệu gồm hai nghìn lời nhắc jailbreak lại có giá trị thấp hơn năm phát hiện hệ thống có thể tái tạo với các đối chứng có tên đi kèm.

Bốn điểm mà red teaming AI khác biệt so với red teaming mạng

Các nhóm đến từ bảo mật mạng hoặc bảo mật ứng dụng mang theo trực giác tốt và bốn giả định sai lầm.

• Không có vành đai nào để bảo vệ. Một đợt đánh giá mạng có danh sách mục tiêu; một đợt đánh giá tác nhân có cửa sổ ngữ cảnh được lắp ráp tại thời điểm yêu cầu từ những nguồn mà bạn có thể chưa kiểm kê. Phạm vi phải được biểu đạt dưới dạng nguồn dữ liệu và quyền của công cụ, chứ không phải tên máy chủ.

• Mục tiêu là không tất định. Cùng một đầu vào có thể thành công vào thứ Ba và thất bại vào thứ Tư. Điều này phá vỡ tiêu chuẩn bằng chứng “một lần tái hiện sạch” và buộc bạn phải báo cáo tỷ lệ.

• Cách khai thác là ngôn ngữ, và ngôn ngữ không có bản vá. Bạn có thể sửa một kiểm tra phân quyền bị thiếu. Bạn không thể vá "mô hình có thể bị thuyết phục". Biện pháp giảm thiểu cho một điểm yếu ở cấp độ ngôn ngữ là một biện pháp kiểm soát ở nơi khác — một bộ lọc, một giới hạn phạm vi, một ranh giới quyền — đó là lý do vì sao các phát hiện cần nêu tên biện pháp kiểm soát, chứ không chỉ hành vi.

• Nhà cung cấp nằm trong vòng lặp. Mục tiêu của bạn thay đổi khi người khác phát hành một phiên bản. Kết quả ở cấp độ mô hình chỉ có giá trị đối với bản dựng mà bạn đã kiểm thử, và nếu bạn không ghi lại phiên bản và ngày, bạn không có kết quả.

Cách xác định phạm vi cho lần hợp tác đầu tiên

Những đợt triển khai diễn ra tồi tệ gần như luôn được xác định phạm vi là "kiểm thử AI". Một phạm vi có thể trụ vững khi va chạm với lịch trình thực tế trông giống như sau: một agent, trong môi trường staging, với dữ liệu và quyền hạn có đặc tính như production; một danh sách năm ranh giới quan trọng (cô lập tenant, truy cập thông tin xác thực, chi tiêu, luồng dữ liệu ra ngoài, phạm vi công cụ); các quy tắc tiến hành nêu rõ những gì nằm ngoài giới hạn; các điều kiện dừng quy định ai có thể dừng lần chạy; và một định dạng bằng chứng được xác định và thống nhất trước lần thử đầu tiên, để báo cáo được lắp ghép từ các artefact thay vì tái dựng từ trí nhớ.

Việc cấp phép xứng đáng có một câu riêng, vì đây là hạng mục mà các đội thường bỏ qua khi mục tiêu là sản phẩm của chính họ còn công cụ là của người khác. Kiểm thử một mô hình mà bạn không vận hành, trên hạ tầng mà bạn không sở hữu, bằng các prompt được thiết kế để vô hiệu hóa một lớp an toàn, là một hoạt động khác với việc kiểm thử triển khai của chính bạn — và phạm vi được ghi thành văn bản là thứ phân biệt hai hoạt động này. Cổng xác minh mà tầng an ninh mạng của chính chúng tôi áp dụng cũng tồn tại vì lý do tương tự: công việc bảo mật được cấp phép ở cấp độ mô hình cần một bên có tên cụ thể và chịu trách nhiệm ở cả hai phía.

Hồ sơ sự cố bổ sung điều gì

Một lần chạy red team cho bạn biết mục tiêu của bạn làm gì. Nó không thể cho bạn biết điều gì xảy ra trên thực địa, mà thực địa mới là nơi lập luận cho một biện pháp kiểm soát thực sự được đưa ra. Đó chính là khoảng trống mà một sổ cái sự cố lấp đầy — và kỷ luật mà nó áp đặt mới là phần hữu ích: một bản ghi không có ít nhất một nguồn thì không tồn tại, và một bản ghi không có phán quyết tổn hại thì không phải là sự cố.

Đọc hai tài liệu cùng nhau và vòng lặp sẽ khép lại. Nhóm red team tạo ra một phát hiện có thể tái lập và chỉ ra biện pháp kiểm soát lẽ ra đã chặn được nó. Bản ghi cho bạn biết liệu đã có ai ngoài thực địa chạm đến ranh giới đó chưa, tác hại là gì và liệu biện pháp kiểm soát có đứng vững ở những nơi khác không. Một phát hiện không có tiền lệ thực địa là một giả thuyết đáng để khắc phục; một sự cố thực địa không có phát hiện tái lập được là một lỗi bạn chưa thể đóng lại. Những nhóm làm đúng sẽ ngừng coi "chúng tôi đã red-team mô hình" là sản phẩm bàn giao và bắt đầu coi đó là một đầu vào cho sổ cái của chính họ.

Điều còn lại là lời kết trung thực. Red teaming AI không tạo ra bảo đảm an ninh, và bất kỳ dịch vụ tư vấn nào được bán như một bảo đảm như vậy đều là đang bán sai thứ. Nó tạo ra một tập hợp các ranh giới mà bạn giờ đã biết là bị vượt qua, cùng bằng chứng có thể chạy lại, được sắp xếp theo điều gì xảy ra khi chúng bị vượt qua. Thế là đủ để đưa ra quyết định — và nhiều hơn hẳn một bộ slide.