Làn sóng lo ngại đầu tiên về AI trong doanh nghiệp khá đơn giản: đó chỉ là việc nhân viên dán dữ liệu nhạy cảm vào các công cụ AI công cộng. Các nhóm bảo mật đã phản ứng bằng các chính sách sử dụng, chặn tên miền và các quy tắc ngăn chặn mất dữ liệu (DLP). Phản ứng đó hoàn toàn hợp lý vào thời điểm bấy giờ.
Nhưng giờ đây, nó không còn phù hợp với vấn đề thực tế nữa.
Shadow AI đã chuyển dịch từ mối lo ngại về rò rỉ dữ liệu sang vấn đề Access Control (kiểm soát quyền truy cập). Mối đe dọa không còn nằm ở những gì nhân viên nhập vào các công cụ AI. Thay vào đó, nó nằm ở việc các AI agent nào đang chạy bên trong tổ chức, chúng được kết nối với hệ thống doanh nghiệp nào và chúng được phép (hoặc không được phép) thực hiện những hành động gì.
Từ các công cụ thụ động đến các tác nhân chủ động
Nhân viên và các đơn vị kinh doanh đang xây dựng các AI agent với tốc độ mà hầu hết các nhóm bảo mật không thể theo kịp. Các trợ lý tùy chỉnh, agent lập trình, tự động hóa quy trình làm việc và các ứng dụng mang tính tác nhân (agentic applications) đang được tạo ra ở khắp các bộ phận. Một số nằm trên các nền tảng được phê duyệt, nhưng nhiều ứng dụng khác lại thông qua các tiện ích mở rộng trình duyệt (browser extensions), tính năng SaaS-native, công cụ dành cho nhà phát triển, MCP servers, agent dựa trên điểm cuối (endpoint-based agents) và các tập lệnh tùy chỉnh. Nhiều ứng dụng bắt đầu như những thử nghiệm nhanh, nhưng chỉ trong vài ngày, một số đã trở nên gắn chặt vào các quy trình kinh doanh quan trọng.
Hồ sơ rủi ro của các agent này về cơ bản khác với Shadow IT truyền thống. Một ứng dụng SaaS không được phê duyệt là một "điểm đến" cho dữ liệu. Còn một AI agent là một "tác nhân" có thể gọi APIs, sử dụng thông tin xác thực đã lưu, truy xuất hồ sơ, sửa đổi cấu hình, kích hoạt các quy trình công việc hạ nguồn và thực hiện hành động trong các hệ thống vận hành (production systems), thường mà không cần con người trực tiếp cho phép từng bước.
Một nhân viên dán hồ sơ khách hàng vào một công cụ AI công cộng là một sự cố rò rỉ dữ liệu. Một AI agent tùy chỉnh được kết nối với Salesforce, Snowflake, GitHub, Gong và Slack là một sự cố Access Control chực chờ xảy ra.
Nó không chỉ có thể làm lộ dữ liệu mà còn có thể thực hiện các hành động đọc, ghi và xóa dữ liệu đó. Nó cũng có thể chạy trên các tài khoản dịch vụ (service accounts) với các quyền chưa được kiểm duyệt và vẫn hoạt động sáu tháng sau khi nhân viên xây dựng nó đã thay đổi vai trò hoặc rời công ty. Nghiên cứu mới từ Token Security và Cloud Security Alliance đã chỉ ra chính xác mức độ phổ biến của lỗ hổng này.
Tại sao các biện pháp kiểm soát hiện tại không thể chạm tới?
Hầu hết các biện pháp kiểm soát an ninh doanh nghiệp được thiết kế cho danh tính con người (human identities) và các khối lượng công việc xác định. Các chính sách IAM, quy tắc DLP và giám sát mạng đều giả định các hành vi có thể dự đoán và các đường dẫn truy cập được xác định trước. Các AI agent phá vỡ những giả định đó.
Một agent được giao nhiệm vụ giải quyết một lỗi triển khai có thể đọc nhật ký, truy vấn hệ thống giám sát, sửa đổi cấu hình hạ tầng, mở vé hỗ trợ (tickets), kích hoạt quy trình tự động hóa và thông báo cho đội ngũ kỹ sư—tất cả theo trình tự và đều sử dụng cùng một thông tin xác thực được kế thừa. Để tránh làm gián đoạn quy trình công việc, các nhà phát triển thường cấp quyền rộng rãi ngay từ đầu. Những quyền này tích tụ dần, agent kế thừa đặc quyền cấp độ người sáng tạo, quyền truy cập tạm thời trở thành vĩnh viễn, khiến các nhóm bảo mật và danh tính mất đi khả năng hiển thị những gì các danh tính đó thực sự đang làm.
Việc chặn các miền AI công cộng không giải quyết được vấn đề này. Khi một agent đã có thông tin xác thực vào hệ thống doanh nghiệp, ranh giới đã bị vượt qua. Tự động hóa khắc phục các danh tính phi con người (non-human identities) chính là nơi khoảng cách đó được lấp đầy.
Một danh mục Shadow AI thực thụ trông như thế nào?
Để phát hiện Shadow AI, cần phải xem xét kỹ các môi trường nơi các agent thực sự tồn tại, chẳng hạn như nền tảng AI, ứng dụng SaaS có tính năng tự động hóa tích hợp, tài khoản đám mây, công cụ lập trình, điểm cuối và các nhà cung cấp danh tính. Dưới đây là sáu câu hỏi để xác định xem nhóm bảo mật có thực sự kiểm soát được hay không:
- Các agent đang được tạo hoặc cài đặt ở đâu? Bao gồm các nền tảng AI rõ ràng nhưng cũng có cả trợ lý lập trình, tính năng agent trong SaaS, công cụ phát triển cục bộ và các ứng dụng nội bộ âm thầm bổ sung khả năng AI.
- Ai sở hữu mỗi agent và ai có thể sử dụng nó? Không có quyền sở hữu thì không có trách nhiệm giải trình. Một agent được xây dựng cho nhóm tài chính ba người nhưng được chia sẻ rộng rãi trong tổ chức sẽ mang hồ sơ rủi ro rất khác với agent chỉ dành cho một người dùng.
- Agent được kết nối với những tài nguyên và dịch vụ nào? Một agent có vẻ vô hại ở cấp độ nền tảng nhưng lại nắm giữ các kết nối tới cơ sở dữ liệu nhạy cảm hoặc hệ thống vận hành thông qua các thông tin xác thực được cấp không chính thức và chưa bao giờ được xem xét lại.
- Nó sử dụng danh tính (identities) và bí mật (secrets) nào? Các agent xác thực thông qua tài khoản dịch vụ, API keys, OAuth tokens, các vai trò Cloud IAM và các bí mật tồn tại lâu dài. Mỗi loại thông tin xác thực mang những rủi ro khác nhau.
- Ý định của agent là gì và nó đã thực sự làm gì? Chỉ riêng cấu hình không cho thấy liệu một agent đang đọc dữ liệu, ghi hồ sơ hay truy cập các hệ thống ngoài phạm vi dự định. Hiểu được ý định và bối cảnh hành vi là yếu tố bắt buộc để ưu tiên ứng phó.
- Agent có còn hoạt động không? Dữ liệu từ Agentic Pulse của Token Security cho thấy 65,4% chatbot agentic chưa bao giờ được sử dụng kể từ khi tạo ra, nhưng thông tin xác thực của chúng vẫn còn hoạt động. Các agent "ngủ đông" nhưng vẫn có quyền truy cập trực tiếp là một lỗ hổng dai dẳng và thường bị xem nhẹ.
Lộ trình trưởng thành để đảm bảo an ninh AI agentic
Hầu hết các tổ chức mới chỉ ở bước khởi đầu và hầu như không có danh mục quản lý agent. Bước tiếp theo là đạt được khả năng hiển thị một phần để biết những agent nào đang tồn tại, ngay cả khi chưa có đầy đủ bối cảnh. Sau đó, họ cần làm phong phú thông tin và bối cảnh để hiểu ý định, xác định quyền sở hữu, quyền truy cập và thông tin xác thực cho từng agent. Bước tiếp theo là áp dụng thực thi với các kiểm soát tự động nhằm khắc phục các quyền quá mức, thông báo cho chủ sở hữu về các agent không hoạt động và gắn cờ các agent mới kết nối với các hệ thống nhạy cảm.
Mục tiêu không phải là ngăn cản việc áp dụng AI. Các đội ngũ đang chịu áp lực thực sự trong việc sử dụng các công cụ này và nhiều lợi ích về năng suất là có thật. Nếu bảo mật trở thành rào cản cứng nhắc, việc sử dụng sẽ chuyển sang hoạt động ngầm và không thể kiểm soát. Kết quả tốt hơn là "cho phép trong sự quản trị" (governed enablement) để cung cấp lộ trình cho các nhóm triển khai agent với các biện pháp kiểm soát tự động chạy liên tục dưới nền.
Điều này đòi hỏi phải đối xử với các AI agent giống như bất kỳ danh tính nào khác trong doanh nghiệp: khám phá liên tục, xác định quyền sở hữu rõ ràng, phạm vi truy cập có giới hạn và quản lý vòng đời từ khi tạo ra cho đến khi ngừng hoạt động.
Câu hỏi về Shadow AI đã thay đổi. Nó không còn là: nhân viên đang đưa dữ liệu gì vào AI? Mà giờ là: những agent nào đang hoạt động trong môi trường của chúng ta và chúng ta đã cấp cho chúng quyền truy cập vào những gì? Đó là những câu hỏi hoàn toàn khác nhau. Câu hỏi thứ hai mới là thứ định nghĩa mức độ tiếp xúc rủi ro của một tổ chức.
