Giải thích Blue Teaming AI: Ba lớp mà một biện pháp kiểm soát thực sự có thể nằm ở

Hỏi một đội bảo mật xem các rào chắn AI của họ nằm ở đâu và câu trả lời thường là một tài liệu chính sách, một lời nhắc hệ thống hoặc một tính năng của nhà cung cấp. Không thứ nào trong số đó là một biện pháp kiểm soát. Một biện pháp kiểm soát là thứ quyết định, tại thời điểm hành động, liệu hành động đó có xảy ra hay không — và với một tác nhân AI, chỉ có ba nơi có thể quyết định: mô hình, cổng vào phía trước nó và môi trường xung quanh nó. Mọi thứ một đội phòng thủ có thể thực sự hứa hẹn đều đến từ nơi thứ hai và thứ ba trong số đó. Đây là câu hỏi về tầng lớp, và nó đứng trước mọi quyết định khác của đội phòng thủ, bao gồm ghi log những gì và gọi cho ai. Đây cũng là lý do bằng chứng thực địa quan trọng: kho lưu trữ sự cố AI chứa 400 sự cố tác nhân từ 2024-12 đến 2026-10-17, và phần lớn trong số đó không phải là những câu chuyện về một mô hình hành xử tệ. Chúng là những câu chuyện về một triển khai không có tầng nào có thể nói không.

Blue teaming theo nghĩa AI là công việc triển khai các lớp đó, tinh chỉnh những gì chúng nhận biết và có sẵn một câu trả lời đã được tập dượt cho ngày một trong số chúng kích hoạt. Đây là công việc kém hào nhoáng, không tạo ra điểm số, và là nửa duy nhất trong cặp red-team/blue-team làm thay đổi con số rủi ro.

Một blue team thừa hưởng những gì, và không thừa hưởng những gì

Hoạt động blue team truyền thống dựa trên một loạt giả định mà các triển khai AI âm thầm phá vỡ. Nhật ký được cho là đầy đủ, vì mạng đã thấy mọi gói tin. Tài sản được cho là có thể liệt kê, vì ai đó đã phải cấp phát chúng. Hành vi được cho là tất định, vì một chương trình làm cùng một việc khi có cùng đầu vào. Không điều nào trong ba điều đó sống sót khi tiếp xúc với một agent.

Thay vào đó, thứ mà một blue team thừa hưởng là một hệ thống nơi những quyết định có hệ quả lớn nhất diễn ra bên trong một yêu cầu mà lớp mạng coi là lưu lượng HTTPS thông thường gửi đến một tên máy chủ. Prompt, ngữ cảnh được truy xuất, các lệnh gọi công cụ, kết quả hoàn tất — tất cả đều nằm trong phần thân yêu cầu, và nếu không ai bắt và phân tích phần thân đó, thì việc triển khai trên thực tế không được giám sát, bất kể vành đai bảo vệ tốt đến đâu. Do đó, nhiệm vụ đầu tiên của blue team không phải là phát hiện; mà là thiết lập một cảm biến. Không có khả năng quan sát ở cấp yêu cầu và cấp công cụ thì không có gì để phát hiện, và mọi biện pháp kiểm soát hạ nguồn đều chỉ là trang trí.

Ai thực sự có thể thực thi biện pháp kiểm soát

Khi đã có cảm biến, câu hỏi trở thành mỗi biện pháp kiểm soát được phép nằm ở đâu. Cách hữu ích để phác họa điều này là theo quyền sở hữu thay vì theo công nghệ, vì quyền sở hữu là thứ quyết định liệu một biện pháp kiểm soát có tồn tại qua bản phát hành tiếp theo hay không.

Lớp mô hình thuộc về bất kỳ ai đã huấn luyện nó. Bạn không cấu hình nó, bạn không thể nhìn vào bên trong nó, và hành vi của nó thay đổi khi nhà cung cấp phát hành một phiên bản mới — mà có thể là bất kỳ ngày thứ Ba nào. Điều bạn có thể làm là ghim một phiên bản và coi việc thay đổi phiên bản là một thay đổi đối với trạng thái rủi ro của bạn, đòi hỏi phải kiểm thử lại. Điều bạn không thể làm là tuyên bố có một biện pháp kiểm soát ở đây. "Mô hình từ chối các yêu cầu có hại" là một thuộc tính mà bạn đang dựa vào, chứ không phải một cơ chế mà bạn vận hành.

Lớp cổng vào là nơi mọi prompt và completion đều đi qua một thành phần do bạn sở hữu. Đây là nơi chứa các giới hạn ngân sách và tốc độ, nơi các danh sách cho phép và quyền sử dụng công cụ được thực thi, nơi việc ghi log yêu cầu và phản hồi hoàn chỉnh ngay từ khâu thiết kế, và nơi một yêu cầu có thể được viết lại, chặn hoặc định tuyến lại trước khi bất kỳ token nào bị tính phí. Các kiểm soát ở cổng vào cũng là những kiểm soát duy nhất vẫn gắn liền khi bạn thay đổi mô hình, điều này quan trọng hơn vẻ bề ngoài của nó: những đội nhóm đặt kiểm soát của mình vào prompt sẽ mất hoàn toàn chúng ngay ngày họ chuyển đổi.

Lớp môi trường là lớp hoàn toàn thuộc về bạn: thông tin xác thực và phạm vi của chúng, luồng ra mạng, quyền truy cập tệp, giới hạn sandbox về thời gian thực tế và chi phí. Đây cũng là nơi một lượt chạy bị xâm phạm gây ra thiệt hại. Một agent bị dụ dỗ thực hiện hành vi độc hại sẽ nguy hiểm đúng theo mức độ mà môi trường cho phép hành động đó vươn tới — và môi trường là nơi duy nhất mà "đặc quyền tối thiểu" là một thay đổi cấu hình chứ không phải một bài toán nghiên cứu.

Bài kiểm tra thực tế cho bất kỳ biện pháp kiểm soát AI được đề xuất nào là một câu hỏi: lớp nào trong ba lớp này thực thi nó? Nếu câu trả lời là lớp mô hình, thì biện pháp kiểm soát chỉ là một hy vọng. Nếu câu trả lời là "lời nhắc hệ thống", thì đó là một gợi ý bên trong lớp mô hình, còn tệ hơn cả một hy vọng vì nó đi kèm tài liệu tuyên bố ngược lại.

Phát hiện: nội dung mà một agent thực sự phát ra

Việc phát hiện đối với các agent vận hành trên một tập tín hiệu khác với việc phát hiện đối với con người. Không có bất thường đăng nhập nào để tương quan. Thay vào đó, thứ hiện có là một luồng yêu cầu với cấu trúc phong phú bất thường, và bốn nhóm tín hiệu đáng để cảnh báo.

• Khối lượng và hình dạng của các lệnh gọi công cụ. Một tác nhân đột nhiên gọi công cụ đọc tệp bốn mươi lần trong một tác vụ, hoặc chuỗi công cụ của nó thay đổi từ ba bước thành ba mươi bước, thì đáng để xem xét — không phải vì nó độc hại, mà vì phân phối đã thay đổi.

• Nguồn gốc nội dung tại ranh giới. Văn bản nào trong prompt đến từ người dùng, văn bản nào từ truy xuất, văn bản nào từ kết quả công cụ và văn bản nào từ bộ nhớ. Hầu hết việc phát hiện prompt-injection quy về việc "văn bản mang tính chỉ dẫn xuất hiện trong một kênh lẽ ra chỉ nên mang dữ liệu", và bạn không thể tính toán điều đó trừ khi cổng vào gắn nhãn nguồn gốc ngay khi dữ liệu đi vào.

• Ranh giới luồng ra và phạm vi.Yêu cầu tới các đích nằm ngoài danh sách cho phép, đọc các đường dẫn ngoài phạm vi, nỗ lực sử dụng thông tin xác thực ngoài dịch vụ dự định của chúng. Đây là những tín hiệu có độ chính xác cao và ít tốn kém, vì môi trường đã biết những gì được cho phép.

• Chi tiêu và độ trễ làm chỉ báo đại diện. Một vòng lặp chạy loạn và một sự xâm nhập đều trông giống như đường cong chi phí đang thay đổi độ dốc. Cảnh báo ngân sách là phương thức phát hiện kém hào nhoáng nhất trong ngăn xếp và thuộc nhóm nhanh hoàn vốn nhất.

Điều cố ý vắng mặt trong danh sách đó là một bộ phân loại được giao nhiệm vụ đánh giá liệu một phản hồi đầu ra có gây hại hay không. Đó là ý tưởng phát hiện mà các đội thường nghĩ tới đầu tiên và cũng là ý tưởng lỗi thời nhanh nhất: nó trôi dạt theo mô hình, nó có tỷ lệ dương tính giả khiến các chuyên viên phân tích của bạn quen với việc phớt lờ nó, và nó chẳng cho bạn thứ gì để đưa vào runbook.

Khoanh vùng: ba nút điều chỉnh giúp chặn đứng một lượt chạy hỏng

Việc kiểm soát phạm vi cho một agent đơn giản hơn vẻ ngoài của nó, vì ba nút điều chỉnh bao quát gần như mọi thứ. Ngân sách giới hạn số tiền một lần chạy có thể chi, qua đó giới hạn cả thiệt hại tài chính lẫn phạm vi tác động của một vòng lặp. Phạm vi giới hạn những gì một lần chạy có thể chạm tới — các công cụ được bật cho tác vụ đó, các đường dẫn, các tenant. Hộp cát giới hạn thời gian nó có thể chạy và những gì nó có thể tiếp cận trong khi chạy. Cả ba đều là cài đặt gateway hoặc môi trường, nói cách khác là chúng có thể được thực thi.

Nguyên tắc thiết kế thực sự quan trọng là phạm vi theo từng tác vụ chứ không phải phạm vi theo từng tác nhân. Một tác nhân có bộ quyền thường trực là tác nhân mà quyền hạn của nó sẽ tích tụ cho đến khi có người rà soát lại; một tác nhân nhận được thông tin xác thực giới hạn theo tác vụ trong suốt thời gian của một tác vụ thì có một ranh giới tự hết hạn. Cách thứ hai tốn nhiều công sức hơn để xây dựng và rẻ hơn nhiều để phòng vệ.

Đây cũng là nơi một gateway xứng đáng với tên gọi của nó. Các kiểm soát nằm ngay trước mọi lệnh gọi mô hình — lệnh gọi công cụ và MCP được đánh giá trước khi chạy, chính sách nội dung và việc che dấu dữ liệu cá nhân được áp dụng trước khi yêu cầu được tính phí — vẫn là những kiểm soát như cũ, bất kể mô hình phía sau là mô hình bạn dùng quý trước hay mô hình vừa ra mắt tuần trước. Sự liên tục đó mới chính là sản phẩm: không phải một bộ lọc tốt hơn, mà là một nơi để bộ lọc tồn tại mà không dịch chuyển khi mô hình thay đổi.

Khôi phục: phát lại, vá lỗi, kiểm thử lại

Việc khắc phục sự cố AI có một lợi thế so với khắc phục sự cố mạng: toàn bộ quá trình chạy thường được ghi lại. Câu lệnh, ngữ cảnh, lệnh gọi công cụ, kết quả hoàn thành, thời gian — nếu cổng đã ghi nhật ký những thứ đó, sự cố có thể được phát lại, một điểm khởi đầu vững chắc hơn hầu hết những gì điều tra số thường có được.

Replay phục vụ ba mục đích nối tiếp nhau. Nó xác lập điều thực sự đã xảy ra, thay vì điều mà bản ghi chép gợi ý là đã xảy ra sau khi vài người tóm tắt lại. Nó xác định cơ chế kiểm soát lẽ ra phải kích hoạt, tức là khác biệt giữa sửa một triệu chứng và sửa một ranh giới. Và nó tạo ra ca hồi quy: một đầu vào đã được ghi lại mà nay phải bị chặn, được chạy với cấu hình mới để chứng minh rằng nó thực sự bị chặn.

Bước vá lỗi là nơi các đội xanh thường nhắm sai mục tiêu nhất. Nếu phát hiện là hành vi của mô hình, thì mọi biện pháp giảm thiểu khả dụng đều nằm ngoài mô hình — thu hẹp phạm vi, một bộ lọc tại cổng, một quyền bị gỡ khỏi môi trường. Nếu phát hiện là hành vi của hệ thống, bản sửa nằm trong cấu hình và kiểm thử hồi quy thì rẻ. Dù theo hướng nào, kiểm thử lại không phải là tùy chọn, vì cả bản sửa lẫn phiên bản mô hình đều thay đổi, và một biện pháp kiểm soát đã được xác minh với bản dựng của tháng trước chỉ là một khẳng định về tháng trước.

Diễn tập ngày nó khai hỏa

Một runbook chưa từng được đọc dưới áp lực chỉ là tài liệu, không phải năng lực. Buổi diễn tập đáng giá thì hẹp và cụ thể: lấy một sự cố agent khả dĩ, đi xuyên suốt từ đầu đến cuối, và bấm giờ từng bước. Ai nhận ra? Mất bao lâu cho đến khi có người nhìn đúng dòng log? Ai có thể dừng quy trình — một người được nêu tên, hay một hội đồng? Ai có thể thu hồi thông tin xác thực, và việc thu hồi mất bao lâu để lan truyền? Ai quyết định có thông báo cho bất kỳ ai bên ngoài công ty hay không?

Hai trong số những câu hỏi đó luôn khiến các đội bị vướng. “Ai có thể dừng lượt chạy” thất bại khi việc dừng đòi hỏi một người đang ngủ, vì vậy câu trả lời cần là một cơ chế chứ không phải một con người — một giới hạn ngân sách hoặc một công tắc dừng khẩn cấp mà một kỹ sư trực ca có thể tự kích hoạt. “Việc thu hồi mất bao lâu” thất bại vì thông tin xác thực thường được lưu đệm trong các thành phần không có trong sơ đồ.

Đọc kho lưu trữ là hình thức diễn tập rẻ nhất hiện có, vì nó cho phép bạn kế thừa cấu trúc sự cố của người khác thay vì tự phát minh ra cấu trúc của riêng mình. Hãy lấy một vài mục giống với triển khai của bạn, và với mỗi mục, hãy đặt ba câu hỏi ở trên. Những mục mà bạn không thể trả lời chúng chính là những lỗ hổng trong runbook của bạn, và bạn đã tìm ra chúng trước sự cố thay vì sau đó.

Sự bất đối xứng đáng được nói thẳng thắn.

Red teaming và blue teaming không phải là những hoạt động đối xứng và không nên được phân bổ ngân sách như thể chúng đối xứng. Một đợt red team bị giới hạn bởi lịch trình và tạo ra một tập hợp các phát hiện sẽ suy giảm khi mục tiêu thay đổi. Các biện pháp kiểm soát của blue team tồn tại lâu dài, tích lũy và là thứ duy nhất thực sự đứng giữa một đầu vào xấu và một kết quả xấu. Một lần triển khai có thể tìm ra một ranh giới; chỉ phía còn lại mới có thể giữ được nó.

Điều đó khiến tiêu chuẩn trung thực dành cho blue team trở nên không hào nhoáng và có thể kiểm chứng. Với mỗi biện pháp kiểm soát bạn tuyên bố, bạn phải có khả năng gọi tên lớp thực thi nó, dòng log chứng minh nó đã kích hoạt, cảnh báo cho bạn biết khi nó không kích hoạt, và người có thể tắt quá trình chạy. Bốn câu. Nếu thiếu một trong số đó, biện pháp kiểm soát chỉ là một tài liệu chính sách, mà tài liệu chính sách thì không đọc nội dung yêu cầu.