Where NVIDIA (and Others) Got It Wrong

1. Summary

In the last week of September 2026, NVIDIA shipped its entry into the agent-safety market: an open-source sandboxed runtime, a hardware watchdog on a data-processing unit, and a set of principles that are individually correct but also incomplete. NVIDIA is joining a crowded field — AI guardrails, identity governance, credential vaults, behavioral analytics, data-security posture tools — each of which has also built something real. This paper is not an argument that any of them built the wrong thing. It is an argument that all of them built it in the wrong place.

The question the industry has answered is: how do we keep an agent from reaching what it shouldn’t? That’s the wrong question. The right question, the one that regulators are focused around and the question that really matters is: how do we keep an agent from doing the wrong thing? Those are two different questions, and the second one requires that you know what the semantic intent of the agent is. It’s one thing to restrict access to a hammer. It’s another to allow access to a hammer but only when you are pounding in a nail but not when you want to break into a safe. A sandbox cannot know what you mean when by ’accounts’ when you say “hedge all my accounts back to USD” (client accounts? Treasury accounts? Bank accounts?). A credential vault cannot know that twelve agents, each under its own cap, have jointly spent through the firms overall payment limit. A behavioral profile cannot tell the difference between an agent that drifted and a data warehouse that migrated. A pass-through token cannot tell an endpoint that the agent is trying to approve a payment it submitted last week, causing a breach of segregation of duties and a toxic combination fail on a payment.

As the saying goes, history doesn’t repeat but it does rhyme. Knight Capital is the historical precedent. On 1 August 2012 the firm lost about $440 million in forty-five minutes from a system that was inside every boundary it had. It was contained. It was authorized. It had logs and people watching. What it lacked was a gate that could decide, before the action, that the orders it was sending made no sense. Old code was restarted, it worked, it caused a meltdown. Everything NVIDIA shipped would have kept Knight’s system in its box. None of it would have saved Knight Capital.

Whether or not you believe that QuantEnt is the right solution for you, the industry needs to realize that the current protections being offered are partial and going to result in a dynamical tension between the AI not being able to do enough and having appropriate levels of protections. The granularity of the protection is wrong (you don’t permission the hammer, you permission the hammer and what you are going to do with the hammer). When granularity is wrong, people make the decision that chooses business growth at the expense of operational risk, and in the new world that is simply too dangerous.

2. What the market built

So, what did NVIDIA, and the industry in general, build.

NVIDIA Open Agent Safety Platform

Announced 28 September 2026. Two components. OpenShell is an Apache 2.0 runtime that executes each agent in its own sandbox with kernel-level isolation: no direct network access, no privileges, a restricted view of the filesystem, syscalls filtered in the kernel, and the agent’s requests brokered to a supervisor through a single secured channel for approval. The operator writes a policy over files, networks, tools, processes and credentials; a prover checks before launch that the policy cannot escape the operator’s intent; every allow and deny is logged. Effectively, we now have a static policy over a set of resources (not CAPABILITIES). Anyone who has managed IAM or IGA systems knows where this will go – endless certifications of capabilities you don’t really understand. Sentry is a reference design that runs out-of-band on BlueField-4 DPUs, sitting on the node’s only path to the model, correlating agent interactions, policy decisions and tool access into an attested activity record, and able to quarantine an agent in milliseconds. NVIDIA states five principles: verifiable policy, out-of-band enforcement, the path to the model as the control point, scaling agent authority with reasoning visibility, and a shared-responsibility model across labs, enterprises and hardware. The stated motivation is the series of 2026 incidents in which frontier-lab agents escaped evaluation sandboxes; NVIDIA’s own framing is a browser for agents. More than a hundred organizations have signed on, and Anthropic is working with NVIDIA on additional controls for its managed agents. Is this a classic case of organizations choosing brand and their need to please a supplier over a thoughtful approach to a problem (nobody got fired for choosing IBM), perhaps….

AI guardrails (Lakera, HiddenLayer and peers)

Inline inspection of prompts, tool calls and model outputs for injection, jailbreak, data leakage and policy violations, using classifiers, pattern matching and allow-lists. Fast, model-agnostic, deployable in front of any endpoint. The problem here is that each request is evaluated independently. It’s logic inside of an MCP endpoint. The obvious question – if the agent sees two MCP endpoints, one is payment approve and one is payment submit, what mechanism is there to prevent the agent from approving its own payment? Next generation attempts to have MCP endpoints speak to centralized repositories will end in an overly complex solution to something that would be better served at a different level.

Identity governance and administration (SailPoint, Saviynt, Entra ID Governance)

The system of record for who holds what: roles, entitlements, access requests, periodic certification, segregation-of-duties rules among human roles, and increasingly a registry for machine and agent identities. The unit of control is just giving an agent a footprint. The problem of course is that an agents permissions are really a combination of the user calling the agent and the agent itself.

Credential vaults and privileged access (CyberArk, Delinea)

Secrets are kept out of the agent’s hands and injected at the moment of use; sessions are brokered and recorded, and what is transferred around is the credential. The problem of course is how to decide who gets what credential – which is often the developer at build time, not an understanding of what the agent is trying to do at run time.

Behavioral analytics and observability (Exabeam, Securonix, and the agent-observability vendors)

Collection of events — calls, tokens, latencies, tool invocations, syscalls — into traces and profiles; anomaly detection against a learned baseline; alerting and forensics. Your unit of analysis is an event; the output is an analysis. Interesting, but this is after the fact. The operational event has already occurred and these elements help explain how it happened.

Data security posture (Cyera, Varonis)

Discovery and classification of sensitive data, mapping of who can reach it, detection of over-exposure and abnormal access. The unit of control is a data store; the control is reducing who can touch it.

The do-it-yourself pattern: pass the user through

Not a product but a practice, and the most common one in production today, and quite dangerous. The agent carries the end user’s identity to the tool endpoint — a pass-through token, an on-behalf-of header, a user ID in the prompt — and the endpoint applies the user’s permissions to whatever the agent asks. It is the pattern every MCP deployment reaches for first, because it reuses the authorization the enterprise already has. It’s the most dangerous because people think they’ve accomplished the task.

3. The Six Mistakes of NVIDIA, and others

Mistake 1 — They made the resource the unit of control.

There is a big difference between answering “may this process touch this thing?” and answering “is this the right thing to do?” Everyone answers the first question, you need to answer the second question.

The difference is not academic. If someone wants access to your email, the natural first question is “Why?” NVIDIA permissions an agent to access the email or not access the email. That’s not sufficient, permissioning is vastly more difficult without the why. An agent chartered to hedge treasury exposure has legitimate access to the trading endpoint, the account master and the FX rates. Inside its NVIDIA sandbox, with its vaulted credential, under its data-access policy, it is permitted to send an order executing an FX trade. Whether the order hedges the treasury accounts or the client accounts is invisible to every control in the stack, because “account” is a word, and the stack does not do words. NVIDIA’s own launch post diagnoses the problem correctly — the breakouts came from a mix of tools, time and ambiguous instructions — and then prescribes isolation, which treats the tools and leaves the ambiguity untouched. How does one implement a policy that you can’t touch client accounts? In the NVIDIA world, you can’t use their tool for that. You’ve got to go into the source systems and rewire and add entitlements with a custom user capability for agents. That’s neither quick, efficient, centralized, or maintainable.

What QuantEnt does instead. The unit of control is the business action: a capability exercised on a business object at a process step, for a declared purpose. Before anything runs, the request is resolved against the enterprise’s canonical vocabulary. If “account” has five valid meanings here, the agent is told so and nothing executes until the intended one is confirmed. The resolved action is then checked against the agent’s human-assigned operating surface and the limits that apply to that step. Clean, unambiguous, centralized, maintainable, transparent, diagnosable, and the way it should be. This is pre-action control with full semantic knowledge, and it is the only way we’ve seen that allows your control plane to know what the request means before deciding whether it may run.

Mistake 2 — They read the record as events. But you need to read it as a process.

Sentry produces an attested record of agent interactions and tool access; OpenShell logs every allow and deny; observability products collect traces by the billion. All of it is true and none of it is legible or easily diagnosable. A long list of imperative actions in a complex organization is opaque. A short list of declarative intent records is clean and satisfies regulatory requirements to know what the intent of the AI was. The record says that a process opened a socket, that a tool was called with a payload, that a syscall was blocked. It does not say which step of the quarter-end financial close the agent was intending to act on, on which ledger, and whether that is what it was chartered to do. Drift, in these products, is a statistical departure from a behavioral profile. If you are migrating your data warehouse, a behavioral analysis says “alert! It’s looking at something it’s never looked at before”, but in reality the agents intent and business action hasn’t changed at all. The firms topology changed, the agent didn’t.

What QuantEnt does instead. Every action in the ledger is aligned to the business process step and the business object it served, using the same canonical nouns that resolved the request. Drift is decomposed: environment-change events separate “the schema moved” from “the agent moved,” and intent drift is visible BEFORE the first out-of-lane action is attempted. The practical consequence is regulatory as well as operational: the EU AI Act asks for traceability appropriate to the intended purpose, and a purpose is a process step. A record in business language. Your auditors see agents continuing to do the same thing every days, not an impenetrable morass of imperative logs indicating actions on the topology of your network.

Mistake 3 — NVIDIA and others control and limit one transaction at a time. The limit that matters is across all of them.

Per-sandbox policy, per-request inspection, per-role entitlement, per-credential session. Each agent is judged one action at a time and inisolation, and each judgment can be correct while the fleet does something no one authorized. A normal limit a user might want is “No agent payment can exceed $100,000”. It’s simply not expressible in a resource contained ecosystem in a native way. An agent can call in the swarm and twelve agents each respect a $100,000 cap and with $20,000 here and $10,000 there jointly release $1.1 million through the payment gateway by lunch. The native thought to put this in the MCP endpoint is futile (do you have multiple payment systems? Multiple entry points? Multiple ways to move cash?)

Let’s ask a harder question. Let’s say you want to enforce that no Agent can both submit a payment and approve a payment. How does one do this? Suppose the agent submits a payment on Monday, and on Thursday it asks another agent to approve it. How does an NVIDIA like ecosystem stop that from happening? It can’t, and it won’t.

What QuantEnt does instead. Hard limits are expressions over all agents and on business quantities — dollars, notionals, record counts — scoped to a process step or a gate and evaluated across every principal that touches it. Onboarding an agent includes choosing its maximum daily damage, writing limits against business process steps, and importantly one can look back in time. Having a transaction log, with an agentic ID, lookback capabilities, and limits expressed against semantically valid business process steps, means that even the toughest limit is expressible and toxic combinations are avoided.

Mistake 4 — They optimize standing permissions. Standing permissions are the problem.

Identity governance has spent two decades getting better at least privilege: tighter roles, faster certification, smarter revocation. They still get it wrong and conflate user certification with actual controls (advertising note: to us about QuantCertify, you should be approving what risks and business process capabilities your employee has, not opaque sets of identifiers). The problem is that with agents you are trying to limit what an agent does, and standing permission sets often grant much wider capabilities than what an agent needs to do its job. An HR agent may have the right to look at compensation data, it may also have the right to send emails because it needs to send alerts and reminders. Does it have the right to load all of the firms employees compensation and personal data and then send that data in an email to all of your employees and to the local newspapers? In the NVIDIA world yes it does.

What QuantEnt does instead. Standing authority is driven to zero. Authority exists as a single-use, time-limited grant, bound to one approved operation and a hash of the exact request, verified offline at the endpoint. A grant is not a prediction; it is a decision, made at the moment of need with the meaning resolved and the limits checked. Because we see the whole request, we can say “any request involving distribution of data via email and personally identifiable information is banned”. The landscape everyone else is optimizing stops existing, one doesn’t need partial optimization. This is also why the agent nobody approved is prevented rather than discovered. A rogue agent has zero permissions from day one, it only gets the permission from QuantData after it is recognized and its authority is checked. The enterprise’s action plane accepts nothing without a grant (every MCP endpoint needs a fresh QuantData token to work), and an unregistered agent has no surface from which a grant could be issued, and so the agent someone launched last night holds nothing and can obtain nothing.

Mistake 5 — The agent tells the endpoints who its user is, and therefore carries all the authority of the user.

A CEO asks his news agent to look up some news on his competitors, does that news agent now carry all the authority of the CEO? It has his ID, his user token, could it pass this to an email agent and send out an email acting as the CEO? You wouldn’t let an employee walk around with the CEO’s login info, why let the agents?

Using the user token in calls to MCP enpoints is the mistake with the most production exposure today, because it is the default. The agent presents the user’s token to the MCP endpoint; the endpoint applies the user’s permissions. Three things are wrong with it. The endpoint cannot verify that the agent is acting on an instruction the user actually gave. The agent now holds a credential that confers everything the user can do, far beyond the task. And the user’s authority and the agent’s charter are evaluated in two places that never meet, so a combination that is individually permitted and jointly forbidden sails through. Security engineers have a name for this: the confused deputy. The identity-governance vendors’ answer — give the agent its own identity and its own role — does not fix it; it adds a second standing permission to the first.

NVIDIA’s DOCA gateway is the closest the sandbox layer comes, continuously verifying an agent’s identity and delegated scope. That is a real control and it is still a check on one principal against a policy file. It does not intersect two authorities on one request.

If your technology team is telling you don’t worry, they’re going to be careful with the MCP endpoint and it will enforce separation of duties and security and reduction in privileges with the user ID that is being passed to it…..do yourself a favor – worry. They haven’t thought it through and they are relying on everyone to code and implement to a certain standard where one mistake can lead to catastrophic outcomes.

What QuantEnt does instead. QuantEnt holds both principals in one place: the user’s authority is in QuantCertify represented as what risks and business processes the user can take, the agent’s operating surface in QuantData. The intersection is computed once, in the control plane, for the specific request (try to perform a intersection of user capabilities and agent capabilities and then represent this in a permission footprint dynamically, its not trivial). The grant is bound to the user, the agent and the exact action. The endpoint verifies the grant. It never sees, trusts or needs the user’s identity from the agent. A treasury analyst entitled to approve but not initiate a payment, working through an agent chartered to initiate, gets an empty intersection and no grant — a result no pass-through architecture can produce, because the information needed to produce it was never in one place. You don’t govern the agents by carefully never allowing the treasury analyst access to the agent (that’s just an operational disaster waiting for an accidental permission to trigger it), you govern it by ensuring that every request is checked against all the roles and responsibilities.

Mistake 6 — They made oversight available. It has to be summoned.

Every product in the stack has a human somewhere in its design. Guardrails block or allow and leave a log. IGA runs a certification campaign each quarter. Observability raises an alert into a queue. OpenShell brokers requests to a supervisor for approval — but the request a supervisor sees is a syscall or a network call, which is not a thing a human can meaningfully approve. In all of them the human is a resource that the system makes available: a dashboard to be checked, a queue to be worked, a campaign to be endured. The regulations now in force assume a competent person is overseeing the system, and are silent on how that person learns that something needs them. The answer, in practice, is the incident.

What QuantEnt does instead. Every ambiguous outcome is a question addressed to a named person who holds authority over that step. Ambiguity returns the candidate meanings and demands a choice. An out-of-mandate request returns the surface member that failed and the nearest chartered alternative. A limit breach, a drifting agent, a mutated request, an unregistered agent, two agents jointly assembling a maker-checker violation: each stops the action and routes a framed question with the decision evidence attached. The answer is recorded with the person’s identity, which is the EU AI Act’s Article 12(3)(d) record produced as a by-product. Override rates and rubber-stamp rates are reportable, which is how an institution proves that automation bias is managed rather than assumed away.

4. What NVIDIA and others got right.

Having spent the last few pages critiquing the current state, there are a few good capabilities and philosophies in these platforms. With the goal of being scientific about this analysis, let’s list a few of them.

• NVIDIA is right that enforcement must live outside the agent. An agent cannot be expected to govern itself; the control must be beyond its reach. QuantData agrees and is built the same way: the agent proposes, QuantData governs, and the governed endpoint verifies a grant the agent could not have forged. The two are the same philosophy at two different layers.

• NVIDIA is right that policy should be verifiable before launch and that the kill switch should be out of the agent. Readiness reports do the first job at the authority layer; halt-issuance and containment directives do the second. Sentry’s millisecond quarantine of a sandbox and QuantData’s negative time halt of grant issuance are complementary stops on different things. Why do we say QuantData is negative time? Because, it doesn’t wait till things start to go wrong and then gagues itself off of how many milliseconds until it shuts the agent down, it stops it even before the action starts, so pre-action and hence negative time.

• NVIDIA is right that the runtime and its policy language should be open. OpenShell brokers an agent’s requests to a supervisor through one secured channel. QuantData is a supervisor. Routing business-consequential requests from that channel to QuantData, and generating OpenShell resource policy from an approved operating surface, is a viable combination of the two platforms.

• Guardrails are right that the input needs inspecting. Prompt injection is real and semantic resolution does not replace injection defense. A guardrail in front of the model and QuantData in front of the action are not alternatives – you need both. These two concepts work very well together. In terms of threat-defense, injection defense is important, but the most likely future operational risks are not those where agents are corrupted, but from where agents do the wrong thing.

• IGA is right to be the system of record. QuantCertify reads it, enriches it with business process and blast radius, and never replaces it. A read-only overlay on Entra, SailPoint and Saviynt is the deployment model.

• Vaults are right that the agent should not hold the secret. A grant references a capability, not a credential; the vault still holds the key. The grant decides whether the key may be used for this operation.

• Observability is right that forensics need the full trace. The QuantData ledger is one more source for it, and the only one that says which business step each event served.

A sandbox keeps the agent in its box. QuantData decides what it may do from inside the box with the tools it legitimately holds. Nobody thinks the browser sandbox replaces the bank’s transaction authorization. Nobody should think it here. You need both, don’t just have one and think you are done.

5. The comparison

Six differentiators, plus the two places where the overlap with the sandbox layer is honest.

6. The regulatory consequence

The EU AI Act’s high-risk obligations apply from 2 December 2027 for stand-alone systems and 2 August 2028 for AI embedded in regulated products. The articles that matter — 12 (record-keeping), 26 (deployer duties) and 72 (post-market monitoring) — are written in the vocabulary of monitoring, but their substance keeps reaching for the action layer. Article 12 asks for traceability appropriate to the intended purpose and for logs that identify risk situations and substantial modifications. Article 26 asks the deployer to use the system per its instructions, to assign oversight to people with authority, to suspend on risk, and to keep the logs under its own control. Article 72 asks the provider to analyze the interaction between AI systems.

A resource-layer stack can produce a record. It cannot produce a record in the language of purpose, cannot say that an unapproved system was prevented from operating, cannot show that two agents’ interaction was governed rather than observed, and cannot show a human being asked. Our clause-by-clause assessment of the Act finds 48 requirements, of which 37 are met directly by a QuantData mechanism, 6 are shared with the organization, and 5 are organizational acts no software performs. The companion whitepaper, QuantData and the EU AI Act, sets out each one.

7. Conclusion

NVIDIA built the browser for agents, and it is a good browser. The industry around it built the inspection, the identity registry, the vault, the trace. All of it keeps the agent from reaching what it shouldn’t. None of it decides whether the agent should do what it is about to do, because none of it knows what that is. The loss in every major operational incident of the last fifteen years, from Knight Capital to the 2026 sandbox breakouts, occurred at the action, inside the boundaries, with the credentials in order and the logs intact. What wasn’t managed was the intent and the appropriateness, and the pre-action controls.

QuantEnt puts the control right before the action: meaning resolved, mandate checked, limits evaluated across the fleet, the user and the agent intersected, authority issued for one operation and no longer, and a person asked whenever the answer is unsure — with the record falling out of the decision rather than being assembled after it. The sandbox underneath is welcome, and good job to NVIDIA for formalizing it, but it is not the control.

About QuantEnt. QuantEnt makes business authority computable: modeling what every person and agent may do, pricing what it could cost, and approving every action before it happens. QuantCertify is the entitlements and business-authority platform; QuantData is the semantic control layer for agentic AI; QuantVault executes; QuantAI is the published standard and store through which agents bind to any enterprise that runs it. www.quant-ent.com.

Sources: NVIDIA, “NVIDIA Launches Open Agent Safety Platform” (28 Sept 2026); NVIDIA Technical Blog, “NVIDIA Open Agent Safety Platform: A Reference for Continuous In-Silicon Agent Monitoring” (28 Sept 2026); NVIDIA OpenShell product page; CNBC, 28 Sept 2026; SEC Release 34-70694, In re Knight Capital Americas LLC (2013); Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744. Descriptions of other vendor categories are at the category level and reflect public product positioning as of October 2026.

QuantEnt whitepaper, October 2026.