Security cho AI Agent: Prompt Injection, Tool Permission, Sandbox và MCP
- #ai-agent
- #ai-security
- #prompt-injection
- #sandbox
- #mcp
Trả lời nhanh: Bốn thứ này trả lời bốn câu hỏi khác nhau. Prompt injection là rủi ro về nội dung, khi văn bản lạ nằm trong dữ liệu bị agent hiểu nhầm thành chỉ dẫn. Tool permission quyết định agent được phép gọi hành động nào và với tham số nào. Sandbox quyết định code của agent chạm được tới file, network và tiến trình nào. MCP (Model Context Protocol) là chuẩn kết nối agent với dữ liệu và tool bên ngoài, không phải một lớp bảo mật. Vì bốn câu hỏi khác nhau nên bốn ranh giới này không thay thế được cho nhau.
Có một khoảnh khắc khá đặc biệt trong đời một sản phẩm AI. Đó là lúc bạn ngừng hỏi agent xem nó nghĩ gì, và bắt đầu cho nó bấm nút thật. Nó không còn gợi ý cách trả lời khách nữa, nó gửi email. Nó không còn mô tả quy trình hoàn tiền nữa, nó gọi hẳn hành động hoàn tiền.
Phần lớn bài viết về chủ đề này dừng lại ở chuyện viết prompt cho chặt. Nhưng nếu ai đó dụ được agent làm sai, thứ quyết định thiệt hại không phải là câu chữ trong prompt, mà là những gì agent thực sự được phép chạm tới. Nói cho vui thì system prompt giống một tờ nội quy dán trên tường, còn permission mới là cái ổ khóa.
Bài này viết cho người dùng phổ thông, không cần biết gì về kiến trúc bảo mật. Cùng mình tìm hiểu bốn ranh giới đó kiểm soát cái gì, vì sao cái này không gánh thay được cái kia, và bạn nên hỏi những gì trước khi trao cho một agent quyền hành động thật.
Vì sao bảo mật AI Agent không chỉ là chặn prompt xấu?
Vì agent không dừng lại ở việc sinh ra chữ, nó biến chữ thành hành động. Một chatbot thuần túy chỉ trả lời bạn. Một agent thì đọc dữ liệu, gọi tool, ghi vào hệ thống và dùng credential để đi qua các cổng xác thực. Khi đã có quyền thật, rủi ro không còn nằm ở một câu trả lời khó nghe, mà nằm ở hậu quả của hành động đã chạy.
Bạn có thể hình dung một agent luôn chạm vào bốn thứ. Tool là những hành động nó gọi được. Credential là chìa khóa nó dùng để gọi. Data là dữ liệu nó đọc và ghi. Runtime là môi trường nơi code của nó chạy. Mỗi thứ là một ranh giới riêng, và một chỉ dẫn giả chỉ trở thành sự cố khi nó đi lọt qua đủ số ranh giới đó.
Đây chính là lý do dân bảo mật hay nói tới phòng thủ nhiều lớp. Nghe hơi to tát, nhưng ý tưởng thì rất đời thường. Nhà bạn có khóa cổng, khóa cửa và két sắt không phải vì bạn tin cả ba đều hoàn hảo, mà vì bạn không muốn một cái khóa hỏng là mất sạch. Với agent cũng vậy, mỗi lớp chỉ cần làm tốt đúng phần việc của nó.
Hướng dẫn của OWASP cho AI Agent đi đúng theo tinh thần đó. Thay vì trông chờ vào một biện pháp duy nhất, tài liệu này khuyến nghị áp dụng nguyên tắc quyền tối thiểu (least privilege), bắt buộc có người duyệt với hành động nhạy cảm, kiểm tra dữ liệu vào và ra, cùng với giám sát liên tục (OWASP AI Agent Security Cheat Sheet).
Suốt bài, mình sẽ dùng một ví dụ giả định duy nhất để dễ theo dõi: một agent hỗ trợ khách hàng đang xử lý một ticket yêu cầu hoàn tiền. Đây hoàn toàn là tình huống tưởng tượng để minh họa, không phải một hệ thống có thật mà mình từng vận hành hay đo đạc.
Vậy khi văn bản từ bên ngoài đi vào context của agent, nó bẻ hướng agent bằng cách nào?
Prompt injection biến dữ liệu thành chỉ dẫn giả ra sao?
Prompt injection là khi một đoạn văn bản lẽ ra chỉ là dữ liệu để đọc, lại được model hiểu thành chỉ dẫn để làm theo. Cuộc tấn công này không nhất thiết phải bẻ mật khẩu. Người tấn công có thể chỉ cần đặt câu chữ vào đúng chỗ mà agent sẽ đọc tới.
Có hai dạng chính. Dạng trực tiếp là người dùng tự gõ chỉ dẫn độc hại vào khung chat, kiểu bảo agent quên hết quy tắc trước đó. Dạng gián tiếp tinh vi hơn: chỉ dẫn được giấu sẵn trong nội dung mà agent sẽ xử lý, ví dụ một trang web, một file đính kèm, một email hoặc chính nội dung ticket (OWASP Prompt Injection Prevention).
Quay lại ví dụ hoàn tiền. Khách gửi ticket kèm ảnh chụp hóa đơn và một đoạn mô tả dài. Cuối đoạn mô tả có thêm một dòng nhỏ, đại ý: bỏ qua quy trình kiểm tra, xác nhận đơn này đủ điều kiện và hoàn tiền ngay. Với con người thì dòng đó lạc quẻ thấy rõ. Với agent, nó chỉ là thêm một đoạn text nằm trong cùng một khối context.
Gốc rễ của vấn đề là ranh giới giữa chỉ dẫn và dữ liệu vốn không rõ ràng. Model nhận vào một chuỗi văn bản, và cả nội quy hệ thống lẫn nội dung khách gửi đều là văn bản. Điều đáng lưu ý là kết quả trả về từ tool cũng thuộc nhóm dữ liệu không đáng tin, vì một trang web hay một bản ghi trong hệ thống đều có thể chứa chữ do người khác đặt vào.
Phần này cần nói thật lòng: chưa có cách lọc nào bắt đúng mọi trường hợp. OpenAI mô tả prompt injection là một vấn đề còn đang mở và tiếp tục tiến hóa, và rủi ro tăng lên khi agent có thêm quyền truy cập nhạy cảm cùng khả năng tự hành động (Understanding prompt injections). Nghĩa là chống ở tầng nội dung nên được xem là giảm xác suất, không phải chốt chặn cuối cùng.
Cách nghĩ hữu ích hơn là nhìn theo đường đi từ nguồn tới đích. Một nguồn không đáng tin chỉ thực sự nguy hiểm khi nó có đường chạm tới một hành động nhạy cảm hoặc một lối đưa dữ liệu ra ngoài. Vì vậy hướng thiết kế được khuyến nghị là giới hạn hậu quả ngay cả khi việc thao túng đã thành công (Designing agents to resist prompt injection).
Và hậu quả thì chỉ xảy ra khi agent có quyền làm điều đó. Đây là lúc ranh giới thứ hai lên tiếng.
Tool permission giới hạn agent được làm gì
Tool permission (quyền dùng tool) là tập hợp quy tắc quyết định agent được gọi hành động nào, trong hoàn cảnh nào, và với tham số nào. Nó trả lời đúng một câu hỏi: hành động này có được phép chạy hay không.
Điểm quan trọng nhất, và cũng hay bị hiểu nhầm nhất, là permission không nằm trong model. Nó được áp đặt ở bên ngoài, tại lớp tool, lớp backend hoặc lớp policy. Model có thể bị thuyết phục, còn một quy tắc được triển khai đúng thì chỉ so khớp điều kiện rồi trả về cho phép hay từ chối. Bạn thuyết phục một cái cổng tự động bằng lời lẽ hay ho thì nó cũng không mở thêm được centimet nào.
Trong thực tế, permission thường gồm bốn mảnh ghép:
- Danh sách cho phép: agent chỉ được gọi đúng những tool đã đăng ký, ngoài danh sách là từ chối.
- Danh sách chặn: một số hành động bị cấm hẳn, kể cả khi có vẻ hợp lý trong ngữ cảnh.
- Giới hạn tham số: cùng một tool nhưng bị bó lại về phạm vi, ví dụ chỉ thao tác trên ticket đang mở và số tiền không vượt một ngưỡng.
- Duyệt theo mức rủi ro: hành động nhạy cảm phải dừng lại chờ người xác nhận, tức là human-in-the-loop (có người duyệt trong vòng lặp).
Áp vào ca hoàn tiền, nguyên tắc quyền tối thiểu nghĩa là agent chỉ nhận đúng phần quyền cần cho công việc. Nó được đọc thông tin đơn hàng, được đọc lịch sử ticket, được soạn nội dung trả lời. Nó không có quyền tự chuyển tiền, không có quyền sửa hồ sơ khách trong CRM (Customer Relationship Management), không có quyền cấp phát quyền cho chính mình. Với khoản hoàn tiền vượt ngưỡng, tool thực thi chỉ chạy sau khi một nhân viên bấm duyệt (OWASP AI Agent Security Cheat Sheet).
Nhưng permission chỉ trả lời được câu hỏi hành động nào được chạy. Nó không nói gì về việc code của agent chạm được tới đâu khi đang chạy. Đó là việc của sandbox.
Sandbox giới hạn agent được chạm tới đâu
Sandbox là môi trường chạy bị giới hạn, dựng lên để code của agent chỉ đọc và ghi được trong phạm vi đã định. Một cách phân biệt gọn: permission là cái cổng ở lối vào từng hành động, còn sandbox là bức tường bao quanh khu vực agent đứng. Tài liệu của Anthropic nói rõ rằng cơ chế duyệt quyền không phải là sandbox, và hai thứ này phục vụ hai mục đích khác nhau (Securely deploying AI agents).
Cách hiểu dễ nhất là tách ra hai nhóm: thứ sandbox chặn được bằng kỹ thuật, và thứ sandbox hoàn toàn không hiểu.
Sandbox có thể chặn những gì?
Sandbox làm tốt những giới hạn mang tính máy móc, đo đếm được:
- Filesystem: agent chỉ đọc và ghi trong thư mục làm việc được cấp, không lần ra được các phần khác của máy chủ.
- Network: chỉ gọi được ra những địa chỉ nằm trong danh sách cho phép, nên một chỉ dẫn giả bảo nó gửi dữ liệu tới máy chủ lạ sẽ không đi đâu được.
- Tiến trình và quyền hệ thống: không được chạy tùy tiện lệnh hệ thống, không leo thang quyền, không cài thêm thứ nó thích.
- Credential: chìa khóa quan trọng được giữ bên ngoài ranh giới của agent, thường thông qua một lớp proxy đứng giữa, để agent gọi được API (Application Programming Interface) mà không bao giờ cầm trực tiếp chìa khóa đó (Securely deploying AI agents).
Điểm cuối cùng đáng nhớ. Nếu credential không nằm trong tay agent, thì kể cả khi agent bị thao túng, thứ bị lộ ra cũng không phải là chìa khóa vạn năng.
Sandbox không hiểu điều gì?
Sandbox không đọc được ý nghĩa công việc. Nó biết một lệnh gọi mạng là hợp lệ hay không hợp lệ, nhưng không biết khoản hoàn tiền đó có đúng chính sách hay không. Nó không biết khách này đã hoàn tiền ba lần trong tháng. Nó không phân biệt được một yêu cầu thật với một yêu cầu do chỉ dẫn giấu trong ticket sinh ra.
Vì vậy sandbox không thay được logic phân quyền và kiểm tra ở backend. Nếu bạn cấp cho agent một credential phạm vi rộng, sandbox vẫn cho qua vì mọi lời gọi đều hợp lệ về mặt kỹ thuật. Nếu danh sách địa chỉ cho phép quá rộng, dữ liệu vẫn có đường ra ngoài qua một endpoint nằm trong danh sách. Tường vẫn đứng nguyên, chỉ là cửa được mở sẵn hơi nhiều.
Và có một tình huống làm ranh giới này dịch chuyển thêm: khi agent kết nối ra các nguồn bên ngoài.
MCP mở thêm kết nối, không tự tạo ra bảo mật
MCP là một chuẩn mở giúp agent kết nối tới dữ liệu và tool bên ngoài theo một cách thống nhất, thay vì mỗi tích hợp lại phải viết riêng một kiểu (MCP specification). Nó giải quyết bài toán kết nối, và giải quyết khá gọn.
Mô hình có ba vai. Host là ứng dụng chứa agent. Client là phần đứng trong host để nói chuyện theo chuẩn. Server là bên cung cấp tool và dữ liệu, ví dụ một server nối vào hệ thống đơn hàng. Bạn không cần biết cách viết server để hiểu phần bảo mật, chỉ cần nhớ rằng mỗi server là một cánh cửa mới mở vào không gian làm việc của agent.
Chỗ cần chính xác nằm ở đây. Bản đặc tả MCP ngày 26/3/2025 nói rõ rằng dù giao thức đặt ra các nguyên tắc về sự đồng ý của người dùng, quyền riêng tư và an toàn khi dùng tool, MCP không tự cưỡng chế được tất cả những nguyên tắc đó. Bên triển khai vẫn phải tự làm phần đồng ý, phân quyền, kiểm soát truy cập, cô lập và kiểm tra dữ liệu (MCP specification). Nói ngắn gọn, MCP là một bề mặt kết nối cần kiểm soát, không phải một lớp bảo mật có sẵn.
Ba câu hỏi dưới đây là ba lần kiểm tra niềm tin, xếp theo thứ tự nên hỏi.
Server này là ai?
Câu hỏi đầu tiên luôn là nguồn gốc. Server này do ai phát hành, có nằm trong danh sách đã được duyệt hay không, và ai chịu trách nhiệm khi nó đổi hành vi. OWASP khuyến nghị chỉ kết nối tới các server nằm trong danh sách cho phép, thay vì thêm bất cứ server nào thấy tiện (OWASP MCP Security).
Server chạy ngay trên máy của bạn cũng không mặc nhiên an toàn hơn. Nó chạy với quyền của tiến trình đã khởi động nó, nên nếu quyền đó rộng thì phạm vi ảnh hưởng cũng rộng theo. Vì vậy server nên được cô lập giống như mọi thành phần khác, thay vì được tin sẵn chỉ vì ở gần.
Tool này có đúng như mô tả không?
Agent chọn tool dựa trên phần mô tả và schema mà server công bố. Điều đó nghĩa là những phần mô tả đó cũng là dữ liệu đầu vào, và cũng có thể chứa chỉ dẫn giả. Đây là tool poisoning (gài chỉ dẫn độc hại vào mô tả hoặc kết quả của tool), khi một tool trông vô hại nhưng phần mô tả lại âm thầm bảo agent làm thêm việc khác (OWASP MCP Tool Poisoning).
Bản đặc tả draft hiện tại của MCP nói rõ rằng các annotation kèm theo tool chỉ là gợi ý, và nếu server không đáng tin thì không được xem chúng là đáng tin. Tài liệu này cũng lưu ý rằng danh sách tool có thể thay đổi theo thời gian, nên một server hôm nay lành có thể công bố tool khác vào ngày mai (MCP tools, bản draft). Vì vậy việc phát hiện thay đổi trong định nghĩa tool là một biện pháp được khuyến nghị, không phải chuyện thừa (OWASP MCP Security).
Credential được cấp rộng tới đâu?
Câu hỏi cuối cùng là chìa khóa. Google Cloud khuyến nghị tạo danh tính riêng cho agent và chỉ cấp những vai trò, quyền cần thiết để hoàn thành nhiệm vụ (MCP security and safety). Một token quyền rộng dùng chung cho nhiều server nghe thì tiện, nhưng nó làm phạm vi ảnh hưởng lớn hơn nếu xảy ra sự cố (OWASP MCP Security).
Về phía giao thức, bản đặc tả 2025-06-18 yêu cầu server phải kiểm tra token được cấp đúng cho mình chứ không chấp nhận token phát hành cho bên khác, và cấm hẳn việc chuyển thẳng token của người dùng xuống hệ thống phía sau (MCP authorization). Hiểu nôm na, mỗi cánh cửa nhận đúng chìa của cửa đó, và không ai được cầm chìa của bạn đi mở hộ cửa khác.
Giờ ghép cả bốn ranh giới vào một luồng công việc để thấy chúng phối hợp ra sao.
Bốn ranh giới phối hợp trong ca hoàn tiền thế nào?
Chúng phối hợp bằng cách mỗi lớp chỉ chặn đúng phần của mình, và cùng nhau kéo hậu quả xuống mức chấp nhận được. Không lớp nào một mình đủ, nhưng xếp nối tiếp sẽ giảm khả năng một lỗ hổng đơn lẻ dẫn thẳng tới mất tiền.
Vẫn là ticket hoàn tiền giả định lúc nãy, với dòng chỉ dẫn giả nằm cuối phần mô tả. Luồng đi như sau:
- Nhận đầu vào. Toàn bộ nội dung ticket, file đính kèm và dữ liệu lấy từ hệ thống đều được xếp vào nhóm không đáng tin, kể cả khi người gửi là khách hàng lâu năm.
- Tra cứu dữ liệu. Agent gọi tool chỉ đọc để lấy thông tin đơn hàng và lịch sử ticket. Ở bước này nó chưa có quyền thay đổi bất cứ thứ gì.
- Đề xuất. Agent soạn đề xuất hoàn tiền kèm lý do và số tiền. Đề xuất chỉ là văn bản, chưa phải hành động.
- Duyệt. Vì hành động chuyển tiền thuộc nhóm nhạy cảm, luồng dừng lại chờ người xác nhận. Nếu giao diện hiển thị đủ lý do và tham số, đây là cơ hội để người duyệt phát hiện đề xuất không khớp với chính sách. Người duyệt vẫn có thể bỏ sót.
- Thực thi. Sau khi được duyệt, tool hoàn tiền mới chạy. Backend vẫn kiểm tra lại điều kiện và hạn mức một lần nữa, không tin sẵn vào việc agent đã kiểm tra rồi.
- Ghi log. Mỗi lời gọi tool, tham số kèm theo và người duyệt đều được ghi lại để tra cứu về sau (OWASP AI Agent Security Cheat Sheet).
Xuyên suốt luồng đó, sandbox giữ cho code của agent không lang thang ra ngoài phạm vi và không cầm trực tiếp credential. Còn nếu dữ liệu đơn hàng đến qua một server MCP, thì server đó là một cửa nữa cần được duyệt nguồn, theo dõi thay đổi tool và cấp phạm vi hẹp. MCP ở đây là bề mặt kết nối cần kiểm soát, không phải thứ tự nó làm luồng này an toàn hơn.
Một điểm cần nói thẳng: bước duyệt của con người làm giảm rủi ro chứ không xóa được rủi ro. Google Cloud lưu ý người dùng vẫn có thể phê duyệt hành động nguy hiểm do quá tin gợi ý của agent (MCP security and safety). Vì vậy nên dành bước duyệt cho hành động thực sự nhạy cảm và hiển thị đủ thông tin để người duyệt kiểm tra.
Từ luồng này, có thể rút ra một danh sách câu hỏi dùng được ngay.
Checklist trước khi cho agent hành động thật
Bạn không cần đọc được code để dùng danh sách này. Chỉ cần hỏi người đang dựng hệ thống, và nghe xem câu trả lời có cụ thể hay không:
- Những nguồn dữ liệu nào agent sẽ đọc, và nguồn nào đến từ bên ngoài mà ta không kiểm soát nội dung?
- Agent được gọi chính xác bao nhiêu tool, và ai giữ danh sách đó?
- Mỗi tool bị giới hạn tham số thế nào, ví dụ trần số tiền, phạm vi bản ghi, khoảng thời gian?
- Hành động nào bắt buộc phải có người duyệt, và ai là người duyệt trên thực tế?
- Code của agent chạy trong môi trường bị giới hạn ra sao về file, network và quyền hệ thống?
- Credential được giữ ở đâu, agent có cầm trực tiếp không, hay đi qua một lớp trung gian?
- Các server MCP đang kết nối đến từ nguồn nào, và ai đã duyệt danh sách đó?
- Khi một server đổi mô tả tool hoặc thêm tool mới, hệ thống có phát hiện được không?
- Backend có tự kiểm tra lại điều kiện nghiệp vụ, hay tin vào việc agent đã kiểm tra rồi?
- Log ghi lại được gì, và có đủ để dựng lại một sự cố sau vài ngày không?
- Có cách dừng agent ngay lập tức khi phát hiện bất thường không, và ai bấm nút đó?
Nếu nhiều câu trong số này chưa có lời đáp rõ ràng, bắt đầu ở chế độ chỉ đọc là lựa chọn hợp lý hơn. Cho agent tra cứu, tóm tắt và đề xuất trước. Chỉ mở dần quyền ghi sau khi các giới hạn, bước kiểm tra và cách dừng đã được thử với những tình huống sai có chủ đích; vài lần agent cư xử ổn chưa phải bằng chứng đủ.
Còn vài chỗ hay gây nhầm lẫn, mình gom lại dưới đây.
Câu hỏi thường gặp
Bốn câu hỏi này giúp tách bạch bốn thứ dễ bị gộp làm một: quy tắc bằng chữ, quyền thực thi, môi trường chạy và giao thức kết nối.
System prompt chặt đã đủ an toàn chưa?
Chưa. System prompt là hướng dẫn, và hướng dẫn thì có thể bị lấn át bởi văn bản khác đi vào cùng context. Đây là lý do các tài liệu đều nói tới phòng thủ nhiều lớp thay vì một câu lệnh vạn năng (OWASP Prompt Injection Prevention). Prompt tốt giúp giảm xác suất, còn permission và sandbox mới giới hạn hậu quả.
Tool permission và sandbox có giống nhau không?
Không, và trộn hai khái niệm này là nhầm lẫn phổ biến nhất. Tool permission trả lời câu hỏi hành động này có được phép chạy hay không. Sandbox trả lời câu hỏi code đang chạy chạm được tới đâu. Một hệ thống có thể duyệt quyền rất chặt mà vẫn để agent chạy trong môi trường quá rộng, và ngược lại (Securely deploying AI agents).
Dùng MCP có tự làm agent an toàn hơn không?
Không tự động. MCP chuẩn hóa cách kết nối, còn phần đồng ý, phân quyền, kiểm soát truy cập và kiểm tra dữ liệu vẫn thuộc về bên triển khai (MCP specification). Thêm một server MCP là thêm một cửa vào không gian làm việc của agent, nên cái được thêm vào là kết nối, còn an toàn thì vẫn phải tự làm.
Có cần người duyệt mọi tool call không?
Không nhất thiết. Nên phân loại theo mức rủi ro: thao tác chỉ đọc trong phạm vi hẹp có thể tự chạy, còn hành động khó hoàn tác, chia sẻ dữ liệu hoặc liên quan tới tiền cần dừng theo chính sách để người duyệt kiểm tra. Bản đặc tả MCP draft cũng khuyến nghị luôn giữ cho con người khả năng từ chối một lời gọi tool (MCP tools, bản draft).
Điểm chung của cả bốn câu trả lời là chúng đều dẫn về một chỗ: đừng đặt cược vào việc agent luôn nghe lời.
Điều cần nhớ: giới hạn hậu quả khi agent làm sai
Bảo mật cho AI Agent không phải cuộc đua tìm câu prompt hoàn hảo. Nó là việc chuẩn bị cho khả năng agent hiểu sai, để thiệt hại dừng lại ở mức bạn chịu được. Prompt injection nói về nội dung đi vào. Tool permission nói về hành động được chạy. Sandbox nói về phạm vi chạm tới. MCP nói về những cánh cửa kết nối mà bạn cần tự kiểm soát.
Nếu bạn đang cân nhắc cho một agent quyền hành động thật, hãy bắt đầu bằng ba câu hỏi: chuyện tệ nhất khi nó làm sai là gì, lớp nào chặn hậu quả, và ai phát hiện ra? Để hiểu vòng lặp suy nghĩ và hành động phía sau, bạn có thể đọc Agent Loop là gì?. Để thấy vì sao các ranh giới này thường nằm ở tầng hạ tầng thay vì trong câu chữ, mời bạn đọc tiếp Vì sao AI Agent cần platform thay vì chỉ prompt?.