Prompt injection và Tool misuse: Vì sao quyền của Agent leo lên hạng ba bảng rủi ro 2026

Nếu công ty bạn đang cho AI agent làm việc gọi tool thay vì chỉ trả lời câu hỏi, thì hai rủi ro đáng lo nhất bây giờ không phải là agent trả lời sai, mà là agent bị dẫn dắt để làm sai — và agent có quyền làm nhiều hơn mức cần thiết. Đó chính là prompt injection và tool misuse.

Mục lục bài viết

1. Prompt injection đứng đầu, lạm quyền Agent leo hạng ba

2. Vì sao Agent có quyền gọi tool lại dễ bị lạm dụng

3. MCP xử lý rủi ro lạm quyền ở tầng giao thức thế nào

4. Checklist rút gọn cho người vận hành agent

1. Prompt injection đứng đầu, lạm quyền Agent leo hạng ba

Bản OWASP GenAI LLM Top 10 phiên bản 2026 xếp hạng mười rủi ro theo thứ tự: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Excessive Agency, LLM04 Supply Chain, LLM05 Data and Model Poisoning, LLM06 Unbounded Consumption, LLM07 Misinformation, LLM08 Hidden Context Exposure, LLM09 Vector and Embedding Weaknesses, LLM10 Improper Output Handling.

Điểm đáng chú ý nhất cho người vận hành agent: Excessive Agency — rủi ro trao quá nhiều quyền hành động cho agent — đứng ở vị trí LLM03 trong bản 2026, trong khi ở bản 2025 nó chỉ nằm ở LLM06. Nói cách khác, chỉ trong một năm, rủi ro "agent làm quá tay" đã leo ba bậc để trở thành một trong ba mối lo hàng đầu, ngay sau prompt injection và rò rỉ thông tin nhạy cảm.

Hai rủi ro này thường đi cùng nhau trong thực tế: prompt injection là cách kẻ tấn công chèn chỉ thị độc hại vào nội dung mà agent đọc được, còn tool misuse là hậu quả xảy ra khi agent bị dẫn dắt đó lại đang cầm quyền gọi tool — đọc file, gửi request, ghi dữ liệu — vượt quá phạm vi công việc ban đầu.

2. Vì sao Agent có quyền gọi tool lại dễ bị lạm dụng

Để hiểu tool misuse, cần hiểu cơ chế tool calling hoạt động thế nào. Với các agent chạy trên nền tảng như Ollama, model nhận định nghĩa tool qua một mảng gửi kèm request, mỗi tool là một object mô tả tên, mô tả chức năng và tham số theo JSON schema. Khi quyết định cần dùng tool, model trả về một mảng tool call gồm tên hàm và tham số cụ thể; kết quả chạy tool sau đó được đưa ngược lại hội thoại qua một message riêng để model đọc tiếp và ra quyết định kế tiếp.

Có bốn kiểu gọi tool phổ biến: single-shot cho một lần gọi rồi kết thúc, parallel cho nhiều tool call cùng lúc, agent loop khi model tự quyết định lặp lại việc gọi tool nhiều vòng, và streaming khi kết quả được ghép dần theo thời gian thực. Kiểu càng tự động — đặc biệt là agent loop — thì càng khó kiểm soát bằng mắt người, vì không có ai duyệt từng lệnh gọi tool trước khi nó chạy. Đây chính là mảnh đất mà prompt injection khai thác: chỉ cần một đoạn nội dung độc hại lọt vào ngữ cảnh, agent trong vòng lặp tự động có thể tự gọi tool sai mục đích mà không ai kịp ngăn.

3. MCP xử lý rủi ro lạm quyền ở tầng giao thức thế nào

Tài liệu Security Best Practices trong đặc tả Model Context Protocol (bản sửa đổi 2026-07-28) đưa ra một loạt quy tắc bắt buộc nhắm thẳng vào việc siết quyền của agent và tool. Nếu team bạn đang dựng AI Agent Orchestration nội bộ trên nền MCP, đây là những điểm cần kiểm tra trước.

3.1. Token passthrough: Đừng chuyển tiếp token không phải của mình

Một anti-pattern phổ biến là MCP server nhận token từ client rồi chuyển tiếp nguyên vẹn xuống API phía dưới mà không kiểm token đó có thực sự được phát hành cho chính server hay không. Quy tắc bắt buộc là server không được chấp nhận bất kỳ token nào không được phát hành tường minh cho chính nó.

3.2. State handle hijacking: Hệ quả của việc bỏ session giao thức

Bản sửa đổi 2026-07-28 đã gỡ session cấp giao thức khỏi transport Streamable HTTP; server cần lưu trạng thái xuyên nhiều lời gọi giờ phải tự phát ra một handle và nhận lại nó như một tham số tool thông thường. Thay đổi này mở ra hướng tấn công state handle hijacking, nên đặc tả yêu cầu server phải kiểm mọi request vào, không được coi việc sở hữu một handle là bằng chứng xác thực, nên sinh handle bằng bộ sinh số ngẫu nhiên an toàn thay vì định danh tuần tự đoán được, và nên buộc handle với danh tính người dùng đã xác thực ở phía server.

3.3. Local MCP server: Consent rõ ràng và chạy trong sandbox

Nếu client hỗ trợ cấu hình local server chỉ bằng một cú nhấp, nó phải hiện cơ chế đồng ý trước khi chạy: hiển thị nguyên văn không cắt bớt câu lệnh sẽ chạy kèm mọi tham số, nêu rõ đây là thao tác có thể nguy hiểm vì thực thi mã trên máy người dùng, và cho phép huỷ. Lý do là local MCP server chạy với cùng mức quyền của client, nên nên được đặt trong sandbox với quyền tối thiểu, giới hạn truy cập cả filesystem lẫn mạng; nếu chỉ cần giao tiếp với client, nên dùng transport stdio, còn nếu bắt buộc dùng HTTP thì phải yêu cầu token authorization hoặc dùng unix domain socket có kiểm soát truy cập.

3.4. Confused deputy và scope tối thiểu

Một lỗ hổng khác là confused deputy, xảy ra khi một MCP proxy dùng chung một client ID tĩnh với authorization server bên thứ ba mà không kiểm consent theo từng client trước khi chuyển tiếp — khi đó kẻ tấn công có thể lấy được authorization code mà người dùng chưa từng đồng ý. Mitigation bắt buộc là proxy phải giữ sổ đăng ký client_id đã duyệt theo từng người dùng và kiểm trước khi khởi động luồng cấp quyền. Song song đó, nguyên tắc scope tối thiểu yêu cầu bắt đầu bằng tập quyền nhỏ nhất — chỉ đọc và khám phá — rồi nâng quyền dần khi thao tác đặc quyền được thử lần đầu, thay vì cấp sẵn các scope bao trùm kiểu "full-access" hay gộp nhiều đặc quyền không liên quan vào một lần xin quyền.

Đặc tả cũng siết cả đường dẫn URL cấp quyền: client chỉ được chấp nhận scheme http hoặc https — http chỉ dùng được cho địa chỉ loopback lúc phát triển — và phải từ chối các scheme nguy hiểm như javascript:, data:, file:, vbscript:, tuyệt đối không mở URL bằng lệnh shell. Ngoài ra, authorization server nên kèm tham số iss trong response để client xác minh đúng issuer trước khi đổi authorization code, còn cơ chế đăng ký client động kiểu cũ (Dynamic Client Registration) đã bị thay thế bằng Client ID Metadata Documents, chỉ còn giữ lại để tương thích ngược.

4. Checklist rút gọn cho người vận hành agent

• Kiểm tra mọi MCP server nội bộ có đang chấp nhận token không được phát hành cho chính nó hay không.
• Xác nhận state handle được sinh ngẫu nhiên và gắn với người dùng đã xác thực, không dùng ID tuần tự.
• Với local MCP server, bật cơ chế hiển thị nguyên văn lệnh và yêu cầu người dùng đồng ý trước khi chạy, đồng thời chạy trong sandbox quyền tối thiểu.
• Cấp scope theo nguyên tắc tối thiểu, tránh scope bao trùm kiểu "all" hay "full-access" cho agent gọi tool.
• Ưu tiên chặn agent loop tự động chạy tool đặc quyền mà không có điểm dừng để người vận hành xác nhận.

Nếu bạn đang lên kế hoạch nâng cấp hạ tầng để chạy agent và các luồng tool calling này ổn định, có thể tham khảo thêm dải AI PC GVN từ 201 - 500 triệu phù hợp cho việc dựng môi trường agent nội bộ trước khi mở rộng quy mô.