Tác nhân AI tạo ra những rủi ro bảo mật mới cho doanh nghiệp như thế nào? Tìm hiểu về lệnh gọi công cụ và ranh giới quyền hạn

Ngày 3 tháng 11 năm 2026, Binance đã công bố Tuyên bố điều tra sơ bộ về sự cố bảo mật xảy ra vào ngày 29 tháng 10. Tuyên bố này cho biết kẻ tấn công đã xâm phạm thiết bị của các kỹ sư bằng phần mềm độc hại và sử dụng các công cụ AI nội bộ để tiếp tục mở rộng quyền truy cập. Theo tuyên bố, cuộc tấn công cuối cùng đã dẫn đến việc truy cập trái phép vào dịch vụ ký ví nội bộ, ảnh hưởng đến khoảng 6,34 tỷ USD tài sản số. Tuy nhiên, tuyên bố không công bố kiến trúc hoàn chỉnh của các công cụ AI nội bộ, cũng không xác nhận rằng cuộc tấn công đã khai thác lỗ hổng của chính mô hình ngôn ngữ lớn hoặc có liên quan đến tiêm lệnh.

Sự cố này đặt ra một câu hỏi quan trọng về bảo mật doanh nghiệp: Khi một AI Agent có thể truy cập nhiều công cụ nội bộ và hệ thống nhạy cảm hơn, doanh nghiệp nên phân biệt như thế nào giữa quyền xử lý thông tin và quyền vận hành thực tế? Bắt đầu từ cách AI Agent gọi công cụ, bài viết này giải thích các ranh giới quyền hạn, tiêm lệnh, quản lý thông tin xác thực và rủi ro di chuyển ngang, đồng thời phân tích các biện pháp kiểm soát bảo mật mà doanh nghiệp có thể áp dụng.

Những điểm chính

• AI Agent có thể làm nhiều việc hơn ngoài tạo văn bản. Chúng cũng có thể thực thi mã, đọc tệp, truy cập API hoặc vận hành các hệ thống nội bộ của doanh nghiệp thông qua lệnh gọi công cụ.

• Tuyên bố điều tra sơ bộ của Binance, được công bố vào ngày 3 tháng 11 năm 2026, cho biết kẻ tấn công đã sử dụng thiết bị bị xâm phạm của các kỹ sư và các công cụ AI nội bộ để tiếp tục truy cập vào thiết bị và quyền hạn của những kỹ sư khác.

• Một trong các rủi ro bảo mật cốt lõi của AI Agent là chuyển đổi thông tin từ môi trường bên ngoài hoặc môi trường có độ tin cậy thấp thành các hành động có quyền thực thi thực tế.

• Tiêm lệnh, đầu ra công cụ độc hại, quyền hạn quá mức và rò rỉ thông tin xác thực có thể kết hợp và làm trầm trọng thêm lẫn nhau. Tuy nhiên, không phải mọi cuộc tấn công liên quan đến công cụ AI đều là cuộc tấn công tiêm lệnh.

• Doanh nghiệp cần coi AI Agent là các thực thể thực thi phần mềm có danh tính và quyền hạn cụ thể, đồng thời kiểm soát rủi ro thông qua nguyên tắc đặc quyền tối thiểu, cô lập công cụ, phê duyệt thao tác và cơ chế kiểm toán.

AI Agent khác với chatbot AI truyền thống như thế nào?

Chatbot AI truyền thống chủ yếu hoàn thành nhiệm vụ bằng cách tiếp nhận dữ liệu đầu vào từ người dùng và tạo phản hồi dưới dạng văn bản. Ngay cả khi một mô hình có thể cung cấp mã, phân tích tệp hoặc giải thích các bước vận hành, mô hình đó thường không thể trực tiếp sửa đổi cơ sở dữ liệu doanh nghiệp, triển khai ứng dụng hoặc gọi dịch vụ nội bộ nếu không được kết nối với một môi trường thực thi thực tế.

Điểm khác biệt của AI Agent là chúng có thể kết nối các quyết định do mô hình tạo ra với các công cụ bên ngoài. Ví dụ, nhà phát triển có thể cấu hình cho một Agent các công cụ tìm kiếm mã, thực thi trong terminal, truy vấn cơ sở dữ liệu và quản lý kho lưu trữ Git. Khi người dùng gửi một nhiệm vụ, Agent trước tiên có thể truy xuất các tệp liên quan, sau đó gọi công cụ để lấy thông tin và tiếp tục quyết định bước tiếp theo dựa trên kết quả. Với các quyền hạn phù hợp, Agent thậm chí có thể tạo commit mã, kích hoạt kiểm thử hoặc thực hiện quy trình triển khai.

Mô hình này chuyển AI Agent từ một công cụ tạo thông tin đơn thuần thành một hệ thống phần mềm có một số năng lực vận hành nhất định. Bản thân Agent có thể không có đặc quyền quản trị viên độc lập, nhưng có thể có khả năng truy cập hệ thống bên ngoài thông qua sự ủy quyền của người dùng, tài khoản dịch vụ, API Token hoặc các thông tin xác thực danh tính khác.

Do đó, không thể đánh giá bảo mật AI Agent chỉ dựa trên việc phản hồi của mô hình có chính xác hay không. Ngay cả khi nội dung do mô hình tạo ra không có lỗi rõ ràng, Agent vẫn có thể thực hiện các thao tác vượt ngoài kỳ vọng của người dùng nếu quyền công cụ được cấu hình không phù hợp. Doanh nghiệp không chỉ cần tập trung vào những gì AI tạo ra, mà còn cần chú ý đến những gì AI có thể đọc, có thể gọi và những thao tác nào thực sự có thể thay đổi trạng thái hệ thống.

AI Agent gọi công cụ như thế nào?

Gọi công cụ là một cơ chế quan trọng để AI Agent tương tác với các hệ thống bên ngoài. Nhà phát triển thường cung cấp cho mô hình tên, mô tả chức năng và cấu trúc tham số của các công cụ có sẵn. Sau đó, mô hình sẽ xác định có gọi một công cụ cụ thể hay không dựa trên nhiệm vụ hiện tại. Việc thực thi thực tế thường do môi trường thời gian chạy hoặc ứng dụng của Agent thực hiện, sau đó kết quả của công cụ được cung cấp cho mô hình để xử lý thêm.

Ví dụ, một Agent phát triển nội bộ của doanh nghiệp có thể đọc kho mã, truy vấn nhật ký lỗi và chạy kiểm thử. Khi người dùng yêu cầu điều tra một sự cố của dịch vụ, Agent có thể gọi công cụ truy vấn nhật ký để xác định vấn đề, đọc mã liên quan và sau đó tạo các đề xuất sửa đổi. Nếu doanh nghiệp cũng cấp quyền viết mã hoặc triển khai, Agent có thể chuyển từ việc hỗ trợ phân tích sang thực hiện các thao tác thực tế.

Rủi ro của việc gọi công cụ chủ yếu đến từ hai khía cạnh.

• Agent có thể nhận được quyền thực thi quá mức. Ví dụ, Agent có thể chỉ cần đọc nhật ký nhưng lại có cả khả năng sửa đổi cấu hình môi trường sản xuất.

• Agent có thể xử lý nội dung không đáng tin cậy từ các trang web bên ngoài, bình luận mã, email hoặc đầu ra của công cụ. Nếu hệ thống không phân biệt đúng nội dung này với sự ủy quyền thực tế của người dùng, thông tin bên ngoài có thể ảnh hưởng đến các lệnh gọi công cụ tiếp theo.

Điều này có nghĩa là doanh nghiệp không thể chỉ coi các lệnh gọi công cụ do mô hình tạo ra là các thao tác đáng tin cậy. Mọi lệnh gọi công cụ liên quan đến dữ liệu nhạy cảm hoặc thay đổi hệ thống đều cần được xác minh quyền hạn một cách độc lập. Mô hình có thể gửi yêu cầu thực thi, nhưng việc yêu cầu đó có được phép hay không cần được quyết định bởi các chính sách bảo mật rõ ràng.

Tại sao AI Agent có thể mở rộng bề mặt tấn công của doanh nghiệp?

Các hệ thống bảo mật doanh nghiệp truyền thống thường thiết lập kiểm soát truy cập dựa trên danh tính nhân viên, máy chủ, ứng dụng và ranh giới mạng. Những nhân viên khác nhau có các quyền hệ thống khác nhau, trong khi các dịch vụ quan trọng có thể hạn chế truy cập thông qua thông tin xác thực riêng biệt và quy tắc mạng. Khi AI Agent được kết nối với hệ thống doanh nghiệp, chúng thực tế tạo ra các đường dẫn truy cập tự động mới.

Ví dụ, một Agent phát triển có thể đồng thời kết nối với kho lưu trữ Git, cơ sở tri thức nội bộ, nền tảng đám mây và hệ thống quản lý công việc. Để hoàn thành nhiệm vụ trên nhiều hệ thống, nhà phát triển có thể cấu hình nhiều API Token hoặc tài khoản dịch vụ. Nếu các thông tin xác thực này không bị hạn chế chặt chẽ, kẻ tấn công kiểm soát được môi trường thời gian chạy hoặc danh tính liên quan của Agent có thể sử dụng các năng lực truy cập đó để tiếp cận nhiều hệ thống hơn.

Một vấn đề khác là tốc độ vận hành. Nhân viên thường cần đăng nhập thủ công vào nhiều nền tảng để hoàn thành một chuỗi thao tác, trong khi AI Agent có thể liên tục gọi công cụ trong một khoảng thời gian ngắn. Tự động hóa vốn không phải là không an toàn. Tuy nhiên, nếu không có giới hạn tốc độ, phát hiện bất thường và phê duyệt đối với các thao tác rủi ro cao, các chỉ dẫn sai hoặc độc hại có thể được thực thi nhanh chóng.

Do đó, AI Agent không chỉ mở rộng số lượng giao diện phần mềm mà còn mở rộng các mối quan hệ quyền hạn kết nối những hệ thống khác nhau. Doanh nghiệp cần đánh giá Agent có thể truy cập những tài nguyên nào, liệu Agent có thể vượt qua các miền bảo mật khác nhau hay không và liệu có các đường dẫn từ công cụ rủi ro thấp đến hệ thống rủi ro cao hay không.

Tại sao tiêm lệnh có thể ảnh hưởng đến lệnh gọi công cụ của AI Agent?

Tiêm lệnh là một hình thức tấn công trong đó kẻ tấn công đặt nội dung mang tính chỉ dẫn vào dữ liệu mà mô hình có thể đọc, nhằm thay đổi nhiệm vụ mà mô hình được yêu cầu thực hiện. Đối với chatbot thông thường, các cuộc tấn công này có thể dẫn đến phản hồi không chính xác hoặc tiết lộ thông tin. Đối với AI Agent có khả năng gọi công cụ, chúng cũng có thể ảnh hưởng đến các thao tác thực tế.

Ví dụ, một doanh nghiệp có thể sử dụng AI Agent để tự động sắp xếp các báo cáo sự cố trong kho mã. Nếu kẻ tấn công có thể kiểm soát nội dung của một báo cáo, họ có thể chèn các chỉ dẫn được ngụy trang thành yêu cầu bảo trì hệ thống, khiến Agent đọc thêm tệp hoặc gọi các công cụ không liên quan. Rủi ro thực sự không nằm ở việc Agent đọc báo cáo, mà là liệu Agent có coi nội dung không đáng tin cậy trong báo cáo là chỉ dẫn có thẩm quyền thực thi hay không.

Các cuộc tấn công này thường được gọi là tiêm lệnh gián tiếp. Kẻ tấn công không cần gửi lệnh trực tiếp cho người dùng của Agent. Thay vào đó, kẻ tấn công có thể tác động đến Agent thông qua trang web, tài liệu, bình luận mã, kết quả tìm kiếm hoặc đầu ra công cụ. OWASP liệt kê tiêm lệnh, lạm dụng công cụ, leo thang đặc quyền và tiết lộ thông tin nhạy cảm là các rủi ro bảo mật quan trọng đối với AI Agent.

Tuy nhiên, cần phân biệt tiêm lệnh với các cuộc tấn công bằng phần mềm độc hại truyền thống. Nếu kẻ tấn công đã kiểm soát máy tính của kỹ sư thông qua mã độc và sau đó sử dụng thông tin xác thực hiện có để truy cập hệ thống nội bộ, việc đường dẫn tấn công có liên quan đến một công cụ AI không nhất thiết đồng nghĩa với việc đã xảy ra tiêm lệnh. Hai cơ chế này có thể xuất hiện cùng nhau, nhưng chúng khác nhau về mặt kỹ thuật.

Sự cố bảo mật của Binance cho thấy những rủi ro nào đối với công cụ AI và quản lý quyền hạn?

Trong tuyên bố điều tra sơ bộ được công bố vào ngày 3 tháng 11 năm 2026, Binance đã tiết lộ một cuộc tấn công nhiều giai đoạn, tiến triển từ việc xâm phạm thiết bị của nhân viên đến lạm dụng hệ thống ký ví nội bộ. Theo tuyên bố, vào tháng 9, kẻ tấn công đã dụ một kỹ sư phần mềm tải xuống kho lưu trữ chứa mã độc thông qua một cuộc phỏng vấn xin việc giả mạo. Mã độc được thực thi trong quá trình cấu hình môi trường và thiết lập các kênh liên lạc do kẻ tấn công kiểm soát bằng cách thay thế các thành phần của công cụ phát triển và sử dụng các phương thức khác.

Vào ngày 20 tháng 10, kẻ tấn công đã sử dụng máy tính của một kỹ sư bị xâm phạm và các công cụ AI nội bộ để kiểm soát thiết bị của các kỹ sư khác. Họ cũng phát hiện một Token quyền triển khai container trên thiết bị của một kỹ sư vận hành ví. Vào ngày 29 tháng 10, kẻ tấn công đã sử dụng thông tin xác thực liên quan để triển khai container và kích hoạt các tập lệnh độc hại, cuối cùng tiếp cận quy trình vận hành ký ví.

Từ góc độ kiến trúc bảo mật, sự cố này phản ánh ít nhất ba vấn đề đáng nghiên cứu. Thứ nhất, thiết bị của nhà phát triển có thể trở thành điểm xâm nhập vào các hệ thống nội bộ có giá trị cao. Thứ hai, khi các công cụ AI nội bộ, môi trường triển khai và quyền hạn của nhân viên được kết nối, kẻ tấn công có thể khai thác các kết nối này để mở rộng quyền truy cập. Cuối cùng, nếu các thao tác rủi ro cao không có đủ cơ chế xác minh quyền hạn độc lập, kẻ tấn công có thể chuyển đổi các quyền nội bộ mà họ có được thành khả năng thực hiện các thao tác tài sản thực tế.

Cần nhấn mạnh rằng Binance chưa công bố phương thức triển khai cụ thể của các công cụ AI nội bộ. Do đó, không thể xác nhận liệu các công cụ này có phải là AI Agent với năng lực lập kế hoạch tự chủ hay không, cũng không thể kết luận rằng cuộc tấn công có liên quan đến MCP, tiêm lệnh hoặc lỗ hổng trong một mô hình cụ thể. Sự cố cho thấy công cụ AI có thể là một phần của đường dẫn tấn công phức tạp, nhưng bản thân điều đó không chứng minh rằng AI Agent là nguyên nhân gốc rễ của cuộc tấn công.

Ranh giới quyền hạn của AI Agent là gì? Tại sao đặc quyền tối thiểu lại quan trọng?

Ranh giới quyền hạn xác định một thực thể phần mềm có thể truy cập tài nguyên nào, có thể thực hiện những thao tác nào và có thể nhận thêm quyền hạn trong những điều kiện nào. Đối với AI Agent, ranh giới quyền hạn không chỉ liên quan đến bản thân mô hình mà còn liên quan đến môi trường thời gian chạy của Agent, giao diện công cụ, danh tính người dùng, tài khoản dịch vụ và các hệ thống bên ngoài.

Nguyên tắc đặc quyền tối thiểu yêu cầu hệ thống chỉ cấp các quyền cần thiết để hoàn thành nhiệm vụ hiện tại. Ví dụ, một Agent chịu trách nhiệm phân tích nhật ký máy chủ thường chỉ cần truy cập dữ liệu nhật ký cụ thể. Agent không nên tự động có khả năng xóa cơ sở dữ liệu, sửa đổi môi trường sản xuất hoặc chuyển tài sản số. Nếu một nhiệm vụ thực sự cần thao tác rủi ro cao, Agent nên nhận quyền tạm thời thông qua cơ chế ủy quyền độc lập.

OWASP liệt kê quyền tự chủ quá mức là một rủi ro quan trọng trong các ứng dụng mô hình ngôn ngữ lớn. Vấn đề cốt lõi không phải là mô hình có khả năng gọi công cụ, mà là hệ thống đã cấp cho mô hình các chức năng không cần thiết, quyền hạn quá mức hoặc khả năng vận hành tự chủ không bị hạn chế. Khi mô hình chịu ảnh hưởng của dữ liệu đầu vào không chính xác, tiêm lệnh hoặc kết quả công cụ độc hại, các quyền hạn này có thể làm tăng thiệt hại tiềm ẩn.

Do đó, doanh nghiệp cần đặt việc kiểm tra quyền hạn trong môi trường thực thi đáng tin cậy thay vì chỉ yêu cầu Agent qua lời nhắc hệ thống rằng không được thực hiện các thao tác nguy hiểm. Ngay cả khi một mô hình yêu cầu nhầm quyền truy cập vào công cụ nhạy cảm, dịch vụ phụ trợ vẫn phải có khả năng từ chối yêu cầu trái phép dựa trên danh tính, phạm vi tài nguyên và loại thao tác.

Các giao thức kết nối công cụ như MCP có thể tạo ra những thách thức bảo mật mới nào?

Model Context Protocol (MCP) là một giao thức mở để kết nối các ứng dụng AI với công cụ bên ngoài và tài nguyên dữ liệu. Thông qua MCP, nhà phát triển có thể kết nối AI Agent với hệ thống tệp, cơ sở dữ liệu, kho mã và các dịch vụ khác mà không cần thiết kế phương thức tích hợp hoàn toàn khác nhau cho từng công cụ.

Phương thức kết nối chuẩn hóa này có thể cải thiện hiệu quả phát triển, nhưng cũng có nghĩa là Agent có thể dễ dàng truy cập nhiều hệ thống bên ngoài hơn. Nếu doanh nghiệp không quản lý MCP Server, định nghĩa công cụ và quyền truy cập, doanh nghiệp có thể gặp phải các vấn đề như quyền công cụ quá mức, mô tả công cụ độc hại, dịch vụ bên thứ ba bị xâm phạm hoặc vô tình làm lộ thông tin nhạy cảm.

Ví dụ, một Agent phát triển có thể cần đọc kho mã nhưng không cần truy cập hệ thống thanh toán của doanh nghiệp. Nếu cả hai loại công cụ được cấu hình trong cùng một môi trường thời gian chạy và sử dụng thông tin xác thực dùng chung với quyền hạn cấp cao, Agent ban đầu được thiết kế để hỗ trợ phát triển có thể có được năng lực vận hành không liên quan đến nhiệm vụ của mình.

OWASP khuyến nghị thiết lập cơ chế kiểm toán đối với các MCP Server được kết nối với công cụ lập trình AI, hạn chế các công cụ có thể được gọi và kiểm tra xem định nghĩa công cụ có chứa chỉ dẫn độc hại hay không. Các Agent thực thi mã cũng nên áp dụng những biện pháp như môi trường hộp cát, hạn chế truy cập mạng và quản lý thông tin xác thực độc lập.

Bản thân MCP không tạo thành một lỗ hổng bảo mật. Điều cần được đánh giá là cách triển khai công cụ, xác thực, cấu hình quyền hạn và cách nội dung bên ngoài ảnh hưởng đến hành vi của Agent sau khi giao thức được kết nối.

Doanh nghiệp nên bảo vệ danh tính và quyền truy cập của AI Agent như thế nào?

Trước hết, doanh nghiệp nên thiết lập một hệ thống danh tính có thể nhận diện và kiểm toán cho AI Agent. Các ứng dụng truyền thống thường sử dụng tài khoản dịch vụ hoặc API Key để truy cập các hệ thống khác. Tuy nhiên, các thao tác của AI Agent có thể đồng thời liên quan đến sự ủy quyền của người dùng, tác vụ tự động và nhiều công cụ. Do đó, doanh nghiệp cần phân biệt rõ danh tính của người dùng, danh tính của Agent và quyền thực thi thực tế.

Ví dụ, việc một nhân viên yêu cầu Agent truy xuất báo cáo nội bộ không có nghĩa là Agent có thể sử dụng tài khoản dịch vụ của mình để đọc các tệp khác mà nhân viên đó không được phép truy cập. Một thiết kế ủy quyền phù hợp cần xác minh cả việc người dùng gửi yêu cầu có được phép truy cập tài nguyên đích hay không và liệu Agent có được phép thực hiện thao tác tương ứng hay không. Điều này giúp ngăn Agent vượt qua các biện pháp kiểm soát truy cập hiện có vì dịch vụ đại diện của Agent có đặc quyền cao hơn.

Vào tháng 2 năm 2026, Trung tâm Xuất sắc về An ninh mạng Quốc gia (NCCoE) trực thuộc Viện Tiêu chuẩn và Công nghệ Quốc gia (NIST) đã công bố một tài liệu khái niệm về danh tính và ủy quyền cho phần mềm và AI Agent. Tài liệu này thảo luận các vấn đề bao gồm nhận diện danh tính Agent, xác thực, ủy quyền, thông tin xác thực tạm thời, quyền được ủy quyền và kiểm toán. Điều này phản ánh việc bảo mật AI Agent đang mở rộng từ kiểm soát đầu ra mô hình sang một khuôn khổ quản lý danh tính và truy cập hoàn chỉnh.

Trong triển khai thực tế, doanh nghiệp có thể sử dụng thông tin xác thực truy cập có thời hạn ngắn và giới hạn quyền đối với các nhiệm vụ, tài nguyên và khoảng thời gian cụ thể. Cần áp dụng phê duyệt độc lập và xác minh thứ cấp đối với các hoạt động rủi ro cao như triển khai môi trường sản xuất, thao tác tài chính và thay đổi quyền hạn. Bằng cách này, ngay cả khi môi trường thời gian chạy của Agent bị xâm phạm, kẻ tấn công có thể không thể trực tiếp lấy được thông tin xác thực dài hạn có đặc quyền cao.

Doanh nghiệp có thể giảm rủi ro bảo mật từ lệnh gọi công cụ của AI Agent như thế nào?

Doanh nghiệp có thể thiết lập biện pháp bảo vệ ở bốn khía cạnh: quyền công cụ, môi trường thực thi, thao tác nhạy cảm và giám sát hành vi.

• Doanh nghiệp nên hạn chế các công cụ mà Agent có thể sử dụng dựa trên yêu cầu nghiệp vụ. Agent chỉ truy xuất thông tin không cần khả năng thực thi mã tùy ý, và Agent dùng để kiểm tra mã không nên tự động nhận quyền triển khai môi trường sản xuất. Đối với các công cụ có khả năng ghi, doanh nghiệp có thể tiếp tục hạn chế đường dẫn tệp, bảng cơ sở dữ liệu, loại thao tác API và phạm vi truy cập.

• Các công cụ rủi ro cao nên chạy trong môi trường cô lập. Việc thực thi mã, cài đặt gói của bên thứ ba và xử lý trang web bên ngoài có thể đưa nội dung không đáng tin cậy vào hệ thống. Do đó, doanh nghiệp có thể sử dụng container hoặc các công nghệ hộp cát khác để hạn chế quyền truy cập vào hệ thống tệp, mạng và tài nguyên hệ thống. Việc cô lập làm giảm khả năng một cuộc tấn công vào một công cụ đơn lẻ ảnh hưởng đến các hệ thống khác.

• Doanh nghiệp nên yêu cầu con người phê duyệt các thao tác không thể đảo ngược. Các thao tác như xóa dữ liệu quan trọng, sửa đổi quyền hạn, triển khai dịch vụ sản xuất hoặc chuyển tài sản không nên được hoàn thành tự động chỉ vì Agent xác định rằng nhiệm vụ là hợp lý. Hướng dẫn bảo mật của Agent Framework từ Microsoft cũng khuyến nghị xác định có cần sự xác nhận của con người hay không dựa trên tác động, độ nhạy cảm của dữ liệu và khả năng đảo ngược của thao tác.

• Cuối cùng, doanh nghiệp cần thiết lập cơ chế kiểm toán liên tục để ghi lại Agent đã sử dụng công cụ nào, truy cập tài nguyên nào, liệu có yêu cầu quyền hạn bất thường hay không và liệu kết quả thực thi thực tế có khớp với nhiệm vụ được ủy quyền hay không. Đối với các lệnh gọi công cụ thất bại lặp lại, truy cập dữ liệu bất thường và số lượng lớn thao tác trong thời gian ngắn, doanh nghiệp có thể kết hợp phát hiện dựa trên quy tắc với phân tích hành vi để nhận diện các rủi ro tiềm ẩn.

Các biện pháp này không thể đảm bảo loại bỏ hoàn toàn rủi ro bảo mật của AI Agent. Tuy nhiên, chúng có thể giảm phạm vi ảnh hưởng sau khi cuộc tấn công thành công và tăng khả năng hành vi bất thường được phát hiện, xử lý.

Tại sao bảo mật AI Agent đang trở thành vấn đề quan trọng đối với hạ tầng Web3?

Sự kết hợp giữa AI Agent và hạ tầng blockchain khiến việc gọi công cụ và quản lý quyền hạn có tác động trực tiếp hơn đến an toàn tài sản. Trong các kịch bản doanh nghiệp truyền thống, Agent có thể thực thi mã, gửi email hoặc sửa đổi cơ sở dữ liệu. Trong các kịch bản Web3, Agent cũng có thể kết nối với ví, truy vấn tài sản trên chuỗi, gọi hợp đồng thông minh hoặc khởi tạo yêu cầu giao dịch.

Ví dụ, một Agent được sử dụng để tự động quản lý tài sản trên chuỗi có thể cần truy vấn số dư, phân tích thị trường và đưa ra đề xuất giao dịch dựa trên thiết lập của người dùng. Nếu Agent cũng nhận được khả năng ký giao dịch hoặc gọi hợp đồng thông minh, doanh nghiệp phải xác định rõ thao tác nào có thể được thực hiện tự động, thao tác nào cần người dùng xác nhận và cách giới hạn số tiền cho mỗi giao dịch, phạm vi tài sản cũng như thời hạn hiệu lực của ủy quyền.

Trong quá trình này, Session Keys, tài khoản thông minh và các cơ chế ủy quyền chi tiết có thể cung cấp các hình thức quản lý quyền hạn khác nhau. Tuy nhiên, tính bảo mật cụ thể của chúng phụ thuộc vào cách triển khai. Session Keys có thể giới hạn một số quyền thao tác trong một khoảng thời gian hoặc phạm vi cụ thể, trong khi tài khoản thông minh có thể hạn chế hành vi giao dịch thông qua các quy tắc hợp đồng. Tuy nhiên, rủi ro bảo mật vẫn có thể phát sinh nếu điều kiện ủy quyền quá rộng, logic xác thực có lỗi hoặc môi trường thực thi bị xâm phạm.

Do đó, việc phát triển AI Agent Web3 không thể chỉ tập trung vào hiệu quả của giao dịch tự động hoặc thanh toán trên chuỗi. Việc này cũng phải giải quyết vấn đề xác minh danh tính, ủy quyền quyền hạn, phê duyệt giao dịch và thu hồi ủy quyền. Đối với các hệ thống AI được kết nối với tài sản thực, ranh giới bảo mật cần bao phủ toàn bộ quy trình từ quyết định của mô hình đến lệnh gọi công cụ, xây dựng giao dịch, xác minh chữ ký và thực thi trên chuỗi.

Kết luận

AI Agent đang thay đổi cách doanh nghiệp sử dụng trí tuệ nhân tạo. Khi các mô hình được kết nối với kho mã, API nội bộ, cơ sở dữ liệu và công cụ tự động hóa, các hệ thống AI không còn chỉ là điểm truy cập để xử lý thông tin. Chúng ngày càng trở thành các thực thể thực thi phần mềm có năng lực vận hành thực tế.

Cuộc điều tra sơ bộ của Binance về sự cố bảo mật được công bố vào ngày 3 tháng 11 năm 2026 cho thấy các công cụ AI nội bộ có thể đã xuất hiện trong một đường dẫn tấn công phức tạp. Tuy nhiên, thông tin hiện có không đủ để chứng minh rằng sự cố trực tiếp do lỗ hổng AI Agent hoặc tiêm lệnh gây ra. Bài học quan trọng hơn là doanh nghiệp cần đánh giá lại các mối quan hệ truy cập giữa môi trường phát triển, công cụ tự động hóa và các hệ thống có đặc quyền cao.

Trong tương lai, bảo mật AI Agent sẽ không chỉ phụ thuộc vào việc mô hình có thể nhận diện chỉ dẫn độc hại hay không, mà còn phụ thuộc vào việc doanh nghiệp có thể thiết lập cơ chế xác thực danh tính đáng tin cậy, đặc quyền tối thiểu, cô lập công cụ và phê duyệt độc lập hay không. Chỉ bằng cách tách biệt phù hợp năng lực ra quyết định của AI với quyền thực thi thực tế, doanh nghiệp mới có thể kiểm soát các rủi ro tiềm ẩn trong khi cải thiện hiệu quả tự động hóa.

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

Tại sao AI Agent có nhiều rủi ro bảo mật hơn chatbot thông thường?

AI Agent có thể truy cập dữ liệu doanh nghiệp, thực thi mã hoặc sửa đổi hệ thống thông qua lệnh gọi công cụ. So với chatbot chỉ tạo văn bản, lỗi hoặc hành vi bị thao túng của AI Agent có thể tạo ra hậu quả vận hành thực tế.

Gọi công cụ của AI Agent là gì?

Gọi công cụ là việc AI Agent yêu cầu một chương trình hoặc dịch vụ bên ngoài thực hiện thao tác dựa trên yêu cầu của nhiệm vụ, chẳng hạn như truy vấn cơ sở dữ liệu, đọc tệp, gọi API hoặc chạy mã.

Tiêm lệnh có phải lúc nào cũng có thể kiểm soát AI Agent không?

Không nhất thiết. Việc tiêm lệnh có thành công hay không phụ thuộc vào thiết kế hệ thống, hành vi mô hình và các biện pháp kiểm soát bảo mật. Ngay cả khi kẻ tấn công tác động đến đầu ra của mô hình, việc xác minh quyền hạn độc lập vẫn có thể ngăn các thao tác công cụ trái phép.

Sự cố bảo mật của Binance có chứng minh AI Agent có lỗ hổng không?

Không. Cuộc điều tra sơ bộ của Binance xác nhận rằng đường dẫn tấn công có liên quan đến các công cụ AI nội bộ, nhưng không công bố bằng chứng kỹ thuật đủ để xác lập sự tồn tại của lỗ hổng AI Agent hoặc tiêm lệnh.

MCP có làm tăng rủi ro bảo mật của AI Agent không?

MCP có thể giúp các ứng dụng AI kết nối với công cụ bên ngoài, nhưng các rủi ro bảo mật chủ yếu đến từ việc triển khai công cụ, quyền truy cập và cách xử lý nội dung không đáng tin cậy. Xác thực phù hợp, kiểm toán công cụ và hạn chế quyền hạn có thể giảm các rủi ro này.

Doanh nghiệp nên hạn chế quyền của AI Agent như thế nào?

Doanh nghiệp có thể sử dụng đặc quyền tối thiểu, thông tin xác thực tạm thời theo từng nhiệm vụ, phê duyệt thao tác độc lập, cô lập hộp cát và kiểm toán lệnh gọi công cụ để bảo đảm Agent chỉ có thể thực hiện các thao tác được ủy quyền rõ ràng.