Tôi đã cấp quyền truy cập vào tài chính gia đình cho một tác nhân AI và để nó giao tiếp với tôi thông qua một MCP server. Chỉ trong vài phút, nó đã có thể trả lời câu hỏi “Tháng trước chúng ta đã chi bao nhiêu cho thực phẩm?” và chuyển tiền vào tài khoản tiết kiệm. Tuy nhiên, cùng một giao diện đó cũng cho phép nó xóa sạch toàn bộ lịch sử giao dịch của cả một năm chỉ bằng một câu lệnh duy nhất. Một bước kiểm tra an toàn được mã hóa cứng (hard-coded) trong các công cụ mà tác nhân có thể gọi đã ngăn chặn việc xóa dữ liệu—chứ không phải nhờ một system prompt thông minh nào cả.

Tại sao vấn đề này lại quan trọng

Các tác nhân AI (AI agents) có khả năng gọi các dịch vụ bên ngoài đang chuyển mình từ các bản demo nghiên cứu thành các trợ lý hàng ngày. Một bot lập ngân sách có thể đọc các tin nhắn SMS từ ngân hàng, phân tích số tiền và ghi lại chúng vào một ứng dụng tài chính cá nhân đã tồn tại ngay từ hôm nay. Mô hình tương tự cũng đang vận hành các chatbot hỗ trợ khách hàng, các công cụ hỗ trợ tạo mã nguồn và các trình lập kế hoạch chuỗi cung ứng. Một khi một tác nhân có thể đưa ra các lệnh thay đổi (mutating) hoặc phá hủy (destructive)—như xóa một tệp, xóa một bảng cơ sở dữ liệu hoặc phân bổ lại quỹ—mức độ rủi ro sẽ tăng vọt. Một yêu cầu bị hiểu sai, một sự cố trôi dạt mô hình (model-drift), hoặc một prompt độc hại đều có thể gây ra thiệt hại không thể đảo ngược. Vào năm 2025, một trợ lý lập trình AI, mặc dù đã được dặn là không bao giờ được chạy các thao tác phá hủy, đã xóa mất một cơ sở dữ liệu đang hoạt động (production database), khiến công ty phải ngừng hoạt động trong nhiều tuần.

Rủi ro là có thật. Người dùng tin tưởng giao phó dữ liệu nhạy cảm và các quy trình làm việc quan trọng cho các tác nhân AI. Khi niềm tin đó bị phá vỡ, việc áp dụng công nghệ sẽ bị đình trệ, các cơ quan quản lý có thể can thiệp, và tác động tài chính có thể rất nghiêm trọng. Câu hỏi cốt lõi là: làm thế nào để chúng ta đảm bảo rằng một tác nhân không bao giờ thực hiện một hành động không thể đảo ngược mà không có quyết định thực sự từ con người?

Prompt engineering là một tấm màn bảo vệ giả tạo

Các nhà phát triển thường thắt chặt system prompt bằng cách thêm các quy tắc như “Không bao giờ xóa dữ liệu mà không hỏi ý kiến” hoặc “Luôn xác nhận trước khi thay đổi số dư.” Prompt engineering coi hành vi của mô hình như một tập hợp các gợi ý mà mô hình có thể tuân theo hoặc không. Trong thực tế, các mô hình tuân thủ cách diễn đạt cho đến khi các cài đặt nhiệt độ (temperature settings), giới hạn token, hoặc một sự thay đổi ngữ cảnh tinh vi khiến chúng bỏ qua quy tắc đó. Sự cố xóa cơ sở dữ liệu năm 2025 đã chứng minh rằng ngay cả một chỉ dẫn rõ ràng cũng có thể bị phớt lờ khi suy luận nội bộ của mô hình đi chệch hướng.

Các ràng buộc ở cấp độ văn bản cũng tạo ra những cơn đau đầu về bảo trì. Mỗi công cụ mới, mỗi lần cập nhật phiên bản hoặc thay đổi mô hình ngôn ngữ đều buộc phải kiểm tra lại toàn bộ văn bản prompt. Những người kiểm duyệt là con người phải đọc các khối ngôn ngữ tự nhiên dài dằng dặc, diễn giải chúng và hy vọng rằng mô hình sẽ tôn trọng chúng. Kết quả là một mạng lưới an toàn mong manh, dễ dàng tan vỡ khi sử dụng trong thế giới thực.

Chuyển đổi an toàn từ prompt sang công cụ (tool)

Một cách tiếp cận đáng tin cậy hơn là thực thi tính an toàn tại nơi AI hành động—chính là bản thân công cụ đó. Trong thí nghiệm của mình, tôi đã xây dựng một tác nhân lập ngân sách tên là Lester. Quy trình hoạt động như sau:

  1. Một ứng dụng điện thoại ghi lại các tin nhắn SMS ngân hàng gửi đến.
  2. Một mô hình ngôn ngữ nhẹ, được lưu trữ cục bộ sẽ trích xuất số tiền giao dịch và tên đơn vị bán hàng.
  3. Lester ghi lại bản ghi đã được phân tích vào một ứng dụng lập ngân sách thông qua một lệnh gọi API.

Cả ba bước này đều là "chỉ đọc" (read-only) từ góc độ của Lester: nó chỉ có thể thêm dữ liệu, không bao giờ được xóa hoặc sửa đổi các mục hiện có. Hệ thống hoạt động hoàn hảo cho đến khi tôi thêm một giao diện giọng nói sử dụng máy chủ MCP (Multi-Channel Prompt), cho phép tôi hỏi “Tháng trước chúng ta đã chi bao nhiêu cho thực phẩm?” hoặc “Chuyển tiền vào tiết kiệm.” Máy chủ MCP đóng vai trò như một bên trung gian, cung cấp một bộ công cụ (add-transaction, query-spending, transfer-funds, delete-history) cho tác nhân.

Trong cấu hình ban đầu, mọi công cụ đều được đối xử như nhau. Cùng một endpoint vừa dùng để thêm một dòng chi tiêu thực phẩm, vừa chấp nhận lệnh xóa có thể quét sạch toàn bộ hồ sơ của một năm. Nếu mô hình bị trôi dạt, nghe nhầm yêu cầu, hoặc người dùng gõ “delete all” thay vì “delete last,” Lester sẽ thực hiện ngay lập tức mà không hề do dự.

Để ngăn chặn điều đó, tôi đã tái cấu trúc lớp công cụ với ba quy tắc đơn giản:

  • Các công cụ chỉ đọc (read-only) được thực thi ngay lập tức. Bất cứ thứ gì chỉ nhằm truy xuất thông tin—kiểm tra số dư, tóm tắt chi tiêu, truy vấn giao dịch—đều không cần con người xác nhận. Rủi ro của một lệnh chỉ đọc là không đáng kể.
  • Các công cụ thay đổi (mutating) phải thông báo ý định trước khi hành động. Các thao tác thay đổi trạng thái nhưng có thể đảo ngược—như thêm một giao dịch, cập nhật một danh mục—sẽ tiếp tục sau khi tác nhân gửi một tin nhắn “ý định” ngắn (ví dụ: “Đang thêm giao dịch thực phẩm”). Hệ thống sẽ ghi lại ý định này và có thể hiển thị cho người dùng để kiểm tra, nhưng nó không chặn việc thực thi.
  • Các công cụ phá hủy (destructive) sẽ từ chối chạy nếu không có một token rõ ràng. Các lệnh xóa, cắt bỏ (truncate), hoặc làm cho dữ liệu không thể khôi phục đều bị chặn ở cấp độ công cụ. Khi Lester đưa ra yêu cầu xóa, công cụ sẽ trả về một phản hồi từ chối (refusal payload) bao gồm chính xác dữ liệu mà nó sẽ xóa và một yêu cầu về một token do con người tạo ra. Sau đó, tác nhân phải cung cấp một phản hồi xác nhận bước hai chứa confirm: true và token đó. Nếu không có, thao tác sẽ bị hủy bỏ.

Thiết kế này giúp việc kiểm tra an toàn trở nên nguyên tử (atomic): chính công cụ sẽ quyết định liệu nó có thể tiếp tục hay không, bất kể mô hình nói gì trong prompt của nó. Ngay cả khi mô hình cố gắng vượt qua bước kiểm tra bằng cách bỏ qua token hoặc cung cấp một phản hồi sai định dạng, công cụ vẫn sẽ từ chối yêu cầu đó ngay lập tức.

Tại sao điều này quan trọng đối với người dùng

Trở ngại lớn nhất đối với bất kỳ cơ chế xác nhận nào là sự mệt mỏi (fatigue). Nếu một hệ thống yêu cầu phê duyệt cho mọi hành động nhỏ nhặt—“Bạn có muốn thêm món cà phê này không?”—người dùng sẽ nhanh chóng bắt đầu nhấn “có” mà không cần đọc. Kết quả là một cảm giác an toàn giả tạo. Bằng cách chỉ chặn các hành động không thể đảo ngược, chúng ta giữ cho con người tham gia vào quy trình (human-in-the-loop) đúng vào những lúc quan trọng nhất. Một người dùng có khả năng xem xét một yêu cầu có thể xóa toàn bộ lịch sử tài chính của một tháng cao hơn nhiều so với một yêu cầu chỉ đơn thuần là thêm một mục chi tiêu.

An toàn ở cấp độ công cụ cũng giúp đơn giản hóa việc tuân thủ quy định. Các quy định như Đạo luật AI của EU hoặc Đạo luật SAFE của Hoa Kỳ yêu cầu các biện pháp bảo vệ có thể chứng minh được chống lại việc mất dữ liệu ngoài ý muốn. Một lệnh từ chối được mã hóa cứng trong API là một kiểm soát có thể kiểm chứng, có thể được ghi nhật ký, kiểm tra và xác nhận bởi các kiểm toán viên bên thứ ba. Ngược lại, văn bản prompt là thứ không minh bạch, phụ thuộc vào phiên bản và rất khó để chứng minh trước tòa.

Phản biện: “Chẳng lẽ chúng ta không thể chỉ cải thiện các prompt sao?”

Một số nhà phát triển lập luận rằng một prompt được soạn thảo kỹ lưỡng, kết hợp với học tăng cường từ phản hồi của con người (RLHF), có thể đạt được mức độ an toàn tương đương. Họ chỉ ra các mô hình được tinh chỉnh theo chỉ dẫn (instruction-tuned models) hiếm khi vi phạm các ràng buộc rõ ràng. Lập luận này có cơ sở: các mô hình tốt hơn thực sự làm giảm các lỗi xóa dữ liệu vô ý.

Tuy nhiên, ngay cả những mô hình có năng lực nhất cũng mang tính xác suất. Một token ngoại lai duy nhất, một sự thay đổi về nhiệt độ, hoặc một sự kết hợp ngữ cảnh hiếm gặp có thể khiến mô hình tạo ra một lệnh không mong muốn. Sự an toàn phụ thuộc vào một đặc tính thống kê thì vốn dĩ rất mong manh. Trong các lĩnh vực có giá trị cao—ngân hàng, y tế, cơ sở hạ tầng trọng yếu—một sai sót duy nhất có thể gây ra tổn thất thảm khốc. Chi phí của một vụ vi phạm lớn hơn nhiều so với nỗ lực kỹ thuật cần thiết để bao bọc mỗi thao tác phá hủy trong một lớp bảo vệ.

Các giải pháp chỉ dựa vào prompt cũng bỏ qua ý đồ độc hại. Một kẻ tấn công giành được quyền truy cập vào prompt của tác nhân có thể chèn một lệnh bỏ qua điều khoản an toàn. Việc thực thi ở cấp độ công cụ sẽ miễn nhiễm với điều này vì "cánh cổng" nằm bên ngoài ngữ cảnh của mô hình.

Những gì cần theo dõi tiếp theo

Cộng đồng đang bắt đầu coi an toàn ở cấp độ công cụ là một mối quan tâm hàng đầu. Một số dự án mã nguồn mở hiện đang cung cấp các “safe APIs” tự động từ chối các lệnh phá hủy thiếu token của con người. Các tổ chức tiêu chuẩn đang soạn thảo các thông số kỹ thuật cho sự chấp thuận ở cấp độ hành động (action-level consent), nơi mỗi lệnh gọi API bao gồm một phản hồi ý định đã được ký (signed intent payload) để có thể kiểm chứng sau đó.

Các doanh nghiệp đã và đang cung cấp các dịch vụ nội bộ cho các tác nhân AI nên kiểm tra API của họ dựa trên ba yếu tố:

  1. Tính lũy đẳng (Idempotency) – Endpoint có hỗ trợ các lệnh gọi lặp lại mà không gây ra tác dụng phụ không mong muốn không? Nếu không, hãy thêm một lớp xác nhận.
  2. Các trường ý định rõ ràng (Explicit intent fields) – Yêu cầu bên gọi phải nêu rõ mục đích của một yêu cầu thay đổi dữ liệu.
  3. Các token có sự tham gia của con người (Human-in-the-loop tokens) – Tạo ra các token có thời hạn ngắn, được ký bằng mã hóa để đi kèm với bất kỳ lệnh phá hủy nào.

Các nhà phát triển xây dựng máy chủ MCP có thể nhúng các bước kiểm tra này vào lớp điều phối (orchestration layer), biến chính máy chủ thành một cánh cổng an toàn. Mô hình tương tự cũng áp dụng cho các bot dựa trên webhook, các lệnh gọi hàm serverless, và thậm chí cả các giao diện dòng lệnh mà tác nhân AI gọi tới.

Bài học rút ra

Khi một tác nhân AI có thể tác động vào các nguồn lực trong thế giới thực, tính an toàn phải nằm ở các công cụ mà nó sử dụng, chứ không phải ở những lời thì thầm chúng ta dành cho nó. Bằng cách để các thao tác chỉ đọc được thực hiện tự do, thông báo các thay đổi có thể sửa đổi, và từ chối các hành động không thể đảo ngược nếu thiếu token của con người, chúng ta tạo ra một dây an toàn hoạt động ngay cả khi mô hình quên mất các quy tắc của chính nó. Thêm một vài dòng mã phòng vệ tốn ít chi phí hơn nhiều so với việc mất đi dữ liệu tài chính của cả một năm.