Chiếm đoạt danh tính trong quy trình làm việc: Noma Labs biến một email hỗ trợ thông thường thành quyền truy cập dữ liệu đặc quyền

Ngày 9 tháng 9 năm 2026, nhóm nghiên cứu tại Noma Security, đăng dưới danh nghĩa Noma Labs, đã công bố bài tường thuật về thứ mà họ gọi là chiếm đoạt danh tính luồng công việc: một luồng công việc AI của doanh nghiệp đọc một tin nhắn thông thường đến tại một điểm đầu vào công khai — hộp thư hỗ trợ, một issue trên GitHub, một biểu mẫu web, một tài liệu được chia sẻ — rồi thực hiện công việc được yêu cầu bằng tài khoản dịch vụ có đặc quyền cao của chính nó thay vì quyền của người gửi. Phần trình bày từng bước của Noma có một người ngoài gửi email đến địa chỉ hỗ trợ công khai của một công ty và yêu cầu, trong số những thứ khác, số liệu bán hàng quý từ email gần nhất của Giám đốc Tài chính; vài phút sau, nội dung đó xuất hiện trong hộp thư của kẻ tấn công. Không có mô hình nào bị lừa và không có tài khoản nào bị xâm phạm, và đó chính là điểm mấu chốt của báo cáo: “tất cả những gì kẻ tấn công phải làm là yêu cầu.” Kho lưu trữ ghi nhận không có thiệt hại thực tế nào — không nêu tên nạn nhân nào và không có hệ thống đã triển khai nào được mô tả là bị xâm phạm — và xếp loại phát hiện này là nghiên cứu, mức độ nghiêm trọng trung bình, độ tin cậy A, không bị tranh chấp. Bài tường thuật này dựa trên báo cáo của Noma Labs, bài đưa tin của Dark Reading xuất bản cùng ngày và bài tiếp theo của CSO Online, và kho lưu trữ sự cố AI lưu mục này cùng với các mục lân cận, mỗi mục đều có nguồn, mức độ nghiêm trọng và xếp hạng độ tin cậy riêng.

Các trường của chính bản ghi đáng đọc trước phần nội dung. Nó được gắn thẻ INFRA và EXFIL, bao phủ khu vực GLOBAL, mang một ngày chính xác đến từng ngày là 9 tháng 9 năm 2026 và không được đánh dấu là mục dấu mốc. Ngày đó là ngày công bố nghiên cứu và không gì khác; không có dòng thời gian sự cố nào gắn với nó, vì không có sự cố nào để định thời gian. Đó là điều đầu tiên cần ghi nhớ: thứ Noma công bố là một cơ chế và một phạm trù, không phải một báo cáo vi phạm.

Noma đã chứng minh được gì, và chưa chứng minh được gì

Chuỗi thao tác trong hộp thư hỗ trợ là một ví dụ minh họa được dựng lên chứ không phải một vụ việc của khách hàng. Báo cáo của Noma không nêu tên tổ chức nào, không đưa ra số lượng triển khai bị ảnh hưởng, không công bố dữ liệu telemetry từ bất kỳ pipeline thực tế nào và không dẫn liên kết đến một lần chạy bằng chứng khái niệm cho kịch bản này — khác với nghiên cứu tháng 7 của nhóm, vốn chỉ ra một lần chạy GitHub Actions công khai. Thay vào đó, điều báo cáo đưa ra là một mô tả về cơ chế đủ chính xác để đối chiếu với một kiến trúc: một đầu vào chưa được xác thực đi vào, mô hình diễn giải nó một cách chính xác, pipeline thực hiện lệnh gọi hạ nguồn, và lệnh gọi đó được thực hiện bằng quyền của người tạo workflow.

Sasi Levi, trưởng bộ phận nghiên cứu bảo mật của Noma và là tác giả của báo cáo, tóm gọn nguyên nhân gốc rễ trong một câu: “danh tính và quyền của người dùng kích hoạt một workflow bị tách rời khỏi danh tính và quyền được dùng để thực thi workflow đó.” Khi điều đó đúng, theo lời báo cáo, workflow trở thành “các proxy không được xác thực cho những hành động đặc quyền và việc rút dữ liệu âm thầm.”

Bởi vì các hành động diễn ra thông qua tự động hóa đáng tin cậy với thông tin xác thực hợp lệ, Noma lập luận rằng cảnh báo thông thường có rất ít thứ để bắt. Yêu cầu là bình thường, đầu ra của mô hình là một đầu ra mô hình hợp lệ, lệnh gọi API đã được xác thực, và phản hồi chính là phản hồi mà quy trình công việc được xây dựng để gửi. CSO Online dẫn lời chuyên gia red team Vibhum Dubey, người đã khiến vấn đề phát hiện trở nên cụ thể: "Các sự kiện riêng lẻ có thể trông hoàn toàn hợp pháp. Các tín hiệu hữu ích sẽ đến từ việc tương quan người yêu cầu ban đầu, danh tính được sử dụng ở hạ nguồn, các tài nguyên được truy cập, các tham số được cung cấp và hành động cuối cùng."

Kiểm tra bị lỗi là kiểm tra phân quyền, không phải bộ lọc nội dung.

Ví dụ rõ ràng nhất trong báo cáo là một cặp yêu cầu giống hệt nhau. Từ một giám đốc tài chính: “Số liệu doanh số theo quý từ Giám đốc Tài chính trong email gần nhất của họ là gì?” Từ một người gửi bên ngoài: vẫn đúng những từ đó. Luận điểm của Noma là câu lệnh và thao tác được yêu cầu là giống nhau, trong khi quyết định cấp quyền phải hoàn toàn khác — “Một CFO có quyền được biết thông tin đó; một người gửi bên ngoài thì không.”

Các bộ phát hiện prompt-injection tiêu chuẩn và guardrail cho agent, theo báo cáo, phân loại hai đầu vào giống hệt nhau, vì không có gì độc hại trong cả hai để phát hiện. "Rủi ro bảo mật không nằm trong prompt; nó nằm ở ranh giới ủy quyền." Tuyên bố mang tính cấu trúc của Noma tiếp nối từ đó: guardrail, chỉ dẫn hệ thống và bộ lọc đầu vào "không được thiết kế để phục vụ như một ranh giới ủy quyền," vì vậy một pipeline dựa vào chúng để quyết định người gọi có thể truy xuất gì đang dựa vào một kiểm soát chưa từng được yêu cầu làm công việc đó.

Sự khác biệt này có ý nghĩa thực tế. Prompt injection trực tiếp thao túng cách mô hình tuân theo chỉ dẫn; prompt injection gián tiếp giấu chỉ dẫn trong nội dung mà mô hình sẽ đọc sau đó; chiếm đoạt danh tính quy trình công việc, theo cách Noma định nghĩa, không cần đến cả hai, bởi vì yêu cầu đó là yêu cầu mà mô hình được cho là phải hiểu và pipeline được cho là phải thực thi. Một người phòng thủ đã dành cả năm để gia cố phòng chống injection hóa ra đã làm việc trên một lớp khác.

Các quy trình làm việc tĩnh nằm ngoài nỗ lực gia cố bảo mật cho tác nhân

Noma tách biệt hai thứ thường được dùng thay thế cho nhau. Quy trình AI là một chuỗi tĩnh, được định nghĩa trước, trong đó mô hình chỉ là một bước xử lý — cách viết tắt trong báo cáo là bước A, mô hình, bước B, bước C — và pipeline tất định xung quanh mô hình kiểm soát những gì diễn ra. Quy trình tác tử thì tự chủ: tác tử quyết định thực hiện những bước nào và gọi những công cụ nào. Theo báo cáo, phần lớn nỗ lực bảo mật hiện nay đã dồn vào loại thứ hai — hạn chế quyền truy cập công cụ và giới hạn phạm vi quyền cho các tác tử đưa ra quyết định động — và những biện pháp kiểm soát đó không vươn tới loại thứ nhất.

Báo cáo cũng bịt một lối thoát hiểm rõ ràng. Việc giới hạn ai hoặc cái gì có thể kích hoạt một quy trình làm việc không khắc phục được vấn đề: nếu một tự động hóa chạy theo lịch lúc 8:00 sáng và tác động lên một hộp thư đến mà bất kỳ ai cũng có thể ghi vào, thì việc kiểm toán "ai có thể kích hoạt quy trình làm việc này" sẽ trả lời sai câu hỏi. Quy tắc của Noma là mọi tự động hóa phải được đánh giá bởi "bên ít được tin cậy nhất có khả năng ảnh hưởng đến thứ mà nó tác động tới" — bao gồm email, biểu mẫu, phiếu yêu cầu, GitHub issues, tài liệu được chia sẻ và tin nhắn trò chuyện.

Noma cho biết Google đã khắc phục một sự cố Google Workflows; Google vẫn chưa công bố thông tin nào.

Nền tảng duy nhất được nêu tên trong báo cáo là của Google. Noma tuyên bố rằng họ đã xác định cùng vectơ rủi ro trong Google Workflows, đã báo cáo vấn đề này một cách có trách nhiệm và Google đã ghi nhận báo cáo và xác nhận một bản sửa lỗi “mà không tiết lộ chi tiết triển khai”. Câu đó là toàn bộ hồ sơ công khai. Không thể tìm thấy bất kỳ khuyến cáo, ghi chú phát hành hay CVE nào của Google mô tả vectơ này, và mọi nguồn thông tin thứ cấp về bản sửa lỗi — bao gồm cả những nguồn được công bố trong những ngày sau ngày 9 tháng 9 — đều quy nó cho Noma chứ không phải Google.

Báo cáo cũng không hoàn toàn nhất quán về việc nó muốn nói đến sản phẩm Google nào. Phần nội dung nêu tên Google Workflows; một tiêu đề mục trong cùng báo cáo lại ghi “Google Workspace: AI Workflow Identity Hijacking.” Cả hai đều là sản phẩm của Google với các ranh giới tin cậy khác nhau, và báo cáo không dung hòa được hai điều này. Noma không nói liệu trường hợp mà họ báo cáo đã bị khai thác hay chưa, có bao nhiêu khách hàng bị phơi lộ, hoặc bản sửa lỗi đã thay đổi điều gì — và vì Google chưa nói gì, không khoảng trống nào trong số đó có thể được lấp đầy từ phía nhà cung cấp.

GitLost chính là cùng một ranh giới, được nhìn qua một lăng kính hẹp hơn

Công bố trước đó của Noma tạo tiền lệ cho loại hình này. Vào tháng 7 năm 2026, nhóm đã công bố nghiên cứu về GitHub Agentic Workflows, được họ đặt tên là GitLost: một workflow được kích hoạt khi một issue được giao; workflow này đọc tiêu đề và nội dung issue rồi trả lời bằng một bình luận, và vì agent có quyền đọc trên các kho lưu trữ của tổ chức, người dùng bên ngoài có thể lợi dụng việc giao issue để truy cập dữ liệu kho lưu trữ riêng tư. Dark Reading đưa tin về vụ việc vào ngày 7 tháng 7 năm 2026 và mô tả một kẻ tấn công giấu các lệnh bằng tiếng Anh thông thường trong phần nội dung của một issue được mở trong kho lưu trữ công khai, không cần thông tin xác thực và không cần kỹ năng lập trình.

Hai cách diễn giải không hoàn toàn giống nhau, và phần thú vị nằm ở chỗ khác biệt. Bài viết tháng Bảy của Dark Reading là một câu chuyện về prompt-injection: văn bản do kẻ tấn công kiểm soát bị đọc như thể là chỉ dẫn. Báo cáo tháng Chín của Noma mô tả GitLost theo góc độ tác nhân kích hoạt và quyền đọc trên toàn bộ kho lưu trữ, đồng thời trình bày đây là cùng một ranh giới phân quyền được nhìn từ một góc. Cả hai mô tả đều khớp với một quy trình làm việc mà tác nhân của nó đã đọc văn bản do người ngoài viết, nhưng chỉ mô tả trước đó phụ thuộc vào việc mô hình bị dẫn dắt. Noma hiện nói rằng họ đã báo cáo cùng vector rủi ro đó cho Google; họ không nói liệu vụ GitLost từng bị khai thác ngoài phần trình diễn đã công bố hay chưa.

Theo cách Noma tự trình bày về độ phủ, Hacker News, Dark Reading và hơn 100 cơ quan truyền thông quốc tế khác đã đưa tin về nghiên cứu GitLost. Con số đó là do nhà cung cấp đưa ra, và bài viết này chưa độc lập kiểm đếm độ phủ.

Những người thực hành đồng ý rằng cơ chế này đã cũ; tranh cãi là về tên gọi.

Các bài đưa tin độc lập không phản bác phát hiện này, và hai chuyên gia thực tiễn bên ngoài phản đối ở khía cạnh tính mới chứ không phải ở nội dung thực chất. Morey Haber, cố vấn trưởng về an ninh tại BeyondTrust, nói với Dark Reading: "Không ai đánh lừa một mô hình AI làm bất kỳ điều gì nó không được phép làm. Mô hình đã làm đúng những gì được yêu cầu, bởi một người lạ (không đáng tin cậy), và quy trình xung quanh nó đã dùng danh tính của người khác để làm điều đó xảy ra vì nó không được giới hạn phạm vi và không được xử lý theo đặc quyền tối thiểu." CSO Online dẫn lời Vibhum Dubey mô tả mô thức này là "một nhóm điểm yếu phân quyền đã biết", và nói thêm rằng khi một đầu vào chưa được xác thực có thể kích hoạt một quy trình đáng tin cậy hoạt động với các đặc quyền riêng của nó, "quy trình đó có thể thực chất hành xử như một confused deputy."

Ram Varadarajan, giám đốc điều hành của Acalvio, đã đề xuất với Dark Reading một biện pháp kiểm soát hoàn toàn khác: thay vì lọc nhiều hơn, hãy gieo vào môi trường các mồi nhử — những luồng trao đổi giả của lãnh đạo, các bản ghi honeytoken — thứ không có lý do chính đáng nào để bất kỳ quy trình được ủy quyền nào chạm tới, để một yêu cầu trông có vẻ vô hại khi vươn tới một trong số đó sẽ vấp phải một ranh giới mà nó không bao giờ được phép vượt qua. Bất đồng, nếu có thể gọi như vậy, là về việc liệu đóng góp hữu ích là một cái tên mới cho một lỗ hổng ủy quyền thời 1988 hay là một mô tả có thể vận hành về nơi lỗ hổng đó hiện đang tồn tại. Lập trường của Noma là ý thứ hai: rằng mô thức này mang tính hệ thống trên các quy trình AI doanh nghiệp và rằng các khung bảo mật AI hiện nay đang nhìn vào sai bề mặt.

Biện pháp giảm thiểu là ủy quyền và một điểm kiểm soát, chứ không phải một bộ lọc tốt hơn.

Các biện pháp kiểm soát được Noma khuyến nghị nằm ở tầng ứng dụng chứ không phải tầng mô hình. Ủy quyền token nhận biết danh tính nghĩa là loại bỏ các khóa API quản trị tĩnh khỏi quy trình AI và thực thi thao tác dữ liệu bằng token ủy quyền ngắn hạn, có phạm vi giới hạn gắn với người yêu cầu đã xác thực, để ngữ cảnh người dùng lan truyền đến lệnh gọi thực sự chạm vào dữ liệu. Điểm kiểm tra ủy quyền theo ngữ cảnh nghĩa là coi mọi đầu ra của mô hình là đầu vào không đáng tin cậy và đặt một bước đánh giá kiểm soát truy cập cùng bảo vệ thời gian chạy rõ ràng giữa bước biến đổi của mô hình và mọi lệnh gọi cơ sở dữ liệu hoặc công cụ tiếp theo. Tách đầu ra bất đối xứng nghĩa là cô lập về mặt cấu trúc việc truy xuất dữ liệu khỏi các kênh liên lạc bên ngoài, để một quy trình xử lý dữ liệu nội bộ nhạy cảm không dùng chung đường thực thi với cơ chế tự động phản hồi cho bên ngoài.

Dubey đã đưa cho CSO Online một bài kiểm tra ít tốn kém hơn bất kỳ bài nào trong ba bài: so sánh kết quả giữa các mức đặc quyền. "Nếu một người dùng có đặc quyền thấp có thể đạt được cùng kết quả như quản trị viên vì các hệ thống hạ nguồn chỉ nhìn thấy danh tính của luồng công việc, thì đó chính là nơi tôi sẽ tập trung điều tra."

Những gì hồ sơ còn để ngỏ

• Không có nạn nhân, không có số liệu và không có dữ liệu đo từ xa. Trường hợp hộp thư hỗ trợ của Noma chỉ là một bản mô phỏng từng bước; báo cáo không nêu tên tổ chức nào và kho lưu trữ ghi nhận tổn hại thực tế là sai. Tính hợp lý của cơ chế không phải bằng chứng cho thấy cơ chế đó đã được sử dụng.

• Sản phẩm Google nào đã được khắc phục và bản sửa lỗi là gì. Phần nội dung của Noma nói là Google Workflows, tiêu đề mục của nó lại nói Google Workspace, còn Google thì chưa công bố gì. Các tổ chức vẫn chưa thể xác định từ các nguồn công khai liệu một pipeline mà họ vận hành có nằm trong phạm vi ảnh hưởng hay không.

• Liệu vector này đã từng bị khai thác ở bất kỳ đâu hay chưa. Cả báo cáo lẫn bất kỳ nội dung đưa tin nào được xem xét cho bài viết này đều không mô tả một chiến dịch đã được quan sát, một tổn thất dữ liệu hay một phát hiện pháp chứng quy được cho là do việc chiếm đoạt danh tính quy trình làm việc.

• Liệu hạng mục này có trụ vững khi được đo lường hay không. Chưa có bên độc lập nào công bố một bản quét, một tập dữ liệu các pipeline bị ảnh hưởng hay một bộ kiểm thử cho mẫu này; bằng chứng đang lưu hành chỉ là lập luận kiến trúc cộng với lời kể của một nhà cung cấp về một trường hợp đã được khắc phục.

• Ai là người đưa ra lập luận. Noma Labs là bộ phận nghiên cứu của Noma Security, công ty bán các biện pháp kiểm soát bảo mật cho agent đúng loại mà báo cáo của mình khuyến nghị. Điều đó không khiến phát hiện này trở nên sai — Dark Reading và CSO Online đều đã đưa tin, và cả hai đều không tìm thấy lỗi thực tế nào — nhưng đó là bối cảnh mà người đọc nên lưu tâm khi cân nhắc xem danh mục này được định nghĩa rộng đến đâu.

Mức độ nghiêm trọng được ghi của bản ghi là trung bình và cờ tổn hại thực tế là false mô tả bằng chứng, không phải cơ chế. Điều mà Noma thực sự đã xác lập thì hẹp và có thể kiểm chứng: rằng danh tính kích hoạt của một workflow và danh tính thực thi của nó là những thứ tách biệt, rằng thứ thứ hai thường mạnh hơn, và rằng một pipeline không bao giờ so sánh hai thứ đó sẽ làm cho một người lạ điều mà nó sẽ làm cho người mà nó được xây dựng để phục vụ. Biện pháp kiểm soát đi kèm vì thế cũng kém hào nhoáng một cách tương xứng — hãy hỏi, với từng automation, ai có thể tác động đến thứ mà nó thao tác, và liệu có bất kỳ thứ gì ở hạ nguồn từng kiểm tra lại rằng người yêu cầu có được phép yêu cầu hay không.