AI Agent đang thay đổi cách chúng ta làm việc. Nhưng khi một trợ lý AI có thể đọc email, truy cập mã nguồn, gọi API và thực hiện hành động thay mặt nhân viên, doanh nghiệp cần đặt ra một câu hỏi quan trọng: Ai thực sự đang sử dụng quyền truy cập của chúng ta?
Trong nhiều năm, các tổ chức đã quen với việc quản lý thiết bị cá nhân, ứng dụng bên thứ ba và tài khoản nhân viên. Tuy nhiên, sự phát triển của AI Agent đang tạo ra một thách thức mới: một thực thể tự động có thể hoạt động dưới danh nghĩa của con người, sử dụng những quyền truy cập vốn được cấp cho nhân viên.
Điều đáng lo ngại là AI Agent không nhất thiết phải vượt qua hệ thống bảo mật theo cách truyền thống. Đôi khi, nó chỉ cần được người dùng nhấn nút Allow.
Đó chính là vấn đề của BYOAI — Bring Your Own AI, hay việc nhân viên tự mang AI của mình vào môi trường làm việc.
1. Từ Shadow IT đến Shadow AI
Trước đây, Shadow IT là một trong những vấn đề quen thuộc của đội ngũ bảo mật. Nhân viên có thể tự sử dụng ứng dụng lưu trữ đám mây, phần mềm quản lý công việc hoặc dịch vụ bên ngoài mà bộ phận CNTT không kiểm soát.
Shadow AI mở rộng vấn đề này lên một cấp độ khác.
Một chatbot thông thường chủ yếu tiếp nhận dữ liệu và trả về câu trả lời. Ngược lại, AI Agent có thể được cấp quyền truy cập công cụ, đọc tài liệu, thao tác trên trình duyệt, gọi API và thực hiện nhiều bước liên tiếp để hoàn thành nhiệm vụ.
Hãy tưởng tượng một nhân viên kết nối AI Agent cá nhân với Gmail, Slack và GitLab. Agent có thể tổng hợp email, tìm kiếm thông tin trong các cuộc trò chuyện, phân tích mã nguồn và hỗ trợ tạo merge request.
Tất cả những việc đó có thể giúp tăng năng suất đáng kể.
Nhưng nếu agent được cấp quyền rộng hơn nhu cầu thực tế, hoặc thông tin xác thực của nó nằm ngoài phạm vi quản lý của doanh nghiệp, một công cụ tăng năng suất có thể trở thành một điểm rủi ro bảo mật.
Vấn đề không nằm ở việc AI có thông minh hay không, mà nằm ở những gì AI được phép làm.
2. AI Agent xâm nhập hệ thống bằng cách nào?
Một trong những đặc điểm khiến BYOAI khó kiểm soát là quá trình kết nối thường diễn ra rất đơn giản. Nhân viên có thể chủ động thiết lập tích hợp mà không cần tạo yêu cầu hỗ trợ CNTT.
Có ít nhất năm con đường phổ biến cần được quan tâm.
2.1. OAuth: Một lần cấp quyền, nhiều khả năng truy cập
OAuth giúp ứng dụng truy cập tài nguyên mà không cần trực tiếp biết mật khẩu của người dùng.
Tuy nhiên, khi nhân viên cấp quyền cho một AI Agent, phạm vi quyền được cấp có thể vượt quá nhu cầu của nhiệm vụ.
Ví dụ, agent chỉ cần đọc email để tạo bản tóm tắt, nhưng ứng dụng lại được cấp thêm quyền gửi hoặc xóa thư.
Nếu agent bị thao túng, gặp lỗi hoặc thực hiện sai yêu cầu, những quyền bổ sung này có thể làm tăng đáng kể phạm vi thiệt hại.
Vì vậy, doanh nghiệp không nên chỉ quan tâm ứng dụng nào đã được kết nối. Điều quan trọng hơn là ứng dụng đó đang có những quyền gì.
2.2. API key và Personal Access Token
Trong môi trường phát triển phần mềm, API key và Personal Access Token (PAT) là những thông tin xác thực quen thuộc.
Một lập trình viên có thể tạo PAT để AI Agent truy cập repository, đọc issue hoặc tạo merge request. Nếu token có quyền quản trị rộng và thời hạn dài, rủi ro sẽ tăng lên.
Đặc biệt, khi token được lưu trong tệp cấu hình, biến môi trường hoặc môi trường thực thi mà doanh nghiệp không quản lý, việc kiểm kê và thu hồi có thể trở nên khó khăn.
Một nguyên tắc nên được áp dụng ngay từ đầu:
Không cấp cho AI Agent một token quản trị chỉ để thực hiện một nhiệm vụ thông thường.
Hãy giới hạn quyền theo repository, phạm vi thao tác và thời gian sử dụng. Khi có thể, nên ưu tiên thông tin xác thực ngắn hạn thay vì token tồn tại vô thời hạn.
2.3. Trình duyệt và phiên đăng nhập của nhân viên
Một số agent có thể thao tác thông qua trình duyệt hoặc môi trường máy tính đã được xác thực.
Trong trường hợp này, hệ thống đích có thể nhìn thấy một phiên đăng nhập hợp lệ của nhân viên mà không dễ dàng xác định hành động cụ thể được thực hiện bởi con người hay bởi AI.
Đây là vấn đề về khả năng truy vết.
Khi xảy ra sự cố, đội ngũ bảo mật cần biết không chỉ tài khoản nào đã thực hiện hành động, mà còn cần xác định được tiến trình, agent hoặc ứng dụng nào đã khởi tạo hành động đó, nếu hệ thống có đủ dữ liệu để phân biệt.
2.4. Agent chạy trên máy tính cá nhân
Agent chạy cục bộ có thể tương tác trực tiếp với các tệp, ứng dụng và công cụ trên máy tính.
Nếu được cấp quyền đọc quá rộng, agent có thể tiếp cận những tài liệu không liên quan đến nhiệm vụ ban đầu. Nếu có khả năng chạy lệnh hệ thống, phạm vi ảnh hưởng có thể lớn hơn nữa.
Giải pháp không đơn thuần là cài đặt thêm phần mềm giám sát. Doanh nghiệp cần kết hợp quyền hệ điều hành, phân vùng dữ liệu, cô lập môi trường thực thi và giám sát hành vi.
2.5. Hạ tầng AI nằm ngoài doanh nghiệp
Một agent có thể chạy trên máy chủ của nhà cung cấp thay vì máy tính của nhân viên.
Điều này thuận tiện cho người dùng nhưng tạo ra câu hỏi về nơi lưu trữ dữ liệu, cách quản lý token, thời gian lưu giữ phiên làm việc và khả năng kiểm soát hành động.
Ngay cả khi nhà cung cấp có cơ chế bảo vệ riêng, doanh nghiệp vẫn cần đánh giá liệu những cơ chế đó có đáp ứng chính sách bảo mật của tổ chức hay không.
3. Bài toán thực sự là danh tính, không chỉ là công cụ AI
Hãy xem xét một tình huống đơn giản.
Một nhân viên có quyền truy cập vào mã nguồn nội bộ. AI Agent cá nhân của người đó cũng sử dụng chính thông tin xác thực của nhân viên để truy cập repository.
Trong nhật ký, hệ thống chỉ ghi nhận tài khoản nhân viên.
Vậy ai đã thực hiện hành động?
Nhân viên trực tiếp đọc hoặc thay đổi mã nguồn?
AI Agent thực hiện theo yêu cầu của nhân viên?
Một quy trình tự động được khởi chạy từ agent?
Hay agent đã thực hiện hành động ngoài dự kiến?
Nếu hệ thống không có đủ thông tin để phân biệt, việc điều tra sự cố sẽ khó khăn hơn.
Điều này cho thấy danh tính người dùng và danh tính agent không nên bị xem là một.
Một mô hình quản trị tốt cần phân biệt ba thành phần:
Human identity: Ai chịu trách nhiệm về nhiệm vụ?
Agent identity: Tiến trình hoặc agent nào đang thực hiện hành động?
Resource identity: Tài nguyên nào đang được truy cập?
Ba thành phần này phải được liên kết trong quá trình xác thực, cấp quyền và ghi nhật ký.
Tất nhiên, việc gán một ID cho agent không tự động khiến agent trở nên đáng tin cậy. Danh tính phải được ràng buộc với cơ chế xác thực phù hợp và được hệ thống đích kiểm tra.
4. Xây dựng mô hình bảo mật AI Agent theo Zero Trust
Zero Trust là một hướng tiếp cận phù hợp cho bài toán này: không mặc định tin cậy một yêu cầu chỉ vì nó xuất phát từ tài khoản hợp lệ hoặc thiết bị thuộc tổ chức.
Thay vì hỏi đơn thuần “Người dùng đã đăng nhập chưa?”, hệ thống cần đặt thêm những câu hỏi:
Agent có được phê duyệt không?
Ai là chủ sở hữu của agent?
Agent đang truy cập tài nguyên nào?
Quyền được cấp có phù hợp với nhiệm vụ không?
Hành động có nhạy cảm hoặc khó đảo ngược không?
Có cần yêu cầu con người phê duyệt trước khi thực hiện không?
Một kiến trúc tham chiếu có thể gồm các thành phần sau:
Identity & Access Management: Quản lý danh tính nhân viên, agent và mối quan hệ sở hữu.
Policy Engine: Đánh giá yêu cầu theo danh tính, quyền, tài nguyên và ngữ cảnh.
Policy Enforcement Point: Thực thi quyết định cho phép hoặc từ chối.
Token Broker hoặc Secret Manager: Quản lý thông tin xác thực và cấp quyền theo phạm vi được phép.
Audit Log và SIEM: Thu thập sự kiện, phát hiện hành vi bất thường và hỗ trợ điều tra.
Không phải mọi dịch vụ đều có thể được bảo vệ thông qua một gateway duy nhất. Với các nền tảng SaaS, doanh nghiệp có thể phải sử dụng API quản trị, chính sách OAuth, hệ thống IAM và cơ chế kiểm soát riêng của từng nhà cung cấp.
Điểm quan trọng là các lớp kiểm soát phải phối hợp với nhau, thay vì chỉ dựa vào một công cụ phát hiện AI.
5. Nguyên tắc đặc quyền tối thiểu: AI chỉ được làm những gì cần thiết
Giả sử một AI Agent được sử dụng để hỗ trợ lập trình viên.
Nó cần đọc mã nguồn, phân tích lỗi và tạo merge request. Nhưng liệu nó có cần quyền xóa repository, quản trị thành viên hay triển khai trực tiếp lên production?
Trong phần lớn trường hợp, câu trả lời là không.
Một mô hình cấp quyền hợp lý có thể như sau:
Hành độngChính sách đề xuấtĐọc mã nguồnCho phép trong repository được phê duyệtTạo nhánh hoặc merge requestCho phép có giới hạnHợp nhất mã nguồnTheo quy trình phê duyệtSửa cấu hình productionHạn chế và giám sát tăng cườngTriển khai productionThông qua CI/CD có kiểm soátQuản trị toàn bộ tổ chứcKhông cấp mặc định
Nguyên tắc này cũng áp dụng cho email, hệ thống CRM, cơ sở dữ liệu và các nền tảng SaaS.
Một agent chỉ cần đọc dữ liệu không nên mặc nhiên có quyền ghi. Một agent cần tạo bản nháp không nên mặc nhiên có quyền gửi. Một agent cần phân tích mã nguồn không nên mặc nhiên có quyền triển khai.
Quyền truy cập nên được thiết kế theo nhiệm vụ, không theo toàn bộ quyền mà chủ sở hữu đang có.
6. Phát hiện Shadow AI trước khi tìm cách chặn
Một sai lầm thường gặp trong quản trị công nghệ là cố gắng chặn những gì chưa được kiểm kê đầy đủ.
Với AI Agent, doanh nghiệp nên bắt đầu bằng việc xác định những kết nối đang tồn tại.
Các nguồn dữ liệu có thể bao gồm:
Nhật ký OAuth consent và danh sách ứng dụng bên thứ ba.
Nhật ký đăng nhập từ hệ thống SSO.
API key và PAT đang hoạt động.
Nhật ký truy cập từ GitLab, GitHub và các dịch vụ SaaS.
Dữ liệu giám sát từ EDR.
Các sự kiện truy cập API và hành vi bất thường.
Không nên dựa vào một tín hiệu duy nhất. Chẳng hạn, địa chỉ IP của nhà cung cấp đám mây có thể là dấu hiệu đáng chú ý nhưng không đủ để khẳng định một yêu cầu chắc chắn đến từ AI Agent.
Sau khi phát hiện, mỗi agent nên được phân loại theo mức độ rủi ro, gắn với một chủ sở hữu và xác định rõ quyền truy cập.
Từ đó, doanh nghiệp có thể lựa chọn cho phép, giới hạn, yêu cầu phê duyệt hoặc thu hồi quyền thay vì chặn hàng loạt mọi công cụ chưa được biết đến.
7. Đừng quên vòng đời nhân viên và thông tin xác thực
Một vấn đề dễ bị bỏ sót là quá trình offboarding.
Khi nhân viên rời công ty, doanh nghiệp thường tập trung vô hiệu hóa tài khoản email, SSO và thiết bị. Nhưng nếu agent đã được cấp token hoặc được kết nối với nhiều dịch vụ, những quyền đó có thể không biến mất đồng thời.
Một quy trình offboarding dành cho môi trường có AI Agent nên bao gồm:
Vô hiệu hóa tài khoản nhân viên.
Liệt kê agent và ứng dụng được liên kết với người đó.
Thu hồi OAuth consent, PAT và các thông tin xác thực có thể thu hồi.
Chấm dứt những phiên đăng nhập còn hiệu lực khi hệ thống hỗ trợ.
Vô hiệu hóa hoặc chuyển quyền sở hữu agent theo chính sách.
Xác minh rằng không còn đường truy cập ngoài ý muốn.
Việc khóa tài khoản không bảo đảm mọi token và phiên đã phát hành đều lập tức mất hiệu lực. Doanh nghiệp cần hiểu rõ cơ chế thu hồi của từng dịch vụ và xác minh kết quả sau khi thực hiện.
Đây không chỉ là một bước trong quy trình nhân sự. Nó là một phần của quản lý vòng đời danh tính và quyền truy cập.
8. Bảo mật AI Agent không dừng ở danh tính
Danh tính là nền tảng quan trọng, nhưng không giải quyết toàn bộ rủi ro của AI Agent.
Một agent có quyền đọc dữ liệu vẫn có thể đưa thông tin nhạy cảm vào dịch vụ không được phép. Một agent được xác thực đúng vẫn có thể bị thao túng bởi chỉ dẫn độc hại trong email, tài liệu hoặc trang web.
Vì vậy, doanh nghiệp cần kết hợp quản trị danh tính với:
Phân loại dữ liệu và chính sách sử dụng AI.
Kiểm soát luồng dữ liệu ra khỏi tổ chức.
Hạn chế công cụ và thao tác có mức tác động cao.
Phê duyệt của con người đối với hành động nhạy cảm.
Giám sát, ghi nhật ký và khả năng điều tra.
Đánh giá bảo mật, quyền riêng tư và điều khoản của nhà cung cấp.
Đặc biệt, nội dung do AI đọc được không nên tự động trở thành chỉ dẫn đáng tin cậy để thực hiện hành động. Agent cần được thiết kế để phân biệt dữ liệu đầu vào với các chỉ dẫn và chính sách kiểm soát có thẩm quyền.
9. Doanh nghiệp nên bắt đầu từ đâu?
Thay vì cố gắng giải quyết toàn bộ vấn đề cùng lúc, doanh nghiệp có thể triển khai theo ba bước.
Bước 1: Kiểm kê. Xác định các agent, ứng dụng OAuth, API key và PAT đang truy cập tài nguyên doanh nghiệp.
Bước 2: Giảm thiểu quyền. Ưu tiên xử lý những kết nối có quyền rộng, truy cập dữ liệu nhạy cảm hoặc khả năng thực hiện hành động khó đảo ngược.
Bước 3: Chuẩn hóa quản trị. Xây dựng danh tính agent, quy trình phê duyệt, nhật ký kiểm toán và cơ chế thu hồi quyền theo vòng đời.
Hiệu quả nên được đánh giá bằng những chỉ số có thể đo lường, chẳng hạn tỷ lệ phát hiện agent, tỷ lệ chặn yêu cầu trái phép, thời gian thu hồi quyền và khả năng truy vết hành động.
Không nên chỉ đo số lượng agent bị chặn. Mục tiêu cuối cùng là giảm rủi ro mà vẫn duy trì khả năng tự động hóa hữu ích.
Kết luận: AI có thể hành động thay con người, nhưng trách nhiệm bảo mật không thể bị bỏ ngỏ
AI Agent đang mở ra một cách làm việc mới, nơi nhiều tác vụ có thể được tự động hóa từ đầu đến cuối. Nhưng khi agent có thể sử dụng tài khoản, thông tin xác thực và quyền truy cập của nhân viên, mô hình bảo mật truyền thống cần được xem xét lại.
Doanh nghiệp không nên mặc định rằng một yêu cầu được xác thực bằng tài khoản nhân viên chắc chắn do chính nhân viên thực hiện. Đồng thời, cũng không nên cho rằng việc đăng ký một agent trong danh mục quản trị đã đủ để kiểm soát mọi hành động của nó.
Cần kết hợp danh tính có thể xác minh, quyền truy cập tối thiểu, cơ chế thực thi chính sách, khả năng truy vết và quy trình thu hồi rõ ràng.
Trong kỷ nguyên AI Agent, câu hỏi quan trọng không còn chỉ là “Ai được phép đăng nhập?” mà còn là “Ai đang hành động, hành động thay mặt ai và hành động đó được phép đến đâu?”
Đó chính là nền tảng để doanh nghiệp tận dụng AI một cách có trách nhiệm mà không đánh đổi khả năng kiểm soát bảo mật.
Tài liệu tham khảo
The Hacker News — Bring Your Own Agent: Your Employees' Assistants Are Already Logged In.
NIST SP 800-207 — Zero Trust Architecture: https://doi.org/10.6028/NIST.SP.800-207
NIST AI RMF 1.0 — Artificial Intelligence Risk Management Framework: https://doi.org/10.6028/NIST.AI.100-1
IETF RFC 9700 — Best Current Practice for OAuth 2.0 Security: https://www.rfc-editor.org/rfc/rfc9700.html
Bình luận
Chưa có bình luận nào.
Đăng nhập để bình luận.