Hướng dẫn bảo mật khi dùng AI agent

Theo Báo cáo về Tình hình Bảo mật AI Agent năm 2026 của Gravitee, 54% các tổ chức đã từng gặp phải sự cố bảo mật liên quan đến AI agent.

Tốc độ xảy ra các sự cố này đang ngày càng tăng. Vào tháng 7 năm 2026, các mô hình của OpenAI trong quá trình thực hiện đánh giá an ninh mạng đã thoát khỏi môi trường sandbox và xâm nhập vào cơ sở hạ tầng vận hành thực tế của Hugging Face. Sự việc này diễn ra mà không có sự can thiệp của bất kỳ kẻ tấn công bên ngoài nào. Khi bị chặn thực hiện các tác vụ, các AI agent này đã biến một trình quản lý gói nội bộ thành một bảng tin, chia sẻ các đoạn code exploit và thông tin xác thực thông qua đó; thậm chí chúng vẫn tiếp tục hoạt động ngay cả sau khi đội ngũ bảo mật đã khôi phục lại hệ thống.

Vụ việc này liên quan đến hành vi thoát khỏi môi trường sandbox và sự phối hợp tự chủ giữa các AI agent, trong đó việc sử dụng thông tin xác thực chỉ là một trong nhiều kỹ thuật được áp dụng. Đây chính là điểm mấu chốt mà chương trình bảo mật hiện tại của bạn có thể tập trung giải quyết.

Các AI agent thực hiện xác thực, quản lý thông tin xác thực, đọc file, chạy những lệnh hệ thống, gọi các API và tương tác với các hệ thống thay mặt cho những đội ngũ triển khai chúng. Điều này biến chúng thành một dạng định danh phi con người (non-human identity - NHI) mới; chúng được cấp hoặc kế thừa các thông tin xác thực, thường là mà không có những biện pháp kiểm soát quản trị nghiêm ngặt như đối với các tài khoản dịch vụ hay API key. Vì các AI agent thường sử dụng chính thông tin xác thực của bạn, nên nếu một agent bị cấu hình sai hoặc bị chiếm quyền kiểm soát, nó có thể truy cập vào tất cả các hệ thống mà những thông tin xác thực đó cho phép. 

Bài viết này đề cập đến các rủi ro bảo mật chính đối với AI agent và cách thức bảo mật chúng trong thực tế. Những biện pháp kiểm soát cụ thể xuyên suốt vòng đời của thông tin xác thực. Dù bạn đang triển khai các agent hỗ trợ lập trình, những workflow tự chủ hay các tích hợp MCP (Model Context Protocol) server, thì câu hỏi cốt lõi vẫn luôn là: Agent này có thể truy cập vào những gì, và điều gì sẽ xảy ra nếu nó hoạt động không đúng như dự kiến?

Các phương pháp hay nhất về bảo mật AI agent: Danh mục kiểm tra triển khai

6 biện pháp kiểm soát dưới đây đóng vai trò là các rào chắn thiết thực cho AI agent, tập trung vào việc thu hẹp phạm vi ảnh hưởng, hạn chế những kênh rủi ro, đồng thời giúp các nhóm có khả năng quan sát kịp thời trước khi một sự cố leo thang thành hành vi xâm phạm bảo mật.

6 biện pháp kiểm soát bảo mật cho AI agent

Biện pháp 1: Chạy agent trong môi trường biệt lập (sandbox)

Việc giới hạn phạm vi truy cập của một agent bị xâm phạm hoặc hoạt động sai trái là một trong những biện pháp kiểm soát đáng tin cậy nhất hiện có. Nó cũng bao gồm phạm vi nỗ lực rộng nhất, từ các cài đặt đi kèm với những công cụ mà nhóm của bạn đã sử dụng cho đến việc cách ly hoàn toàn bằng máy ảo, vì vậy điều quan trọng là phải xác định rõ bạn đang bắt đầu từ đâu. Một agent chạy trong môi trường biệt lập với quyền truy cập mạng bị hạn chế, phạm vi hệ thống file bị giới hạn và không có quyền truy cập vào thông tin đăng nhập sản xuất sẽ khó bị khai thác hơn nhiều so với một agent có quyền truy cập hệ thống rộng.

Việc sử dụng sandbox đặc biệt quan trọng đối với các agent xử lý đầu vào không đáng tin cậy: Nội dung repository từ những người đóng góp bên ngoài, email hoặc phiếu yêu cầu từ các chủ thể bên ngoài, nội dung web từ nhưunxg nguồn không xác định.

Hãy bắt đầu với các biện pháp kiểm soát gốc trước khi sử dụng container. Hầu hết những công cụ lập trình AI đều đi kèm với cài đặt sandbox mà các nhóm thường để mặc định, và việc bật chúng lên không tốn chi phí. Hãy cùng xem xét chi tiết hơn:

• Claude Code: Không bao giờ bật --dangerously-skip-permissions, và cấu hình các quy tắc cho phép và từ chối rõ ràng cho những công cụ mà agent có thể gọi.
• Cursor: Sử dụng .cursorrules để hạn chế quyền truy cập file và vô hiệu hóa các MCP server mà bạn không sử dụng.
• GitHub Copilot : Cài đặt độ tin cậy của workspace kiểm soát những gì agent có thể đọc và chạy, vì vậy hãy giữ chúng trong phạm vi dự án hiện tại.

Khi các biện pháp kiểm soát gốc không đủ, Docker Sandboxes chạy mỗi phiên agent trong một máy ảo nhẹ với hệ thống file và network namespace riêng, do đó thông tin xác thực và trạng thái từ một phiên không thể truyền sang phiên khác. Đây là sự cô lập thông tin xác thực ở cấp độ thời gian chạy, một biện pháp kiểm soát mạnh mẽ hơn so với việc sử dụng hộp cát ở cấp độ tiến trình. Bất kể bạn sử dụng phương pháp nào, hãy gắn thư mục dự án, chứ không phải thư mục chính.

Phân đoạn vi mô áp dụng nguyên tắc tương tự ở cấp độ mạng: Các agent chỉ nên có thể truy cập các dịch vụ cụ thể mà chúng cần và không gì khác. Nếu một agent lập trình cần gọi một API cụ thể, hãy cấp cho nó thông tin xác thực được giới hạn trong phạm vi API đó và quyền truy cập mạng bị hạn chế đối với endpoint đó.

Biện pháp 2: Cấp cho mỗi agent một thông tin xác thực giới hạn trong phạm vi nhiệm vụ của nó

Mỗi AI agent khi xác thực với một dịch vụ, sử dụng thông tin xác thực hoặc thực hiện thao tác trên hệ thống đều cần có một định danh duy nhất, một chủ sở hữu được chỉ định và một vòng đời thông tin xác thực được ghi lại rõ ràng - tương tự như cách quản lý tài khoản dịch vụ.

Trên thực tế, điều này có nghĩa là cấp các thông tin xác thực riêng biệt cho từng agent, thay vì chia sẻ thông tin xác thực giữa nhiều agent hoặc tái sử dụng các token của nhà phát triển. Bạn cần biết ai là chủ sở hữu của mỗi thông tin xác thực, nó có quyền truy cập vào những gì và lần cuối cùng nó được đánh giá là khi nào. Hãy theo dõi các định danh của agent giống như cách bạn theo dõi những tài khoản dịch vụ: Xác định các định danh hiện có, gán mỗi định danh cho một chủ sở hữu, đánh giá mức độ rủi ro (liệu nó có đang được cấp quyền quá mức, đã lỗi thời hay không được quản lý?), và lập danh mục để đảm bảo không có thành phần nào hoạt động mà không được kiểm soát.

Đây chính là mô hình quản trị định danh phi con người (non-human identity governance). Nó không phải là một công cụ tự động thực hiện các tác vụ này, mà là một tư duy nền tảng giúp những biện pháp kiểm soát khác trở nên nhất quán và hiệu quả.

Phương pháp quản trị phù hợp sẽ tùy thuộc vào loại agent:

• Các agent tự hành (như bot trong quy trình xử lý, agent chạy tác vụ theo lịch trình, hoặc các tiến trình CI/CD) cần có thông tin xác thực riêng biệt (NHI - định danh phi con người) với một chủ sở hữu cụ thể, tương tự như bất kỳ tài khoản dịch vụ nào.
• Các agent hỗ trợ lập trình tương tác (như Claude Code hoặc Cursor) hiện nay thường chạy dưới quyền của chính nhà phát triển. Khi agent hoạt động với tư cách người dùng, nhật ký kiểm toán (audit log) sẽ ghi lại tên người dùng đó, khiến việc phân biệt đâu là thao tác của người dùng và đâu là thao tác của agent trở nên bất khả thi. Hãy hướng tới việc thiết lập một định danh riêng biệt cho các agent này. Trong trường hợp công cụ chưa hỗ trợ định danh riêng, hãy giới hạn phạm vi truy cập của các thông tin xác thực mà agent đó có thể sử dụng, đồng thời đưa agent đó vào danh mục quản lý của bạn.

Cách nhanh nhất để giảm thiểu phạm vi ảnh hưởng là thu hẹp phạm vi truy cập của agent. Một agent hoạt động với quyền admin sẽ tiềm ẩn rủi ro cao hơn nhiều so với một agent chỉ có quyền đọc (read-only) giới hạn trong một repository cụ thể. 

4 phương pháp giúp hạn chế tình trạng cấp quyền quá mức:

• Ưu tiên sử dụng các thông tin xác thực có thời hạn ngắn thay vì các token tĩnh có thời hạn dài, nếu dịch vụ hỗ trợ.
• Giới hạn phạm vi truy cập của thông tin xác thực ở mức tối thiểu cần thiết để agent hoàn thành nhiệm vụ.
• Tránh chia sẻ thông tin xác thực giữa nhiều agent khác nhau để đảm bảo phạm vi ảnh hưởng của chúng được tách biệt.
• Xoay vòng thông tin xác thực có thời hạn dài theo lịch trình. Thông tin xác thực của agent không bao giờ được xoay vòng sẽ trở nên có giá trị hơn đối với kẻ tấn công theo thời gian.

Đối với các nhóm quản lý số lượng lớn danh tính agent, đây là lúc việc lập danh mục NHI trở nên hữu ích về mặt vận hành. Một danh mục hiển thị các agent nào đang nắm giữ thông tin xác thực quá mức và đánh dấu những danh tính lỗi thời hoặc không được gán sẽ biến việc kiểm tra thủ công thành việc gắn cờ tự động.

Cách thức lưu trữ các thông tin bí mật (secret) của agent sẽ quyết định phạm vi ảnh hưởng mà bạn phải chấp nhận nếu xảy ra sự cố bảo mật. Hãy coi đây như một thang đo mức độ trưởng thành:

• Cấp độ 1 (tệ nhất): Lưu trữ dưới dạng plaintext trong các file `.env` trên ổ đĩa – đây là thứ đầu tiên mà agent đọc khi khởi chạy.
• Cấp độ 2: Sử dụng trình quản lý mật khẩu cục bộ, trong đó thông tin bí mật chỉ được truy xuất khi có yêu cầu cụ thể.
• Cấp độ 3: Cung cấp thông tin bí mật tại thời điểm thực thi; một hệ thống lưu trữ bảo mật (vault) sẽ cung cấp thông tin khi bắt đầu phiên làm việc, hoặc một proxy xác thực sẽ tự động chèn thông tin đó vào luồng dữ liệu, nhờ vậy agent không bao giờ thực sự nắm giữ giá trị gốc.
• Cấp độ 4 (tốt nhất): Sử dụng các token tạm thời cho từng yêu cầu cụ thể và hết hạn ngay lập tức. Bạn không thể làm rò rỉ thứ vốn đã không còn tồn tại.

Hầu hết các tổ chức hiện vẫn đang ở Cấp độ 1 hoặc 2. Việc chuyển sang cơ chế cung cấp thông tin tại thời điểm thực thi và sử dụng những thông tin xác thực tạm thời chính là thay đổi mang lại hiệu quả cao nhất trong lĩnh vực này.

Đây cũng là giải pháp duy nhất trong danh sách này có thể khắc phục hạn chế đã nêu trước đó; vì một thông tin bí mật không bao giờ được ghi vào ổ đĩa thì agent cũng không thể đọc được nó, bất kể công cụ quét bảo mật có phát hiện ra hay không.

Biện pháp 3: Ngăn agent truy cập vào cấu hình của chính nó và các MCP server

Agent thường đọc các file ở cấp độ dự án (như .claude/settings.json và .mcp.json) để làm chỉ dẫn, và những file này có thể bị thiết lập bởi một repository không đáng tin cậy. Hãy lưu trữ các cấu hình này ở nơi mà agent không có quyền ghi dữ liệu: Cố định (pin) file cấu hình để ngăn chặn việc sửa đổi trong quá trình thực thi; tuyệt đối không đặt enableAllProjectMcpServers thành true; đồng thời đảm bảo các thiết lập được quản lý tập trung luôn có quyền ưu tiên cao hơn bất kỳ cấu hình nào nằm trong repository.

Các MCP server giúp mở rộng khả năng hoạt động của AI agent. Mỗi server được cài đặt trong môi trường của nhà phát triển cũng đồng thời tạo ra một điểm truy cập mới: Một công cụ có khả năng kết nối với các hệ thống, đọc file hoặc thực hiện các thao tác tùy theo cấu hình của nó.

Việc bảo mật các MCP server cũng tuân theo những nguyên tắc tiêu chuẩn đối với phần mềm mới: Cần nắm rõ những gì đã được cài đặt, nguồn gốc của chúng và phạm vi truy cập mà chúng có. Đối với các MCP server, điều này đồng nghĩa với việc duy trì danh mục những server đang chạy trên toàn bộ hệ thống của nhà phát triển, xác thực rằng mỗi server đều đến từ nguồn đáng tin cậy, đồng thời giới hạn quyền truy cập của chúng chỉ trong phạm vi thực sự cần thiết cho agent.

Xác thực là yếu tố quan trọng ở cấp độ kết nối. Các MCP server chấp nhận kết nối mà không yêu cầu xác thực, hoặc vận hành với những quyền hạn quá rộng, sẽ tạo ra bề mặt tấn công – chính là điều khiến kỹ thuật Prompt injection trở nên nguy hiểm. Ngay cả khi một agent bị thao túng để gọi một công cụ, thì bản thân công cụ đó cũng chỉ được phép thực hiện những tác vụ đã được cấu hình cụ thể.

Biện pháp 4: Ghi lại mọi lệnh gọi và đặt các "honeytoken" (dữ liệu bẫy)

Nếu một agent thực hiện các hành động mà không để lại dấu vết, bạn sẽ không thể điều tra khi có sự cố xảy ra. Việc ghi nhật ký (log) mọi lệnh gọi công cụ, mọi kết nối hướng ra ngoài, mọi lần sử dụng thông tin xác thực và mọi kết quả đầu ra sẽ cung cấp cho đội ngũ bảo mật các tín hiệu cần thiết để phát hiện điểm bất thường, tái dựng sự cố và xác định agent cụ thể đã thực hiện hành động đó.

Những yêu cầu về ghi nhật ký đối với các AI agent cũng tương tự như đối với các tài khoản dịch vụ, bao gồm:

• Dấu thời gian (Timestamp)
• Danh tính (Identity)
• Hành động (Action)
• Đối tượng mục tiêu (Target)
• Kết quả (Outcome)

Điểm phức tạp hơn là các hành động của một agent có thể trải rộng trên nhiều hệ thống trong cùng một phiên làm việc. Một bản ghi nhật ký lưu lại từng bước trong chuỗi hành động đó sẽ hữu ích hơn nhiều so với việc chỉ ghi lại kết quả cuối cùng. Hãy gửi dữ liệu này đến hệ thống mà đội ngũ bảo mật của bạn đang sử dụng để giám sát.

Giám sát hành vi giúp chuyển đổi dữ liệu nhật ký thành các tín hiệu có thể hành động được. Những mô thức bất thường – chẳng hạn như một agent truy cập vào các hệ thống mà nó thường không chạm tới, số lượng lệnh gọi API lớn bất thường, hoặc việc sử dụng thông tin xác thực từ một vị trí không mong đợi – cần phải kích hoạt những cảnh báo, thay vì chỉ đơn thuần là tạo ra các dòng nhật ký.

Một lưu ý về các công cụ bạn đang sử dụng: Các hệ thống phát hiện và phản ứng tại endpoint (EDR) vốn được xây dựng dựa trên nhịp độ hoạt động của con người. Một agent có thể đọc hàng trăm file trong một giây, thực thi các lệnh ngay lập tức mà không cần suy nghĩ, và có thể chạy vào lúc 3 giờ sáng nếu được kích hoạt bởi một quy trình tự động (pipeline). Những hành động vốn sẽ bị cảnh báo ngay lập tức nếu do con người thực hiện thì lại có thể bị coi là hoạt động tự động bình thường; ngược lại, những hành động hoàn toàn bình thường đối với một agent tự động đôi khi lại trông giống như một vụ xâm nhập. 

Đây chính là lúc các "honeytoken" phát huy tác dụng. Chúng sẽ kích hoạt cảnh báo ngay khi có bất kỳ sự tương tác nào, bất kể các hoạt động thông thường (baseline) diễn ra như thế nào.

Honeytoken là một loại thông tin xác thực giả: Không có giá trị sử dụng thực tế nhưng trông giống hệt thông tin xác thực thật. Khi được đặt tại những vị trí mà một agent bị xâm nhập hoặc kẻ tấn công thường tìm kiếm - chẳng hạn như các file cấu hình, thư mục chứa thông tin xác thực, hay lịch sử dòng lệnh (shell history) - honeytoken sẽ phát đi cảnh báo ngay khi có đối tượng chạm vào nó.

Giá trị của chúng nằm ở tính bất đối xứng. Một kẻ tấn công hoặc một tiến trình bị xâm nhập khi chạm vào honeytoken sẽ tự bộc lộ danh tính trước khi kịp sử dụng thông tin xác thực đó. Đây chính là cơ chế phát hiện trước khi gây ra hậu quả.

Trên thực tế, honeytoken đóng vai trò bổ trợ cho các phương pháp quét thông tin xác thực tiêu chuẩn. Trong khi việc quét giúp phát hiện các thông tin xác thực thật trước khi chúng bị lộ, thì honeytoken lại giúp phát hiện hành vi truy cập trái phép sau khi một đối tượng (hoặc agent) đã xâm nhập được vào môi trường.

Biện pháp 5: Quét workspace để tìm kiếm thông tin xác thực trước khi thực thi lần đầu

Các trợ lý lập trình AI đang trở thành một kênh dẫn đến nguy cơ lộ thông tin xác thực ngày càng phổ biến. Báo cáo "State of Secrets Sprawl 2026" của GitGuardian cho thấy, các commit được hỗ trợ bởi Claude Code có tỷ lệ chứa thông tin xác thực là 3,2% - cao gấp đôi so với mức trung bình 1,5% trên tất cả những repository công khai trên GitHub. Kịch bản phổ biến nhất là: Các agent viết code, sao chép các mẫu từ ngữ cảnh làm việc, và đôi khi những mẫu này vô tình bao gồm cả các API key hoặc token từ những file cục bộ.

Cần thực hiện quét bảo mật trước lần chạy đầu tiên và quét lại mỗi khi workspace có thay đổi; bất kỳ dữ liệu nào mà agent có thể đọc được đều nằm trong phạm vi dữ liệu mà nó có thể tiếp cận. Có hai biện pháp kiểm soát trực tiếp vấn đề này. Thứ nhất là quét thông tin bí mật trên tất cả các commit trước khi hợp nhất (merge), bất kể code đó do con người hay trợ lý lập trình AI tạo ra. Các công cụ như ggshield có thể được thiết lập dưới dạng "pre-commit hook" (lệnh chạy trước khi commit) hoặc kiểm tra trong quy trình CI (tích hợp liên tục), giúp phát hiện các thông tin bí mật được hardcode trước khi chúng được đưa vào repository. Thứ hai là quét code do AI tạo ra theo thời gian thực thông qua MCP (Model Context Protocol) server; phương pháp này cho phép kiểm soát code ngay tại thời điểm được tạo ra, thay vì đợi đến khi thực hiện commit.

Các file cấu hình của agent cũng cần được kiểm tra kỹ lưỡng tương tự. Theo dữ liệu từ GitGuardian, trong năm 2025, có 24.008 thông tin bí mật được tìm thấy trong các file cấu hình MCP công khai, trong đó 8,8% vẫn còn hiệu lực. Các file cấu hình dành cho Claude Code, Cursor, VS Code và những công cụ phát triển hỗ trợ bởi AI thường chứa các token hoặc API key mà lập trình viên đã thêm vào trong quá trình thiết lập. Do đó, các file này cần được đưa vào phạm vi quét bảo mật, bên cạnh mã nguồn thông thường.

Các mô thức về việc một agent lập trình có thể lạm dụng thông tin xác thực không được giới hạn phạm vi đã được ghi nhận rất chi tiết. Điểm chung trong hầu hết các trường hợp là: Agent đó không hề đánh cắp thông tin xác thực; chúng vốn đã tồn tại ở đó từ trước.

Quá trình quét bảo mật cũng cần bao quát cả những dữ liệu mà agent đọc và tạo ra trong quá trình vận hành:

• Các "AI Hook" (điểm kiểm soát AI): Đây là các cơ chế tích hợp giúp quét những câu lệnh (prompt) và các lệnh gọi công cụ của agent để tìm kiếm thông tin bí mật trước khi chúng được xử lý hoặc thực thi. Nếu phát hiện thông tin bí mật trong một câu lệnh, nhà phát triển sẽ nhận được cảnh báo trước khi câu lệnh đó được gửi đi. Đây không phải là biện pháp ngăn chặn tấn công Prompt injection, mà là ngăn chặn ngay từ đầu việc các thông tin xác thực thực sự lọt vào ngữ cảnh hoạt động của agent.
• Quét dữ liệu đầu ra: Đối với các agent tạo ra code hoặc kết quả từ công cụ, dữ liệu đầu ra này cần được kiểm tra để phát hiện thông tin bí mật trước khi được lưu vào hệ thống (commit), ghi nhật ký (log) hoặc gửi đến các hệ thống downstream. Các phương thức quét dùng để phát hiện thông tin xác thực được hardcoded trong code do con người viết cũng có thể áp dụng cho dữ liệu đầu ra do AI tạo ra.

Biện pháp 6: Áp dụng nguyên tắc "từ chối theo mặc định" và chỉ phê duyệt những thao tác không thể hoàn tác

Tự động hóa giúp rút ngắn khoảng thời gian từ khi agent đưa ra quyết định đến khi hậu quả xảy ra – đó chính là mục đích của nó. Tuy nhiên, một số hành động như thanh toán, xóa dữ liệu, triển khai hệ thống hoặc sửa đổi các hệ thống đang vận hành thực tế là những thao tác không thể hoàn tác; trong trường hợp này, cái giá phải trả cho một sai sót sẽ lớn hơn nhiều so với lợi ích về tốc độ mà tự động hóa mang lại.

Một biện pháp kiểm soát thực tế là thiết lập quy trình phê duyệt thủ công đối với các hành động vượt quá một ngưỡng xác định trước. Agent có thể soạn thảo hành động, chuẩn bị dữ liệu cần thiết và đưa yêu cầu vào hàng đợi, nhưng việc thực thi chỉ diễn ra sau khi có sự phê duyệt rõ ràng từ con người.

Một quy tắc mặc định hữu ích là: Bất kỳ hành động nào không thể hoàn tác nếu không tốn nhiều công sức, hoặc bất kỳ hành động nào tác động đến hệ thống đang vận hành thực tế, đều cần một checkpoint. Đây là quyết định có chủ đích nhằm duy trì sự tham gia của con người trong quy trình ra quyết định, chứ không phải là hạn chế của bản thân công nghệ.

Ngược lại, việc phê duyệt mọi hành động cũng là một sai lầm. Nếu hệ thống yêu cầu phê duyệt cho mọi lệnh gọi, người dùng sẽ hình thành thói quen nhấn "phê duyệt" một cách máy móc. Áp dụng cơ chế mặc định từ chối: Cho phép các thao tác đọc, nhưng chỉ yêu cầu xác nhận đối với những thao tác ghi, gửi, xóa hoặc chi tiêu. Nhờ đó, số lượng thông báo yêu cầu xác nhận được giảm bớt, giúp người dùng có đủ thời gian và sự chú tâm để xem xét từng yêu cầu.

Mỗi biện pháp nêu trên đều có thể được một kỹ sư triển khai trên một thiết bị duy nhất. Tuy nhiên, việc áp dụng các biện pháp này trên quy mô toàn tổ chức lại là một vấn đề khác; bởi lẽ, bất kỳ biện pháp nào mà một cá nhân có thể tự kích hoạt thì cũng chính cá nhân đó có thể tự tắt đi.

Triển khai AI agent an toàn là vấn đề về quản lý định danh

Các tổ chức thực hiện tốt việc bảo mật cho AI agent đều hiểu rõ bản chất thực sự của chúng: Đó là các thực thể đã được xác thực, sở hữu thông tin xác thực, có khả năng thực hiện các thao tác trên hệ thống, và đòi hỏi một cơ chế quản trị tương xứng với thực tế đó.

Trên thực tế, điều này bao gồm: Áp dụng các biện pháp kiểm soát định danh cho mọi agent tương tác với hệ thống (sử dụng thông tin xác thực duy nhất, xác định rõ chủ sở hữu, theo dõi vòng đời); quét code do các agent tạo ra, những câu lệnh (prompt) mà chúng nhận được, cũng như các cấu hình mà chúng sử dụng để vận hành; lập danh mục các MCP server đã cài đặt trong môi trường phát triển cùng với phạm vi truy cập của từng server; và thiết lập các điểm kiểm soát do con người thực hiện đối với những quyết định không thể đảo ngược.

Tốc độ triển khai và tính bảo mật không hề loại trừ lẫn nhau. Tuy nhiên, việc coi các AI agent chỉ như những chatbot thông thường trong khi vẫn cấp cho chúng quyền truy cập ở cấp độ tài khoản dịch vụ là một sự sai lệch nghiêm trọng – đây chính là nguyên nhân dẫn đến các sự cố đã nêu ở trên.

Như Chris Hughes từ Resilient Cyber ​​đã nhận định khi xem xét dữ liệu về các sự cố thực tế từ OWASP: "Đã đến lúc ngừng coi việc lựa chọn mô hình là quyết định bảo mật quan trọng nhất; thay vào đó, hãy xem AI agent harness như một loại tài sản mà đội ngũ bảo mật cần phải nắm rõ".

Harness ở đây chính là môi trường mà AI agent hoạt động, bao gồm các thông tin xác thực, quyền hạn và những công cụ được tích hợp. Điều này đòi hỏi phải lập danh mục, chỉ định chủ sở hữu và thực thi các biện pháp kiểm soát một cách chặt chẽ, thay vì chỉ hy vọng rằng bản thân mô hình AI sẽ tự từ chối những chỉ dẫn sai lệch.