Tóm tắt nhanh

  • Các tác nhân AI không chỉ tạo văn bản mà còn truy cập dữ liệu, gọi công cụ và thực hiện hành động với danh tính người dùng. Hướng dẫn từ AWS và hoạt động tấn công do Wiz quan sát cho thấy đội ngũ kỹ thuật phải bảo vệ toàn bộ đường đi từ người dùng, mô hình đến công cụ và hạ tầng.
  • Rào chắn ở lớp mô hình không thể tự ngăn truy cập sai quyền, khai thác máy chủ công cụ hay đánh cắp thông tin xác thực. Mỗi lần gọi công cụ cần được xem như một yêu cầu bảo mật có danh tính, chính sách và bước kiểm tra riêng.
  • Lập sơ đồ một tác nhân đang chạy production từ principal đến từng công cụ và kho dữ liệu; sau đó kiểm tra ngay nơi ngữ cảnh phân quyền bị mất, credential dùng chung hoặc phản hồi công cụ chưa được xác thực.

Điều gì đã xảy ra

Tác nhân AI đang biến một yêu cầu ngôn ngữ tự nhiên thành chuỗi hành động trên cơ sở dữ liệu, kho tài liệu, dịch vụ SaaS và API nội bộ. Vì vậy, bảo mật không thể dừng ở việc kiểm tra prompt hoặc phản hồi của mô hình: quyền hạn, thông tin xác thực và dữ liệu trả về đều đi qua những thành phần nằm ngoài ranh giới đó.

Hai nhóm bằng chứng chỉ về cùng một vấn đề. AWS đưa ra hướng dẫn về truyền ngữ cảnh phân quyền, tích hợp cơ chế xác thực tùy chỉnh và mở rộng guardrail tới tương tác công cụ; trong khi honeypot AI của Wiz ghi nhận các chiến dịch đang nhắm vào LiteLLM, máy chủ MCP và framework AI bằng RCE, blind prompt injection và đánh cắp thông tin xác thực trong bộ nhớ.

Vì sao guardrail của mô hình chưa đủ?

Guardrail ở ranh giới mô hình có thể đánh giá nội dung đi vào hoặc đi ra khỏi mô hình, nhưng tác nhân còn gửi đối số tới công cụ, nhận dữ liệu bên ngoài và chuyển kết quả giữa nhiều hệ thống. Theo hướng dẫn mở rộng Amazon Bedrock Guardrails bằng Strands Agents SDK, những luồng dữ liệu ngoài mô hình cần các điểm kiểm tra bổ sung; bài viết trình bày một cách triển khai gồm ba checkpoint xác thực.

Đây là khác biệt giữa kiểm duyệt nội dung và kiểm soát thực thi. Một câu trả lời có vẻ an toàn vẫn có thể bắt nguồn từ truy vấn vượt quyền, còn một lời gọi công cụ hợp lệ về cú pháp vẫn có thể chứa tham số nguy hiểm do prompt injection tác động.

Cũng không nên xem MCP hoặc gateway là ranh giới tin cậy mặc định. Chúng giúp chuẩn hóa và điều phối tích hợp, nhưng máy chủ, framework và thông tin xác thực phía sau vẫn là bề mặt tấn công. Khi xây dựng hệ sinh thái công cụ kiểu MCP cho trợ lý phát triển phần mềm, đội ngũ cần lập mô hình đe dọa cho từng khả năng mà tác nhân được cấp.

Một kiến trúc bảo mật nhiều lớp cần kiểm soát những gì?

Cách tiếp cận thực tế là coi mỗi bước trong chuỗi tác nhân như một lần chuyển ranh giới tin cậy. Danh tính phải tồn tại xuyên suốt, nhưng quyền thực thi cần được đánh giá lại tại nơi sở hữu tài nguyên thay vì chỉ tin vào quyết định của mô hình.

LớpRủi ro chínhKiểm soát ưu tiên
Người dùng đến tác nhânGiả mạo hoặc thiếu ngữ cảnh người gọiXác thực người dùng, giữ principal và thuộc tính phân quyền
Tác nhân đến công cụGọi sai công cụ hoặc truyền đối số nguy hiểmAllowlist công cụ, kiểm tra schema, policy theo hành động
Công cụ đến dữ liệuĐọc hoặc thay đổi tài nguyên vượt quyềnỦy quyền ở tầng dữ liệu, đặc quyền tối thiểu, giới hạn phạm vi
Phản hồi công cụNội dung độc hại hoặc dữ liệu nhạy cảm quay lại ngữ cảnhKiểm tra đầu ra, lọc dữ liệu và giới hạn dữ liệu đưa vào mô hình
Runtime và gatewayRCE, rò rỉ secret hoặc chiếm quyền dịch vụVá lỗi, cô lập tiến trình, quản lý secret và giám sát hành vi

Mẫu truyền ngữ cảnh phân quyền của AWS tập trung vào một lỗi thiết kế quan trọng: tác nhân không biết ai đang đặt câu hỏi có thể trả về dữ liệu mà người đó không được phép xem. Nguyên tắc tổng quát là truyền đủ ngữ cảnh danh tính để hệ thống đích ra quyết định, nhưng không trao cho tác nhân một danh tính dịch vụ có quyền rộng thay cho mọi người dùng.

Xác thực và phân quyền cũng phải được tách riêng. OAuth 2.0, IAM hoặc API key có thể chứng minh hay đại diện cho một danh tính, nhưng chính sách vẫn phải quyết định danh tính đó được gọi công cụ nào, trên tài nguyên nào và với hành động nào.

Đội ngũ phát triển nên triển khai từ đâu?

Trước hết, hãy lập danh mục tất cả công cụ mà tác nhân có thể gọi, bao gồm các lệnh đọc, ghi và hành động không thể đảo ngược. Với mỗi công cụ, ghi rõ principal được sử dụng, dữ liệu đi vào và đi ra, nơi áp dụng quyết định phân quyền, secret liên quan và nhật ký cần lưu.

  1. Gắn danh tính vào toàn bộ luồng: bảo toàn ngữ cảnh người dùng qua agent runtime, gateway và adapter; từ chối yêu cầu khi thiếu ngữ cảnh bắt buộc.
  2. Thu hẹp quyền: tách công cụ đọc khỏi công cụ thay đổi trạng thái, giới hạn tài nguyên và tránh dùng một credential quyền cao cho mọi phiên.
  3. Xác thực trước và sau lời gọi: kiểm tra tên công cụ, kiểu và phạm vi tham số trước khi thực thi; đánh giá dữ liệu trả về trước khi đưa lại vào mô hình.
  4. Cô lập hạ tầng: xem LiteLLM, máy chủ MCP, plugin và framework tác nhân là workload có thể bị khai thác, không phải middleware vô hại.
  5. Ghi lại quyết định: log principal, công cụ, policy áp dụng, kết quả và mã tương quan mà không ghi thừa secret hoặc dữ liệu nhạy cảm.

Hệ thống doanh nghiệp đôi khi vẫn phải kết nối dịch vụ dùng Basic Auth theo RFC 7617. AWS mô tả cách dùng request Lambda interceptor trong AgentCore Gateway để hỗ trợ cơ chế tùy chỉnh, bên cạnh OAuth 2.0, IAM và API key có sẵn. Interceptor là điểm chuyển đổi tương thích, không phải lý do để nới lỏng TLS, quản lý secret, xoay vòng thông tin xác thực hoặc giới hạn quyền.

Những điểm kiểm soát này nên nằm trong control plane có chủ sở hữu và chính sách rõ ràng, thay vì được sao chép tùy ý vào từng prompt. Các nguyên tắc tương tự cũng xuất hiện khi thiết kế một control plane có quản trị: tập trung chính sách nhưng giữ việc thực thi có thể kiểm toán.

Cần kiểm thử và theo dõi điều gì tiếp theo?

Kiểm thử red-team nên đi qua toàn bộ chuỗi thay vì chỉ cố làm mô hình sinh nội dung bị cấm. Các tình huống hữu ích gồm người dùng quyền thấp yêu cầu dữ liệu quyền cao, tài liệu ngoài chứa chỉ dẫn ẩn, đối số công cụ vượt schema, phản hồi công cụ cố điều khiển vòng tác nhân tiếp theo và credential bị lộ từ runtime.

Ở khâu vận hành, hãy cảnh báo khi một principal gọi công cụ bất thường, khi tác nhân tăng đột biến số lần gọi, khi xuất hiện tham số ngoài phạm vi hoặc khi một công cụ đọc lượng dữ liệu không phù hợp với tác vụ. Nhật ký phải cho phép dựng lại chuỗi người dùng–tác nhân–công cụ–tài nguyên mà không biến hệ thống quan sát thành kho secret mới.

Các hướng dẫn AWS là mẫu triển khai trên một hệ sinh thái cụ thể; báo cáo Wiz phản ánh hoạt động mà honeypot của hãng quan sát. Chúng không chứng minh mọi stack đều bị tấn công giống nhau, nhưng kết hợp lại tạo cơ sở đủ mạnh để các đội ngũ đánh giá bề mặt ngoài mô hình ngay bây giờ.

Kết luận

  • Guardrail ở mô hình chỉ bảo vệ một phần của luồng tác nhân.
  • Danh tính người dùng và quyết định phân quyền phải đi tới nơi sở hữu dữ liệu hoặc hành động.
  • Gateway, máy chủ MCP và framework AI phải được vận hành như hạ tầng nhạy cảm.
  • Ưu tiên kiểm kê công cụ, đặc quyền tối thiểu, checkpoint xác thực và log có thể kiểm toán.

Bài viết liên quan

Nguồn tham khảo

Vì sao developer cần quan tâm

Rào chắn ở lớp mô hình không thể tự ngăn truy cập sai quyền, khai thác máy chủ công cụ hay đánh cắp thông tin xác thực. Mỗi lần gọi công cụ cần được xem như một yêu cầu bảo mật có danh tính, chính sách và bước kiểm tra riêng.

  1. 1Lập sơ đồ một tác nhân đang chạy production từ principal đến từng công cụ và kho dữ liệu; sau đó kiểm tra ngay nơi ngữ cảnh phân quyền bị mất, credential dùng chung hoặc phản hồi công cụ chưa được xác thực.