Đi đến nội dung chính
Quay lại bài viết

3 tháng 8, 2026

Bảo mật Agentic AI sau Project Perception: quản trị trước khi hành động

Project Perception đưa bảo mật Agentic AI từ cảnh báo đến hành động. Xem cẩm nang về cổng phê duyệt, đặc quyền tối thiểu, rollback, nhật ký kiểm toán và đánh giá.

Bởi Tran Tien Van15 phút đọc

Trọng tâm bài viết

Project Perception biến bảo mật Agentic AI thành vấn đề vận hành, không phải thêm một câu chuyện về cảnh báo. Điều này quan trọng với các đội kỹ thuật, bảo mật và nền tảng xây dựng hoặc phòng thủ bằng AI agent.

Project Perception biến bảo mật Agentic AI thành vấn đề vận hành, không phải thêm một câu chuyện về cảnh báo. Điều này quan trọng với các đội kỹ thuật, bảo mật và nền tảng xây dựng hoặc phòng thủ bằng AI agent. Các cuộc tấn công ở tốc độ máy có thể vượt phản ứng ở tốc độ con người, trong khi agent chỉ cảnh báo để mọi bản sửa chữa cho các nhà phân tích vốn đã quá tải. Hướng dẫn này cung cấp cẩm nang quản trị và rollout cho các agent có hành động: cổng phê duyệt, quyền truy cập theo phạm vi, triển khai theo giai đoạn, rollback và bằng chứng kiểm toán. Tại Van Data Team, chúng tôi vận hành hóa sự chuyển dịch đó qua workflow AI agent production, nơi ánh xạ quyền hạn, cổng kiểm duyệt và phục hồi trước khi có quyền ghi.

Project Perception hiện ở giai đoạn public preview. Microsoft nêu rõ sự chuyển dịch vận hành trong thông báo ngày 27 tháng 7 năm 2026, đặt public preview vào ngày 3 tháng 8 năm 2026 và mô tả mô phỏng tấn công, điều tra mối đe dọa và khắc phục lỗ hổng:

"Đó sẽ là khả năng liên tục nhận biết, suy luận và hành động của họ."

Bài viết này tách biệt các dữ kiện Microsoft công bố với khuyến nghị vận hành của Van Data Team. Nội dung tập trung vào kiến trúc và quản trị phòng thủ, không hướng dẫn khai thác.

Điểm chính cần nhớ

Bài học vận hành từ Project Perception là quyền hành động cần kiểm soát mạnh hơn quyền cảnh báo. Các kiểm soát sau tạo thành nền tảng thực tế.

  • Project Perception kết nối lập bản đồ rủi ro, điều tra và hành động khắc phục trong một vòng lặp đa agent được điều phối.
  • Mẫu có thể tái sử dụng tách biệt việc tạo bằng chứng, phán đoán rủi ro và thực thi có kiểm soát.
  • Thay đổi có tác động cao cần phê duyệt của con người, rollout theo giai đoạn, rollback tự động, đặc quyền tối thiểu và nhật ký chống sửa đổi.
  • Benchmark tốt không chứng minh an toàn production; các đội cũng cần đánh giá hồi quy, tuân thủ chính sách, phục hồi, chi phí, độ trễ và chất lượng dữ liệu.

Project Perception thay đổi bảo mật Agentic AI như thế nào

Project Perception thay đổi vận hành bảo mật bằng cách liên kết mô phỏng tấn công, điều tra mối đe dọa và hành động khắc phục trong một hệ thống agent được điều phối. Nó chuyển workflow từ tạo cảnh báo sang thực thi được quản lý.

Thông tin được công bố: Project Perception vượt ra ngoài cảnh báo

Microsoft mô tả Project Perception như một lực lượng gồm các agent chuyên biệt suy luận trên dữ liệu, công cụ và workflow bảo mật. Các agent bộc lộ khoảng trống, điều tra mối đe dọa và khắc phục chúng. Nền tảng vẫn là public preview, vì vậy các đội nên đánh giá kiểm soát của nó trước khi giao thẩm quyền production.

Theo thông báo mô hình của Microsoft AI, MAI-Cyber-1-Flash là mô hình bảo mật đầu tiên do Microsoft tự huấn luyện. Mô hình được thiết kế để tìm các lỗ hổng khó trong mã phức tạp và chạy trong MDASH. Microsoft cho biết MDASH điều phối hơn 100 agent chuyên biệt trên các mô hình frontier và distilled. Harness này đã tìm thấy lỗ hổng trong codebase của Microsoft và đạt khoảng 96% trên CyberGym, cao hơn khoảng 12 điểm phần trăm so với cấu hình dựa trên Mythos.

Theo trang sản phẩm Project Perception, nền tảng bắt đầu với các agent Red, Blue và Green. Red lập bản đồ đường tấn công và lỗ hổng. Blue điều tra phát hiện và xác định rủi ro có ý nghĩa, còn Green viết và triển khai bản vá, đồng thời củng cố phòng thủ.

Trang sản phẩm cũng nói hành động có tác động cao vẫn cần con người ký duyệt. Ranh giới này quan trọng khi diễn giải từ "tự động". Cột cuối dưới đây là mô hình kiểm soát do Van Data Team khuyến nghị, không phải tuyên bố về sản phẩm Microsoft.

Vai trò agentChức năng được công bố

Ranh giới kiểm soát khuyến nghị

Red

Lập bản đồ đường tấn công và lỗ hổng

Tạo bằng chứng nhưng không thể phê duyệt khắc phục

Blue

Điều tra phát hiện, lọc nhiễu và xác định rủi ro có ý nghĩa

Áp dụng phán đoán rủi ro và chính sách nhưng không thể triển khai

Green

Viết và triển khai bản vá, đồng thời củng cố phòng thủ

Thực thi phạm vi đã phê duyệt nhưng không thể mở rộng quyền hạn

Bài học có thể tái sử dụng không phải là cách đặt tên theo màu. Đó là sự phân tách nhiệm vụ giữa phát hiện, phán đoán và hành động. Các đội thiết kế ranh giới thẩm quyền tương tự có thể dùng hướng dẫn về AI agent có kiểm duyệt của con người làm mẫu bổ trợ. Hướng dẫn này chỉ ra nơi nên đặt cổng kiểm duyệt khi agent có thể thay đổi hệ thống bên ngoài.

Red, Blue và Green tạo thành vòng kiểm soát an toàn hơn

Sự phân tách Red, Blue và Green chỉ cải thiện kiểm soát khi không agent nào có thể tạo bằng chứng, phê duyệt ý nghĩa của nó và tự ủy quyền thay đổi. Vòng lặp thất bại khi các thẩm quyền đó gộp vào cùng một vai trò.

Phân tích của Van Data Team: tách bằng chứng, phán đoán và thực thi

Minh họa sau tóm tắt việc không có đường đi trực tiếp từ phát hiện đến production:

Workflow bảo mật Agentic AI tách bằng chứng Red, xác thực rủi ro Blue, phê duyệt của con người và khắc phục Green với rollback.

Hình 1. Vòng lặp bảo mật Agentic AI an toàn tách biệt bằng chứng, phán đoán, ủy quyền và thực thi, đồng thời giữ đường quay về trạng thái lành mạnh gần nhất.

Hãy xem Red là bên tạo bằng chứng, Blue là ranh giới rủi ro và chính sách, còn Green là bên thực thi được kiểm soát. Một phát hiện của Red không bao giờ được kích hoạt hành động Green trực tiếp. Blue nên kiểm tra độc lập liệu bằng chứng có liên quan, còn mới và nằm trong chính sách hay không.

Một bàn giao Blue hữu ích gồm bằng chứng nguồn, độ tin cậy, tài sản bị ảnh hưởng, phạm vi đề xuất, quyền sở hữu tài sản và trạng thái chuyển cấp. Nó cũng nên ghi lại bất đồng đáng kể giữa các agent. Green nên từ chối tác vụ khi bàn giao không đầy đủ hoặc xung đột với chính sách.

Hãy xem một phát hiện giả định ở dịch vụ danh tính. Red lập bản đồ mức phơi lộ có thể có, trong khi Blue kiểm tra phiên bản đã triển khai, khả năng truy cập, chủ sở hữu và độ mới telemetry. Nếu rủi ro có ý nghĩa, Green mở bản vá trong branch và xác thực riêng biệt. Chủ sở hữu dịch vụ phê duyệt rollout có giới hạn, còn các tín hiệu sức khỏe quyết định thay đổi được mở rộng hay rollback.

Thiết kế này giới hạn thất bại tương quan. Agent tự tin tìm thấy điểm yếu vẫn có thể hiểu sai ngữ cảnh kinh doanh hoặc phụ thuộc triển khai. Phân loại độc lập tạo vị trí để bắt lỗi đó trước khi chạm production.

Quy mô điều phối của MDASH cũng khiến kỷ luật runtime trở nên không thể tránh khỏi. Chi phí, độ trễ, ngân sách token, khả năng quan sát và đánh giá trở thành ràng buộc thiết kế hàng đầu. Hãy trace mọi lệnh gọi công cụ và bàn giao, giới hạn retry, xác định cách giải quyết xung đột và đo toàn bộ workflow thay vì một agent riêng lẻ.

Quản trị khả năng tự động khắc phục trước khi cấp quyền production

Các agent có khả năng hành động nên nhận thẩm quyền production theo từng giai đoạn, chỉ được cấp quyền rộng hơn sau khi bằng chứng cho thấy hành vi bị giới hạn và có thể đảo ngược. Lộ trình quyền hạn nên mở rộng chậm hơn năng lực kỹ thuật của agent.

Phân tích của Van Data Team: phân loại hành động trước khi cấp quyền

Phân loại từng hành động theo khả năng đảo ngược, phụ thuộc bị ảnh hưởng, độ nhạy dữ liệu, đặc quyền cần thiết và bán kính ảnh hưởng vận hành. Mặc định nên là thẩm quyền ít nguy hiểm nhất nhưng vẫn tạo được bằng chứng hữu ích.

Một tiến trình an toàn theo chuỗi dưới đây. Mỗi giai đoạn bổ sung bằng chứng trước khi bổ sung thẩm quyền.

  • Đọc và điều tra trong các tài sản đã phê duyệt
  • Đề xuất bản vá trong branch hoặc pull request
  • Xác thực thay đổi trong môi trường cô lập
  • Triển khai vào lát production có giới hạn sau phê duyệt cần thiết
  • Chỉ mở rộng khi tín hiệu sức khỏe và cổng hồi quy đạt yêu cầu

Hãy dùng checklist quản trị và cổng phê duyệt này làm hiện vật triển khai ban đầu. Điều chỉnh chủ sở hữu và ngưỡng theo các dịch vụ đang được bảo vệ.

CổngMặc định khuyến nghị

Bằng chứng cần có trước hành động

Điều kiện chặn hoặc rollback

Danh tính agent

Danh tính workload riêng với đặc quyền tối thiểu và thông tin xác thực ngắn hạn

Tài nguyên, hành động, môi trường, chủ sở hữu và thời hạn đã phê duyệt

Từ chối và chuyển cấp mọi sai lệch phạm vi

Tin cậy đầu vào

Chỉ telemetry, code và nguồn tài sản được phê duyệt

Độ mới, lineage, quyền sở hữu và trạng thái SLA

Dừng khi bằng chứng cũ, không đầy đủ hoặc không thể trace

Tách biệt rủi ro

Lập bản đồ không thể ủy quyền khắc phục

Phân loại độc lập, tài sản bị ảnh hưởng, độ tin cậy và kết quả chính sách

Dừng khi rủi ro chưa xác minh hoặc agent bất đồng đáng kể

Tạo bản vá

Mặc định dùng branch hoặc pull request

Lý do, diff, kiểm thử, tác động phụ thuộc và bằng chứng nguồn

Từ chối khi kiểm thử hoặc kiểm tra chính sách thất bại

Xác thực cô lập

Môi trường không phải production trước production

Kết quả hồi quy, kiểm tra bảo mật, tín hiệu sức khỏe và kiểm thử rollback

Revert và chuyển cấp khi có hành vi không mong đợi

Phê duyệt production

Con người ký duyệt thay đổi có bán kính ảnh hưởng lớn

Lớp rủi ro, chủ sở hữu chịu trách nhiệm, phạm vi rollout và kế hoạch phục hồi

Chặn khi thiếu phê duyệt hoặc sẵn sàng rollback

Rollout theo giai đoạn

Lát production hữu ích nhỏ nhất

Baseline, sức khỏe canary, tín hiệu lỗi và tiêu chí mở rộng

Rollback khi ngưỡng được phê duyệt thất bại

Hồ sơ kiểm toán

Nhật ký chống sửa đổi ngoài quyền ghi của agent

Danh tính, bằng chứng, phiên bản, công cụ, phê duyệt, thay đổi và kết quả

Chặn khi trace không được ghi lại

Sự phê duyệt của con người thuộc về nơi một sai sót có thể lan rộng hoặc khó phục hồi. Thay đổi danh tính, truy cập dữ liệu nhạy cảm, migration không thể đảo ngược và thay đổi xuyên dịch vụ nên đến chủ sở hữu dịch vụ hoặc bảo mật chịu trách nhiệm. Tự động hóa bị giới hạn bởi chính sách phù hợp với hành động có thể đảo ngược, phạm vi hẹp, giám sát đáng tin cậy và rollback đã thử nghiệm.

Agent không bao giờ được tự mở rộng quyền để hoàn thành tác vụ. Quản lý quyền nên nằm sau một đường danh tính và phê duyệt riêng. Điều này ngăn việc khắc phục bị chặn trở thành lối đi vòng qua ủy quyền.

Rollback là một phần của hợp đồng hành động, không phải bước dọn dẹp. Ghi lại baseline trước thay đổi, xác định ngưỡng sức khỏe, kiểm thử đường revert và triển khai theo giai đoạn. Nếu một ngưỡng thất bại, hệ thống nên rollback tự động và chuyển cấp kèm trace đầy đủ.

Giữ hồ sơ kiểm toán ngoài quyền ghi của agent. Ghi lại danh tính thực hiện, bằng chứng, phiên bản mô hình và chính sách, lệnh gọi công cụ, thay đổi đề xuất, người phê duyệt, diff kết quả, tín hiệu sức khỏe và kết quả rollback. Hồ sơ đó phải hỗ trợ replay và rà soát sau sự cố.

Xem AI Agent bảo mật tự động như danh tính zero trust

AI agent bảo mật tự động là một danh tính workload có quyền theo phạm vi, không phải người nội bộ đáng tin cậy với truy cập rộng. Quyền truy cập của nó nên hết hạn, có thể quy trách nhiệm và dừng ở các ranh giới tài nguyên rõ ràng.

Giới hạn danh tính, quyền và thời gian

Cấp cho từng vai trò một danh tính riêng. Cấp quyền đối với tài nguyên, hành động và môi trường được nêu tên, sau đó phát hành thông tin xác thực ngắn hạn cho tác vụ đã phê duyệt. Tách quyền đọc code, ghi bản vá, merge, triển khai và quản lý quyền.

Từ chối các yêu cầu ngoài phạm vi đã khai báo và chuyển chúng đi rà soát. Quy tắc này áp dụng dù công cụ đến qua function calling native, MCP server, CI runner hay cloud API. Mỗi công cụ là một bề mặt thẩm quyền.

Xem chất lượng dữ liệu là một phần của ranh giới bảo mật

Agent có thể đưa ra quyết định sai khi telemetry không đầy đủ, cũ hoặc tách rời khỏi quyền sở hữu. Yêu cầu trạng thái độ mới, lineage nguồn, quyền sở hữu tài sản và ngữ cảnh service-level agreement đi cùng mọi phát hiện.

Nền tảng kỹ thuật data pipeline trưởng thành rất quan trọng vì agent không thể suy luận an toàn trên telemetry mà không ai tin cậy. Workflow nên dừng khi tín hiệu cần thiết đến muộn, mâu thuẫn hoặc không thể trace. "Không hành động" là kết quả đúng khi hợp đồng bằng chứng thất bại.

Chọn framework không thay thế kiểm soát vận hành

LangGraph, LangChain, CrewAI, function calling native, Model Context Protocol (MCP) và Plan-and-Execute có thể triển khai sự tách biệt vai trò tương tự. Chúng có thể mô hình hóa trạng thái, định tuyến lệnh gọi công cụ và tạm dừng để kiểm duyệt. Chúng không cung cấp chính sách danh tính, thiết kế rollback hay mô hình trách nhiệm của bạn.

Tại Van Data Team, chúng tôi xem chi phí trên mỗi workflow hoàn thành, độ trễ đầu cuối, ngân sách token, độ đầy đủ trace và kết quả đánh giá là tiêu chí chấp nhận. Workflow nghiên cứu đa agent của chúng tôi cho thấy mẫu điều phối liền kề ở lĩnh vực khác. Bảo mật nâng mức đặt cược về quyền hạn và phục hồi, nhưng các khía cạnh vận hành vẫn giữ nguyên.

Đánh giá khả năng tự động khắc phục vượt ra ngoài điểm benchmark

CyberGym cung cấp bằng chứng về việc tạo exploit trên các lỗ hổng đã biết, nhưng không xác lập khả năng tự động khắc phục an toàn trong production. Niềm tin production cần một bộ hồi quy và quản trị rộng hơn.

Theo SecurityWeek, CyberGym đo liệu mô hình có thể tạo proof-of-concept khai thác hoạt động cho các lỗ hổng phần mềm đã biết hay không. Cấu hình MAI-Cyber-1-Flash cùng GPT-5.4 đạt khoảng 95,95% trên benchmark đó. Cùng bài đưa tin cho biết tiết kiệm chi phí khoảng 50% so với cấu hình MDASH đang có mặt trên thị trường.

Đây là các kết quả hẹp, theo từng cấu hình. Điểm CyberGym được công bố không đo phân loại an toàn, tính đúng đắn bản vá, chất lượng phê duyệt, mối đe dọa chưa biết hay phục hồi production. Kết quả chi phí không bảo đảm cho workload, chính sách định tuyến mô hình hoặc môi trường bảo mật khác.

Bộ hồi quy production nên kiểm thử cả chất lượng tác vụ và tính toàn vẹn kiểm soát. Phạm vi nên gồm:

  • Chất lượng quyết định: mức độ liên quan của phát hiện, dương tính giả và bất đồng đáng kể giữa agent
  • An toàn thay đổi: tính đúng đắn bản vá, tác động phụ thuộc và rủi ro hồi quy
  • Quản trị: tuân thủ chính sách, thực thi phê duyệt và các lần thử hành động trái phép
  • Phục hồi: rollback thành công, hành vi chuyển cấp và khoanh vùng thất bại
  • Runtime: lỗi công cụ, lỗi bàn giao, chi phí, độ trễ, mức dùng token và trần retry
  • Bằng chứng: độ đầy đủ trace, độ mới telemetry, lineage và quyền sở hữu tài sản

Chạy lại bộ này bất cứ khi nào mô hình, prompt, công cụ, chính sách, quyền, phụ thuộc hoặc dữ liệu nguồn thay đổi. So sánh ứng viên với baseline cố định và chặn triển khai khi cổng an toàn suy giảm. Lưu hiện vật đánh giá cạnh trace hành động.

Trong một rollout giả định, agent có thể trước hết sửa phụ thuộc không phải production và vượt qua mọi kiểm thử bắt buộc. Sau đó nó đề xuất canary có giới hạn thay vì thay đổi toàn bộ fleet. Nếu tín hiệu lỗi hoặc độ trễ xấu đi, nền tảng revert và chuyển cấp. Quyền tự động rộng hơn đến từ bằng chứng lặp lại, không phải cấu hình ban đầu.

Với các kiểm soát runtime xung quanh, hãy dùng cẩm nang vận hành AI agent và chuyển cấp cho con người để xác định quyền sở hữu, giám sát và bàn giao sự cố. Nó bổ trợ cho bộ hồi quy ở trên.

Bài toán khó nhất là hành động có kiểm soát

Project Perception làm rõ quá trình chuyển từ cảnh báo sang hành động: các agent bảo mật có thể lập bản đồ rủi ro, phán đoán phát hiện và tạo thay đổi khắc phục. Bài học vận hành cho bảo mật Agentic AI là năng lực và thẩm quyền phải được thiết kế riêng.

Bắt đầu với danh tính riêng biệt, điều tra chỉ đọc, đề xuất bản vá, xác thực cô lập, cổng do con người quyết định, rollout có giới hạn, rollback tự động và nhật ký chống sửa đổi. Yêu cầu bằng chứng hồi quy sau các thay đổi đối với mô hình, prompt, công cụ, chính sách, quyền hoặc telemetry. Chỉ giảm mức kiểm duyệt khi hành vi đo lường được chứng minh điều đó.

Van Data Team có thể biến mẫu này thành workflow rà soát rủi ro theo phạm vi. Một phiên rà soát phạm vi security agent có thể tạo bản đồ tín hiệu và quyền, ma trận phê duyệt, kế hoạch đánh giá và phạm vi cung cấp theo giai đoạn. Mục tiêu không phải là quyền tự động tối đa. Đó là hành động có kiểm soát mà chủ sở hữu kỹ thuật và bảo mật có thể quan sát, dừng, phục hồi và giải thích.

Câu hỏi thường gặp

Những câu hỏi người đọc thường đặt ra tiếp theo.

Các câu trả lời ngắn này làm rõ những câu hỏi thực tế thường xuất hiện sau khi đọc bài viết.

Bạn cần một hệ thống tương tự?

Nếu bài viết này phản ánh một quy trình đội ngũ bạn đang vận hành, bước tiếp theo thường là rà soát có phạm vi về hệ thống, ràng buộc và lộ trình triển khai.

Đặt lịch rà soát quy trình miễn phí tại đây.