Chuỗi bài về AI Agent Zero Trust của Google (Phần 2): Quản trị thời gian thực dựa trên ý định thay vì cú pháp

15 THÁNG 9, 2026

Eric Dong, Kỹ sư Quan hệ Nhà phát triển (Developer Relations Engineer)

Phần 2 của loạt bài về Zero-trust Agents: quản trị thời gian thực (runtime governance), kiểm soát ý định (intent gating) và khắc phục bất thường thích ứng (adaptive anomaly remediation).

Trong Phần 1, chúng tôi đã thiết lập ba biện pháp kiểm soát tất định cho các tác nhân tự hành (autonomous agents): ghi cơ sở dữ liệu có chữ ký với Cloud KMS, cô lập nhân (kernel) trong không gian người dùng với gVisor, và cổng vào/ra (input/output gateway) được hỗ trợ bởi các bài kiểm thử đơn vị (CI unit tests).

Những biện pháp đó hoạt động hiệu quả, nhưng chúng có chung một hạn chế: chúng chỉ phát hiện được các trường hợp mà bạn có thể xác định rõ ràng từ trước.

Một trình phân tích cú pháp SQL không thể phân biệt được một yêu cầu hoàn tiền do kỹ thuật thao túng tâm lý (social engineering) với một yêu cầu hợp lệ nếu cú pháp vẫn đúng. Một biểu thức chính quy (regex) không thể phân biệt được giữa một cáp USB vật lý và một giấy phép phần mềm đã mở. Và một bộ kiểm thử đơn lượt (single-turn test suite) không thể phát hiện được một đội ngũ tác nhân bị rút cạn tài nguyên qua nhiều lượt tương tác.

Phần 2 vẫn giữ nguyên Customer Support & Returns Agent được xây dựng bằng Agent Development Kit (ADK) và chuyển các kiểm tra bảo mật lên nền tảng, nơi chúng suy luận về ý định và thích ứng với hành vi. Việc chuyển các kiểm tra lên nền tảng cũng thay đổi quyền sở hữu chúng. Quản trị được xác định và quản lý bởi một quản trị viên nền tảng hoặc bảo mật, tách biệt với nhà phát triển tác nhân, vì nền tảng thực thi nó bên ngoài mã nguồn của tác nhân.

Khi triển khai lên Gemini Enterprise Agent Platform, chúng tôi thay thế cơ sở hạ tầng container tự lưu trữ và các danh sách regex được quản lý thủ công bằng quản trị thời gian thực (runtime governance) được quản lý: Model Armor, Semantic Governance Policies, và Agent Anomaly Detection với Closed-Loop Remediation.

Kịch bản: Vẫn là tác nhân hoàn tiền đó, nhưng hiện tại ở giai đoạn thời gian thực.

Chúng tôi giữ nguyên Customer Support and Returns Agent từ Phần 1. Nó thực hiện tra cứu đơn hàng, tính phí hoàn kho và thanh toán hoàn tiền dựa trên sổ cái của người bán. Khi khách hàng yêu cầu trả hàng, tác nhân đọc đơn hàng bằng verify_order và xác định số tiền hoàn lại cuối cùng bằng calculate_restocking_fee, chạy bên trong Agent Sandbox – môi trường sandbox được quản lý của nền tảng dành cho mã nguồn do mô hình tạo ra. Nếu việc hoàn tiền hợp lệ, nó sẽ gọi issue_refund để thực hiện thanh toán, ký yêu cầu bằng khóa bất đối xứng Cloud KMS của chính tác nhân, cùng một định danh dựa trên phần cứng từ Phần 1. Trong môi trường sản xuất, một tác nhân thường sẽ gọi các khả năng này thông qua các công cụ được cung cấp qua Model Context Protocol (MCP) hoặc các API backend. Để đơn giản hóa trong bản demo đi kèm, chúng tôi triển khai chúng trực tiếp dưới dạng các hàm Python cục bộ.

Để các cuộc tấn công trở nên cụ thể, chúng tôi chạy tất cả chúng trên một giao dịch duy nhất: Đơn hàng #99281, tổng cộng $149.00. Đơn hàng bao gồm hai mục: một USB-C Pro Docking Station and Cable giá $29.00, và một Workplace User License hàng năm giá $120.00. Sự phân chia giữa hàng hóa vật lý và kỹ thuật số này là điểm mấu chốt cho hai cuộc tấn công tiếp theo.

Tất cả mã nguồn, khai báo chính sách và các trình mô phỏng tương tác được giới thiệu dưới đây đều có sẵn trong bản demo mã nguồn mở đi kèm: zero-trust-agents-2.

Dưới đây là cách quản trị thời gian thực ngăn chặn bốn mô hình tấn công mà các biện pháp kiểm soát tại thời điểm xây dựng (build-time) đã bỏ lọt.

Chuyển từ kiểm tra ở cấp độ mã nguồn sang quản trị thời gian thực được quản lý.

Một môi trường thời gian thực zero-trust giả định rằng mỗi yêu cầu riêng lẻ có thể trông hợp lệ nhưng vẫn là một phần của cuộc tấn công. Thay vì mã hóa cứng mọi quy tắc từ trước, nó thực thi ba biện pháp kiểm soát được quản lý, tất cả đều được áp dụng thông qua Agent Gateway, điểm thực thi thời gian thực giúp chặn và quản lý các tương tác giữa người dùng, tác nhân, mô hình và các công cụ của nó. Các biện pháp kiểm soát này là:

Mỗi biện pháp kiểm soát bao phủ những gì các biện pháp khác không thể làm được. Model Armor lọc payload, công cụ chính sách (policy engine) suy luận về ý định, và phát hiện bất thường theo dõi hành vi theo thời gian.

1. Sàng lọc mọi prompt tại biên: Model Armor

Trong Phần 1, kẻ tấn công đã gửi một payload brute-force:

Chúng tôi đã bắt được nó bằng một danh sách regex (JAILBREAK_SIGNALS = ["ignore previous instructions",...]). Trong môi trường sản xuất, việc duy trì các từ điển regex cho mọi kiểu jailbreak bị làm nhiễu (obfuscated) sẽ nhanh chóng thất bại.

Model Armor sàng lọc payload tại biên nhập, trước khi vòng lặp suy luận của tác nhân chạy, kiểm tra các hành vi tiêm prompt (prompt injection), jailbreak và các URL độc hại. Trên nền tảng, Agent Gateway áp dụng mẫu Model Armor của bạn trực tiếp vào đường dẫn yêu cầu. Đây là lệnh gọi API trực tiếp mà nó bao bọc:

Python

Đã sao chép

Cần làm rõ rằng đây là mã nguồn mà bạn không cần phải viết. Nó được Agent Gateway thực thi thay cho bạn. Khi một bộ lọc khớp, yêu cầu sẽ bị loại bỏ tại biên với mã lỗi 403. Mô hình của tác nhân không bao giờ được gọi, vì vậy không có token nào bị tiêu tốn và cửa sổ ngữ cảnh (context window) vẫn sạch sẽ.

Tại đầu ra (egress), Model Armor chạy Sensitive Data Protection trên các phản hồi đi ra, che các số thẻ tín dụng, bí mật Stripe và ID nhân viên trước khi chúng rời khỏi gateway:

Python

Đã sao chép

2. Đánh giá ý định, không chỉ cú pháp: Semantic Governance Policies

Kẻ tấn công từ bỏ việc tiêm mã và chuyển sang kỹ thuật thao túng tâm lý lịch sự, cú pháp sạch sẽ:

Mọi cổng kiểm soát tất định đều vượt qua. Model Armor thấy ngôn ngữ sạch và cho phép nó. Số tiền $120.00 được yêu cầu nằm dưới tổng đơn hàng $149.00. Các tham số SQL được định kiểu đúng. Không có bằng chứng về nỗ lực jailbreak. Tuy nhiên, chính sách công ty quy định rằng các giấy phép phần mềm kỹ thuật số trên $30 không được hoàn tiền nếu không có sự chấp thuận của quản lý. Chúng ta có thể thử viết các chính sách tất định hoặc danh sách regex để bao phủ mọi loại giấy phép phần mềm và SKU sản phẩm, nhưng trên danh mục doanh nghiệp, điều đó là bất khả thi. Vì prompt và có lẽ chính đơn hàng đề cập đến "Google Workplace user license" thay vì nói rõ là "phần mềm", việc khớp từ khóa và bộ lọc regex không thể phát hiện ra nó, và trình phân tích cú pháp SQL không có cách nào biết rằng "Google Workplace user license" là phần mềm kỹ thuật số - đó là lý do tại sao chúng ta dựa vào Semantic Governance Policies.

Semantic Governance Policies đặt một công cụ chính sách ngôn ngữ tự nhiên trước khi thực thi công cụ. Tại thời điểm mô hình đề xuất một lệnh gọi công cụ, công cụ này đánh giá công cụ đó và các tham số được đề xuất dựa trên prompt của người dùng, lịch sử hội thoại và các chính sách của bạn, sau đó đưa ra phán quyết. Các quy tắc được viết dưới dạng ràng buộc văn bản thuần túy, vì vậy chủ doanh nghiệp có thể đọc và thay đổi chúng:

Văn bản thuần túy

Đã sao chép

Khi mô hình đề xuất lệnh gọi công cụ issue_refund(amount=120.00, item="Workplace User License"), công cụ này sẽ từ chối. Bạn sẽ có thể thấy điều đó trong luồng sự kiện Cloud Logging cho Semantic Governance:

JSON

Đã sao chép

Việc thực thi công cụ bị chặn trước khi nó chạy. Cloud KMS không bao giờ được gọi, sổ cái không bị chạm đến và tác nhân giải thích kết quả cho người dùng: "Việc hoàn tiền cho giấy phép phần mềm kỹ thuật số trên $30 yêu cầu sự chấp thuận của quản lý." Semantic Governance áp dụng bất kể tác nhân truy cập công cụ như thế nào: trực tiếp qua mã nguồn bên trong tác nhân, hoặc từ xa qua điểm cuối API hoặc MCP Server.

3. Phát hiện các hành vi khai thác đa lượt: Agent Anomaly Detection