Google đã công bố vào ngày 17 tháng 8 năm 2026 một hướng dẫn về kiến trúc và thực hành, kèm theo một bản trình diễn mã nguồn mở, dành cho các tác nhân có khả năng thay đổi một hệ thống sản xuất. Thông điệp chính của họ là đúng: một prompt, ngay cả khi rất chi tiết, không phải là một biên giới an ninh. Các quy tắc quan trọng phải được áp đặt bằng mã, quyền truy cập và bằng chứng mật mã độc lập với mô hình.
1. Rủi ro mới: đại lý viết lách
Một chatbot trả lời kém chủ yếu tạo ra một vấn đề về thông tin. Một nhân viên thay đổi giá, hoàn tiền cho một đơn hàng, tạo người dùng hoặc thay đổi cấu hình có thể gây ra thiệt hại trực tiếp.
Những lỗi không chỉ xuất phát từ ý định xấu. Mô hình có thể hiểu sai bối cảnh, gọi nhầm công cụ, lặp lại một hành động sau một khoảng thời gian hoặc tuân theo một hướng dẫn được chèn từ một nguồn bên ngoài.
Do đó, bảo mật phải tập trung vào khả năng hành động tự nó. Hệ thống mục tiêu không nên tin tưởng vào một yêu cầu chỉ vì nó đến từ dịch vụ 'đại lý'.
2. Tại sao các hướng dẫn lại không đủ
Một lời nhắc có thể nói “không bao giờ hoàn trả hơn 100 euro” hoặc “yêu cầu xác nhận từ con người”. Những hướng dẫn này cải thiện hành vi trung bình, nhưng chúng vẫn được một mô hình xác suất diễn giải.
Một mũi tiêm có thể cố gắng vượt qua chúng. Một bản cập nhật mô hình có thể thay đổi cách chúng được theo dõi. Một lỗi ngữ cảnh cuối cùng có thể khiến tác nhân tin rằng một ngoại lệ là được phép.
Các quy tắc an toàn phải được viết trong một cổng xác định hoặc trong API mục tiêu. Mẫu đề xuất một hành động; một thành phần cổ điển quyết định xem hành động đó có được chấp nhận hay không.
3. Lớp đầu tiên: ký mỗi sửa đổi
Kiến trúc của Google khuyến nghị sử dụng một khóa riêng cho mỗi tác nhân, được quản lý bởi Cloud KMS và được bảo vệ về mặt phần cứng bởi Cloud HSM trong cấu hình được mô tả. Mỗi thay đổi của sổ cái của trình diễn đều được ký. Đối với một kiến trúc sản xuất, chúng tôi khuyến nghị mở rộng nguyên tắc này cho mỗi lần ghi vào hệ thống đích. API sau đó có thể xác minh danh tính của tác nhân, tính toàn vẹn của yêu cầu và sự không bị thay đổi.
Chữ ký phải bao phủ nhiều hơn là chỉ phần thân JSON. Bao gồm định danh của đại lý, người dùng khởi tạo yêu cầu, hành động, tài nguyên, số tiền, dấu thời gian, một định danh duy nhất và chính sách được áp dụng. Một nonce hoặc định danh idempotence chỉ ngăn chặn việc lặp lại nếu API nhớ các định danh đã được xử lý và từ chối sử dụng lại chúng.
Một khóa riêng cho mỗi đại lý giúp việc thu hồi trở nên dễ dàng. Nếu một dịch vụ bị xâm phạm, có thể chặn các ghi chú của nó mà không làm gián đoạn tất cả các dịch vụ khác.
Chữ ký cũng cung cấp bằng chứng về sự xác lập kỹ thuật. Nó không chứng minh rằng quyết định là đúng, nhưng nó cho phép biết thành phần nào đã phát ra yêu cầu và liệu yêu cầu đó có bị sửa đổi hay không.
4. Lớp thứ hai: thực thi trong một sandbox
Google minh họa việc cách ly với gVisor, một môi trường chặn các lệnh gọi hệ thống ở không gian người dùng. Nguyên tắc chung là giảm các khả năng của mã được tạo ra hoặc các công cụ được gọi: không có truy cập mạng theo mặc định, hệ thống tập tin bị giới hạn, quyền hạn bị loại bỏ, tài nguyên được giới hạn và thời gian tối đa.
Kho lưu trữ chỉ rõ rằng giao diện của trình trình diễn mô phỏng sandbox và việc thực thi thực sự dưới gVisor là tùy chọn. Vì vậy, đây là một hướng dẫn và một điểm khởi đầu để tăng cường bảo mật, chứ không phải là bằng chứng rằng một kiến trúc sản xuất đầy đủ đã được kiểm toán.
Một sandbox chỉ hữu ích nếu các kết quả đầu ra được kiểm soát. Một tác nhân bị cô lập có thể ghi một tệp sau đó bị dịch hoá mù bởi một dịch vụ có đặc quyền vẫn giữ một con đường tấn công.
Dữ liệu được đưa vào môi trường phải tối thiểu và tạm thời. Một bí mật sản xuất không nên được sao chép vào sandbox khi hành động có thể được thực hiện bởi một API hẹp phía sau một cổng.
5. Lớp thứ ba: một cầu nối ngữ nghĩa định hướng
Cổng kiểm tra hướng thực hiện của hành động trước khi thực hiện. Nó áp dụng các quy tắc có thể kiểm tra được: số tiền tối đa, vai trò của người dùng, trạng thái đơn hàng, tần suất, quốc gia, sự hiện diện của một sự xác nhận và sự nhất quán của các trường.
Mô hình không được phép tự chọn chính sách. Nó cung cấp một ý định có cấu trúc, lý tưởng là phù hợp với một sơ đồ. Cổng kết nối bổ sung với dữ liệu tham chiếu và quyết định cho phép, từ chối hoặc yêu cầu phê duyệt.
Bản trình diễn của Google chủ yếu dựa vào các biểu thức chính quy, từ khóa và kiểm soát giá trị SQL. Những kiểm soát nghiệp vụ phong phú hơn được đề xuất ở đây chỉ là một khuyến nghị về kiến trúc để điều chỉnh và thử nghiệm, không phải là khả năng được công cụ chứng minh một cách phổ quát.
Các quy tắc phải được kiểm tra trong CI như mã nghiệp vụ. Việc thay đổi ngưỡng hoặc ngoại lệ phải trải qua một cuộc đánh giá, một phiên bản và một lịch sử.
6. Nhật ký kiểm toán độc lập
Các dấu vết do tác nhân tạo ra là không đủ, vì một thành phần bị xâm phạm có thể thay đổi chúng. Hãy lưu giữ một nhật ký độc lập ở phía cổng hoặc hệ thống mục tiêu: yêu cầu nhận được, chữ ký, chính sách, quyết định, phản hồi và trạng thái cuối cùng.
Để vượt ra ngoài trình minh họa của Google, vốn kiểm tra định kỳ các chữ ký của sổ cái và khuyến nghị việc sử dụng Cloud Logging trong sản xuất, một lưu trữ chỉ cho phép thêm mới hoặc một chuỗi băm có thể tăng cường khả năng phát hiện việc sửa đổi. Các nhật ký cần vẫn có thể được các đội ngũ bảo mật và nghiệp vụ khai thác mà không tiết lộ dữ liệu đầy đủ một cách không cần thiết.
Cuộc kiểm toán phải cho phép tái tạo một quyết định: ai đã yêu cầu, bối cảnh nào đã được sử dụng, phiên bản chính sách nào đã được áp dụng và hành động nào thực sự đã được thực hiện.
7. Thiết kế các quyền theo năng lực
Tránh một tài khoản kỹ thuật đa năng. Tạo các khả năng hẹp: đọc một lệnh, đề xuất hoàn tiền, kích hoạt hoàn tiền có giới hạn hoặc mở một yêu cầu phê duyệt.
Mỗi khả năng có sơ đồ, giới hạn và quyền của riêng nó. Một nhân viên hỗ trợ không được truy cập cấu hình của cụm chỉ vì cả hai chức năng sử dụng cùng một nền tảng công cụ.
Các quyền cũng phải tính đến người dùng cuối. Đại lý không thể mở rộng quyền của người mà họ hỗ trợ. Nguyên tắc này là trung tâm đối với mọi đại lý kết nối với hệ thống thông tin.
8. Một ví dụ cụ thể: hoàn tiền cho khách hàng
Hãy xem xét một kịch bản minh họa, khác với trình diễn của Google: đại lý phân tích cuộc trò chuyện và đề xuất hoàn lại 42 euro cho đơn hàng X. Nó không trực tiếp sở hữu khóa thanh toán. Nó gọi một khả năng propose_refund với một kế hoạch nghiêm ngặt.
Cổng thanh toán thu thập số tiền đã thanh toán, trạng thái, các khoản hoàn trả trước đó và vai trò của người điều hành. Nó cho phép các khoản dưới 50 euro trong một số trường hợp, yêu cầu xác nhận đến 200 euro và từ chối vượt quá mức đó.
Sau khi được phép, một dịch vụ chuyên dụng thực hiện thao tác và ký kết kết quả. Nhật ký liên kết đề xuất, chính sách và giao dịch. Việc lặp lại với cùng một định danh không tạo ra một khoản hoàn tiền thứ hai.
9. Danh sách kiểm tra triển khai sản xuất
Trước khi mở một bản ghi cho một đại lý, hãy kiểm tra xem hành động có một sơ đồ đóng, một chính sách xác định, một danh tính riêng, một chữ ký, tính nhất quán và một nhật ký độc lập không. Hãy thử nghiệm các giới hạn, lặp lại, độ trễ và dữ liệu bị lỗi.
Sau đó mô phỏng các cuộc tấn công: hướng dẫn ẩn trong tài liệu, công cụ trả về nội dung độc hại, khóa bị thu hồi, dấu thời gian cũ, hành động ngoài vai trò và cố gắng vượt qua giới hạn tối đa.
Bắt đầu ở chế độ chỉ đọc, sau đó chuyển sang chế độ đề xuất. Chỉ cho phép thực thi tự động đối với các thao tác có thể đảo ngược, ít ảnh hưởng và được quan sát đầy đủ.
Phương pháp zero-trust không nhằm làm cho mô hình trở nên không thể sai sót. Nó bắt đầu từ giả định rằng mô hình có thể sai và giới hạn những gì một lỗi có thể gây ra. Chính sự đảo ngược này cho phép chuyển từ một minh chứng sang một khả năng có thể khai thác.
Partitech hỗ trợ việc bảo mật cho các nhân viên nghiệp vụ: thiết kế năng lực, cầu nối chính sách, chữ ký KMS, sandboxing, kiểm toán và thử nghiệm các kịch bản đối nghịch.