AI Agents Should Not Be Their Own Security Witness
An agent can tell you that it followed the rules. That is not the same as independent evidence. When software can read files, call tools and make network requests, security teams need a view of those actions that the software itself cannot rewrite.
NVIDIA made this distinction unusually concrete in its October 21 technical account of Sentry. Its proposed architecture puts policy enforcement and observation on a BlueField-4 data processing unit, separate from the host running the agent. The announcement is an architecture and vendor description, not evidence that every enterprise can deploy it today. But the security principle matters well beyond one hardware stack: the actor and the witness should not share the same trust boundary.
What the agent's own log cannot prove
Imagine a coding agent asked to investigate a customer-facing bug. It has repository access and a tool that can fetch external documentation. A malicious instruction in a retrieved page tells it to include a private configuration file in a subsequent request. The agent may record a reassuring summary, or it may omit the detour altogether. Even a detailed self-reported trace is still produced inside the environment whose behavior is under investigation.
The first question is not, "Did the agent say it complied?" It is, "Which process requested which destination, with what authority, and what actually crossed the boundary?" An authorization decision must occur before the request, not only in a report after the fact. The example is a threat model, not a claim that a particular product or incident behaved this way.
Separate intent, execution and evidence
NVIDIA describes three distinct layers in Sentry. DOCA Flow restricts destinations, DOCA Tower inspects permitted communications and evaluates policies with Open Policy Agent, and DOCA Argus brings independent runtime context from host memory. In the reference design, BlueField sits on the agent's path to the model and outside world. NVIDIA says that correlation can tie a request to a process and container, and check attributes such as hashes and an approved software bill of materials.
That separation is more useful than a single "agent risk" score. Intent says what the task was. Execution shows the calls and data movement. Evidence says what an observer outside the agent's own control could verify. None alone settles whether a business outcome was right, but together they allow an investigator to identify the boundary crossed and the control that did or did not operate.
Hardware isolation is one way to build that observer. It is not the only deployment pattern, and a separate observer still has blind spots. TLS inspection requires configured traffic paths and appropriate privacy decisions. A host-isolated network view cannot automatically understand an employee's intent, every local file operation or an unmanaged device. Security teams should ask vendors for the exact collection point, permitted destinations, policy decision timing, bypass paths and evidence-retention boundary.
The workforce problem is adjacent, not identical
There is a second boundary many organizations encounter sooner: employees using third-party AI in a browser or desktop app. An agent runtime control does not automatically tell you which employee pasted a client file into a separate AI service. Conversely, visibility into employee AI use does not make you the independent runtime monitor for every autonomous agent in a data center. Treating these as the same product category creates a false sense of coverage.
For workforce AI, the practical sequence is to establish managed-device coverage, discover the tools people use, decide which data and applications are allowed, and apply the relevant prompt or file policy at the interaction point. Aona's Workforce AI Security platform focuses on that employee-use boundary through visibility, policy enforcement and sensitive-data protection. Its native endpoint has agent inspection in limited rollout, but that is not a claim to provide NVIDIA's hardware-isolated Sentry architecture or universal agent-action control. Read more about Shadow AI visibility and AI policy enforcement where those paths fit your deployment.
A test worth running this week
Pick one representative employee AI task and one agent task. For each, write down the identity, device or host, data classification, permitted tools and destinations, and the person who can stop or review an exception. Then run a harmless synthetic test: a prompt containing a fake sensitive identifier, or an agent trying to reach an unapproved test destination. Record what was blocked, what was merely logged, who received the evidence and whether the actor could alter it. Do not use real customer data to test the boundary.
If you cannot answer those questions, another dashboard is not the immediate fix. Map the missing observation and decision points first. If your priority is securing employees' use of AI tools, talk to Aona about a scoped evaluation of visibility and prompt/file controls on your actual managed-device paths.
