Open Agent Safety Platform: AI Agent cần một lớp an toàn nằm ngoài chính nó

AI Agent đang dần vượt khỏi vai trò của một hệ thống chỉ tạo câu trả lời. Khi được kết nối với công cụ, dữ liệu, API và môi trường thực thi, Agent có thể tự viết mã, sử dụng công cụ, truy cập dịch vụ bên ngoài và thực hiện một chuỗi hành động để hoàn thành nhiệm vụ.

Khả năng tự chủ càng cao thì một câu hỏi càng trở nên quan trọng: nếu Agent đưa ra quyết định sai hoặc đi ra ngoài phạm vi được giao, lớp nào trong hệ thống sẽ thực sự ngăn hành động đó xảy ra?

Đây là vấn đề NVIDIA tập trung vào khi giới thiệu Open Agent Safety Platform. Thay vì đặt toàn bộ trách nhiệm an toàn lên model, prompt hay chính Agent, kiến trúc mới đưa một phần cơ chế kiểm soát xuống runtime và hạ tầng — những lớp nằm ngoài phạm vi mà Agent có thể tự thay đổi.

Khi Agent không chỉ “trả lời” mà bắt đầu “hành động”

Với chatbot truyền thống, phần lớn rủi ro nằm ở nội dung đầu ra. Model có thể trả lời sai, thiếu thông tin hoặc hiểu sai câu hỏi, nhưng hành động cuối cùng thường vẫn do người dùng quyết định.

Agent thay đổi mô hình này.

Một Agent có thể nhận mục tiêu, lập kế hoạch, gọi công cụ, viết code và tiếp tục điều chỉnh cách làm khi gặp lỗi. Để làm được việc hữu ích, Agent cũng cần quyền truy cập vào workspace, tài nguyên tính toán, dữ liệu, thông tin xác thực và các dịch vụ bên ngoài.

Điều đó đồng nghĩa một lỗi không còn chỉ dừng lại ở câu trả lời. Agent có thể thay đổi dữ liệu production, truy cập thông tin không nằm trong nhiệm vụ hoặc thực hiện một hành động ngoài phạm vi ban đầu. NVIDIA xem đây là lý do các hệ thống Agent cần một lớp kiểm soát độc lập thay vì chỉ dựa vào khả năng tự tuân thủ của model.

Prompt không phải là ranh giới bảo mật

System prompt, guardrail và các quy tắc trong Agent vẫn cần thiết. Chúng giúp model hiểu điều gì nên làm và điều gì không nên làm.

Nhưng về bản chất, đó vẫn là hướng dẫn mà hệ thống AI phải tự diễn giải.

Nếu một Agent được cấp shell, quyền chạy code hoặc khả năng gọi API, việc viết trong prompt rằng “không được truy cập tài nguyên này” không tương đương với việc hệ thống thực sự ngăn kết nối đó xảy ra.

Sự khác biệt nằm giữa hai khái niệm khá đơn giản:

Hướng dẫn hành vi: nói cho Agent biết nó nên hoặc không nên làm gì.
Thực thi quyền hạn: hệ thống chỉ cho phép những hành động nằm trong phạm vi đã được cấp.

Open Agent Safety Platform được xây dựng xoay quanh lớp thứ hai.

NVIDIA liên hệ cách tiếp cận này với quá trình phát triển của Internet. Trình duyệt trở nên an toàn hơn không phải vì mọi website đều được yêu cầu phải hành xử tốt, mà vì mã từ website được đặt trong những môi trường có ranh giới rõ ràng. Sandbox của trình duyệt trở thành một lớp tin cậy nằm giữa nội dung từ Internet và hệ thống của người dùng.

Với Agent, NVIDIA cho rằng một lớp tương tự đang trở nên cần thiết.

Vấn đề “drift” khi Agent làm việc trong thời gian dài

Một Agent không nhất thiết đi sai ngay từ bước đầu tiên.

Nó có thể thực hiện đúng hàng trăm bước trước khi gặp một API bị chặn, một công cụ không hoạt động hoặc một yêu cầu chưa đủ rõ ràng. Khi cách đầu tiên thất bại, Agent thử cách khác. Nếu cách đó tiếp tục không thành công, nó có thể tiếp tục tìm những con đường mới để hoàn thành mục tiêu.

NVIDIA sử dụng khái niệm drift để mô tả những hành động dần rời khỏi nhiệm vụ hoặc giới hạn vận hành ban đầu.

Drift có thể xuất hiện do policy chặn một thao tác, lỗi phần mềm, thiếu công cụ, chỉ dẫn mơ hồ hoặc đơn giản là Agent được để chạy trong thời gian dài để giải quyết một bài toán khó.

Điểm cần lưu ý là Agent không nhất thiết phải có ý định xấu. Nó có thể chỉ đang cố hoàn thành mục tiêu được giao bằng những lựa chọn còn lại mà nó nhìn thấy. NVIDIA cho rằng trong những tình huống như vậy, không nên kỳ vọng Agent có thể hoàn toàn tự quản lý hành vi của chính nó.

OpenShell: đặt ranh giới ở runtime

Thành phần trung tâm ở lớp runtime của kiến trúc này là NVIDIA OpenShell.

OpenShell là một runtime mã nguồn mở dành cho AI Agent. Thay vì yêu cầu phải viết lại Agent theo một framework riêng, runtime được đặt xung quanh workload hiện có và kiểm soát những tài nguyên mà Agent được phép sử dụng.

Mỗi Agent có thể chạy trong một sandbox với chính sách riêng. Người vận hành xác định phạm vi truy cập đối với file, network, service, process và credential. Những giới hạn này được thực thi bên ngoài workload của Agent.

OpenShell hiện được tổ chức quanh ba thành phần chính:

OpenShell Gateway quản lý vòng đời và policy của nhiều sandbox.
OpenShell Supervisor chạy bên ngoài workload và kiểm tra các request đi ra ngoài theo policy.
OpenShell Sandbox chạy Agent cùng các công cụ cục bộ với những giới hạn ở mức hệ điều hành đối với filesystem, process và network.

Điểm quan trọng là các giới hạn này vẫn tồn tại khi Agent mở shell, chạy đoạn code vừa tạo, khởi tạo process con hoặc giao việc cho sub-agent. Agent có thể thay đổi cách giải quyết bài toán, nhưng không thể tự bỏ đi ranh giới mà runtime đã đặt ra.

Không phải chỉ chặn một địa chỉ mạng

Kiểm soát network ở cấp Agent cần chi tiết hơn việc đơn giản cho phép hoặc chặn kết nối tới một domain.

Một API có thể hỗ trợ cả đọc và ghi dữ liệu. Agent có thể cần quyền đọc để hoàn thành nhiệm vụ nhưng không nhất thiết cần quyền thay đổi dữ liệu.

OpenShell Supervisor có thể kiểm tra lưu lượng HTTP, GraphQL và MCP đã được cấu hình để áp dụng policy ở mức thao tác. Ví dụ, cùng một dịch vụ có thể cho phép truy vấn dữ liệu nhưng từ chối request thay đổi dữ liệu.

Cách tiếp cận này cho phép quyền của Agent được xác định gần với nhu cầu thực tế của từng nhiệm vụ hơn, thay vì cấp toàn bộ quyền truy cập vào một dịch vụ chỉ vì Agent cần sử dụng một phần nhỏ của nó.

Credential không cần nằm trong tay Agent

Thông tin xác thực là một trong những phần nhạy cảm nhất khi Agent được kết nối với hệ thống doanh nghiệp.

Nếu API key hoặc token tồn tại trực tiếp trong môi trường mà Agent có thể đọc, đoạn code do chính Agent tạo ra cũng có khả năng tiếp cận chúng. Khi Agent có quyền chạy lệnh và tạo chương trình mới, đây là một ranh giới rất khó kiểm soát chỉ bằng prompt.

OpenShell hỗ trợ tách credential khỏi workload của Agent. Agent có thể sử dụng một dịch vụ đã được cấp quyền mà không cần trực tiếp sở hữu thông tin xác thực thực tế. Runtime giữ credential bên ngoài workload và chỉ sử dụng chúng cho những request phù hợp với policy.

Điều này không loại bỏ mọi rủi ro, nhưng giúp thu hẹp đáng kể phạm vi mà Agent và đoạn code do Agent sinh ra có thể tiếp cận.

Policy cũng cần được kiểm chứng

Một policy có thể trông hợp lý khi đọc từng rule riêng lẻ nhưng vẫn tạo ra một con đường ngoài dự kiến khi các quyền được kết hợp với nhau.

Ví dụ, một công cụ có thể bị giới hạn ở quyền đọc. Nhưng nếu Agent đồng thời có khả năng chạy code, truy cập network và sở hữu credential có quyền ghi, việc giới hạn riêng công cụ ban đầu chưa chắc đã tạo thành một ranh giới hoàn chỉnh.

OpenShell đưa thêm bước formal policy verification vào quá trình này. Policy prover được dùng để phân tích các quyền đã mô hình hóa và chỉ ra khi quyền được yêu cầu vượt ra ngoài ranh giới xác định.

Điểm đáng chú ý ở đây là policy không chỉ được sử dụng lúc Agent đang chạy. Nó còn trở thành một đối tượng có thể được kiểm tra trước khi Agent bắt đầu hoạt động.

Ba lớp của Open Agent Safety Platform

Open Agent Safety Platform chia hệ thống thành ba lớp khá rõ ràng:

Application

Đây là những gì người phát triển trực tiếp xây dựng: model, Agent framework, tool, dữ liệu, script và logic phục vụ nhiệm vụ.

Runtime

Runtime đưa workload của Agent xuống hạ tầng thực tế và chịu trách nhiệm về sandbox, policy, giám sát cũng như thực thi quyền. OpenShell nằm ở lớp này.

Infrastructure

Đây là tài nguyên thực mà Agent sử dụng: CPU, GPU, network, storage và các thành phần xử lý bên dưới.

Việc tách ba lớp giúp cơ chế kiểm soát không bị đặt hoàn toàn bên trong application — cũng chính là nơi Agent đang hoạt động.

Đây cũng là nền tảng để NVIDIA bổ sung một lớp quan sát khác ở hạ tầng thông qua NVIDIA Sentry.

Sentry: đưa lớp giám sát ra khỏi máy chủ của Agent

OpenShell kiểm soát Agent ở runtime. NVIDIA Sentry mở rộng mô hình này xuống lớp hạ tầng.

Trong kiến trúc tham chiếu của NVIDIA, Sentry chạy trên BlueField-4 DPU và hoạt động như một lớp giám sát độc lập với host đang chạy Agent.

Thông qua NVIDIA DOCA, lớp này có thể kết hợp thông tin về tương tác của Agent, quyết định policy cũng như việc truy cập tool và dữ liệu để xây dựng bối cảnh về hoạt động đang diễn ra.

Vị trí của lớp giám sát có ý nghĩa quan trọng. Nếu cơ chế bảo vệ nằm trên cùng host với workload cần được giám sát, một sự cố trên host có thể ảnh hưởng đồng thời tới cả workload lẫn cơ chế bảo vệ.

Trong thiết kế Vera Rubin POD mà NVIDIA mô tả, BlueField-4 nằm trên đường kết nối của node tới model. Nhờ nằm ngoài host, DPU có thể cung cấp khả năng quan sát và thực thi policy độc lập với Agent đang chạy trên máy chủ.

Sentry là một lớp bổ sung chứ không phải điều kiện bắt buộc để sử dụng OpenShell. NVIDIA cho biết Open Agent Safety Platform được tối ưu cho hệ thống Vera CPU và BlueField DPU nhưng vẫn tương thích với các nền tảng phần cứng khác.

Năm nguyên tắc NVIDIA đặt ra cho Agent Safety

Từ quá trình xây dựng OpenShell, NVIDIA đưa ra năm nguyên tắc cho một hệ thống Agent có khả năng kiểm soát tốt hơn.

1. Policy phải có khả năng kiểm chứng

Trước khi Agent chạy, cần có cách xác định policy thực tế cho phép Agent làm những gì và liệu các quyền kết hợp có vượt khỏi ý định ban đầu của người vận hành hay không.

2. Cơ chế thực thi phải nằm ngoài Agent

Agent không nên có khả năng trực tiếp sửa hoặc vô hiệu hóa lớp đang kiểm soát chính nó.

3. Đường tới model là một điểm kiểm soát quan trọng

Agent cần model để tiếp tục suy luận và lựa chọn bước tiếp theo. Vì vậy, NVIDIA xem đường giao tiếp tới model vừa là điểm quan sát quan trọng vừa là nơi có thể ngắt quá trình khi cần thiết.

4. Quyền của Agent càng lớn, khả năng quan sát càng phải cao

Một Agent chỉ đọc tài liệu và một Agent có khả năng thay đổi dữ liệu production không thể được quản lý với cùng mức độ quan sát và kiểm soát.

5. An toàn là trách nhiệm của nhiều lớp

Model provider, đơn vị triển khai và nhà cung cấp hạ tầng đều kiểm soát những phần khác nhau của hệ thống. Vì vậy, NVIDIA đặt Agent Safety theo mô hình shared responsibility thay vì kỳ vọng một lớp duy nhất giải quyết toàn bộ vấn đề.

Một thay đổi đáng chú ý trong cách xây dựng AI Agent

Trong giai đoạn đầu của Agentic AI, phần lớn nỗ lực thường tập trung vào việc làm cho Agent có khả năng thực hiện nhiều việc hơn: gọi nhiều tool hơn, lập kế hoạch dài hơn, tự sửa lỗi tốt hơn và hoạt động độc lập lâu hơn.

Khi những khả năng này bắt đầu được đưa vào hệ thống thực tế, bài toán tiếp theo không chỉ còn là Agent có thể làm gì, mà còn là Agent được phép làm gì.

Hai câu hỏi nghe khá giống nhau nhưng thuộc về hai lớp hoàn toàn khác nhau.

Khả năng của Agent đến từ model, tool và workflow. Quyền hạn của Agent nên đến từ một cơ chế kiểm soát độc lập.

Đây là điểm xuyên suốt trong Open Agent Safety Platform.

Không cần cấp toàn bộ quyền ngay từ đầu

Một cách triển khai khá thuận tiện trong giai đoạn thử nghiệm là cấp cho Agent nhiều quyền hơn mức nó thực sự cần. Điều này giúp giảm lỗi permission và làm cho Agent dễ hoàn thành nhiệm vụ hơn.

Nhưng mô hình đó trở nên khó kiểm soát khi Agent được kết nối với nhiều hệ thống hoặc bắt đầu xử lý công việc trong thời gian dài.

OpenShell hỗ trợ một hướng khác: Agent bắt đầu với policy xác định. Khi gặp một nhiệm vụ cần thêm quyền, thay đổi policy có thể được đưa ra ngoài workload để người vận hành hoặc hệ thống quản trị xem xét.

Agent vẫn có thể linh hoạt trong cách giải quyết bài toán nhưng không đồng nghĩa với việc nó phải sở hữu toàn bộ quyền ngay từ đầu.

Từ AI Safety đến Systems Security

Khi AI chỉ tạo nội dung, phần lớn câu chuyện an toàn tập trung vào model: chất lượng dữ liệu, alignment, guardrail và cách model phản hồi người dùng.

Khi AI bắt đầu được trao quyền hành động, những nguyên tắc quen thuộc của bảo mật hệ thống trở nên quan trọng không kém.

Authentication, authorization, isolation, least privilege, audit trail và policy enforcement đều là những khái niệm đã tồn tại từ lâu trong kỹ thuật phần mềm. AI Agent không làm những nguyên tắc này mất đi. Ngược lại, khả năng tự chủ của Agent khiến chúng cần được áp dụng chặt chẽ hơn.

Một hệ thống database không được thiết kế dựa trên giả định mọi ứng dụng sẽ luôn gửi truy vấn đúng. Một hệ thống mạng cũng không dựa vào giả định mọi process đều sẽ hành xử đúng.

Agent cũng cần được nhìn theo cách tương tự.

Open Agent Safety Platform đang hướng tới điều gì?

Thông điệp xuyên suốt trong kiến trúc mới của NVIDIA khá rõ ràng: khả năng tự chủ của Agent không nên đồng nghĩa với quyền tự kiểm soát mọi ranh giới của chính nó.

Model vẫn cần được huấn luyện tốt. Prompt vẫn cần rõ ràng. Guardrail vẫn cần tồn tại. Nhưng khi Agent có thể tác động tới hệ thống thực, những cơ chế đó không nên là lớp bảo vệ cuối cùng.

Open Agent Safety Platform bổ sung một cách tiếp cận gần hơn với kiến trúc bảo mật truyền thống:

Application tạo ra khả năng của Agent.
Runtime kiểm soát phạm vi hoạt động.
Infrastructure tạo thêm một lớp quan sát và thực thi độc lập.

OpenShell hiện thực hóa phần runtime bằng sandbox, policy, kiểm soát service và credential. Sentry tiếp tục đưa khả năng quan sát xuống hạ tầng thông qua BlueField.

Đây chưa phải lời giải cuối cùng cho bài toán an toàn của AI Agent. Hệ sinh thái Agent vẫn đang thay đổi rất nhanh và những mô hình triển khai thực tế chắc chắn sẽ tiếp tục phát triển.

Nhưng khi Agent bắt đầu được sử dụng cho những công việc kéo dài, truy cập dữ liệu doanh nghiệp hoặc tương tác trực tiếp với hệ thống production, việc xây dựng một ranh giới mà Agent không thể tự vượt qua sẽ không còn là phần bổ sung phía sau.

Nó cần trở thành một phần của kiến trúc ngay từ đầu.

____
Bài viết liên quan