Before an AI agent can act on behalf of a business, someone has to decide what it is allowed to do. When that action causes harm, someone also has to answer for the consequences.
In his September 28 CNBC interview, NVIDIA CEO Jensen Huang describes himself as “a responsible optimist.” His argument connects the usefulness of AI to the public’s confidence that it can be built and deployed safely. He makes that case through a familiar piece of technology: the web browser. [1]
The analogy caught my attention because it connects two parts of my work: cybersecurity and commercial insurance. We are giving software more responsibility inside businesses while trying to understand how its actions fit into existing controls, contracts, and insurance policies.
The interview moves from containment and monitoring to liability, industry standards, regulation, competition with China, and model distillation. I recommend watching the full conversation. Its central security argument is worth understanding, and its insurance implications deserve a close look.
What the browser teaches us
Think about opening an unfamiliar website while your banking session is open in another tab. Your security should not depend on the unfamiliar website voluntarily respecting your financial information.
Browsers enforce boundaries. In Chrome, for example, sandboxing restricts what a web-content process can do to the computer. Site Isolation helps separate sites into different processes and limits access to other sites’ sensitive data, including when a process is compromised. These protections reduce the damage a malicious page can cause. They do not make every page trustworthy. [2]
Huang’s proposal applies that containment principle to AI agents. His starting point is direct: “the first thing you do is you take away all of its rights.” Access to files, tools, data, and networks is then granted according to the task. He compares this to employees receiving badges and access appropriate to their jobs. Intelligence does not establish a need for unrestricted authority. [1]
An agent may read documents, select tools, and carry out several steps toward an objective. Its operating environment must determine which files it can read, which records it can change, and which destinations it can contact. Those permissions need to be enforced outside the agent’s own reasoning. [3]
Figure 1. An explanatory analogy, not an equivalence between browser architecture and AI architecture. Each boundary still needs implementation and testing.
The controls surrounding the model
Huang repeatedly frames containment as a technically solvable engineering problem. That directs attention toward controls we can build, test, and improve. It remains an argument for doing the engineering work, rather than evidence that every AI risk has already been resolved. [1]
NVIDIA’s September 28 announcement describes two components of its Open Agent Safety Platform. OpenShell provides a runtime boundary around agent execution. Sentry adds independent monitoring and enforcement on BlueField-4 data processing units, separate from the agent’s operating environment. NVIDIA says Sentry can quarantine agents that attempt to cross their boundaries within milliseconds. [4]
The architectural principle is useful: a system being monitored should not be able to rewrite or disable its own controls.
Huang also emphasizes why OpenShell is open source. He wants outside researchers and companies to inspect the code, find weaknesses, and contribute fixes. When asked about OpenAI’s absence from the participant list, he welcomes its participation rather than treating that absence as evidence of indifference. [1] Public code makes scrutiny possible; the resulting security still depends on the quality of review, implementation, and maintenance.
A prompt asking an agent to behave safely helps communicate intent. An authorization check determines whether a requested action can actually execute. Those mechanisms perform different jobs.
OWASP calls attention to excessive agency: systems with more functionality, permission, or autonomy than their task requires. An error or manipulated instruction can become a damaging action when the surrounding system allows it. [5]
Consider a hypothetical invoice-processing assistant. It needs to extract invoice details and prepare a payment recommendation. That does not establish a business need to change supplier bank details, release funds, or export the accounting database.
I would design those capabilities separately. Extracting approved fields could proceed automatically. A change to payment instructions would require verification through an established process. Sending sensitive records to an unapproved destination would be blocked. A request from the agent would never, by itself, expand its authority.
Figure 2. A hypothetical design. Approval requirements and technical permissions are set by the organization and enforced independently of the agent.
The test is what happens when the agent makes the wrong request. NVIDIA’s engineering guidance recommends testing unauthorized credential access, data transfers, permission changes, and interference with monitoring, then repeating tests after material changes. [3]
A secure boundary still permits mistakes
The browser analogy also has a limit. A browser cannot guarantee that the information on an allowed website is true. An AI agent can remain inside its permissions and still make a consequential mistake.
Our invoice assistant might misread an amount in an approved document and prepare an incorrect payment recommendation. No sandbox escape is necessary. The business still needs validation, reconciliation, and a reviewer who has enough context to challenge the result.
Security asks whether access and actions are controlled. Reliability asks whether the system performs its job correctly. Safety asks what harm can result when it does not. These concerns overlap, and each needs attention.
For consequential workflows, I would want the approval screen to show the proposed action, its supporting evidence, and any unresolved uncertainty. A human clicking a button without that information provides a weak control.
This is also where I would qualify two parts of Huang’s argument. He credits faster development with improved grounding, tool use, and safety, and describes hallucination as solved. Those are different claims. NIST identifies confidently false output, or confabulation, as a risk requiring management. An improvement in a model or workflow does not establish that the risk has disappeared across deployments. [1, 8]
He also discusses potentially monitoring an agent’s expressed reasoning. That may provide useful signals, but it is not complete visibility into a model’s internal process. Anthropic’s research on earlier reasoning models found that their explanations did not always disclose factors influencing their answers. That study does not settle the behavior of every current model, but it supports treating reasoning traces as one source of evidence alongside observed actions and enforced permissions. [1, 9]
Where responsibility meets insurance
Huang says companies that know they have not adequately tested a product should hold it back. He also calls for applying existing laws and regulations. That is a substantive responsibility position, even as he argues against premature rules that could restrict a developing industry. [1]
One exchange is especially relevant to insurance. A host asks whether using OpenShell transfers liability to NVIDIA if an agent breaks out. Huang’s response turns to model hosting and the distinction between a model and an agent. He does not give a clear promise in that exchange that NVIDIA absorbs users’ liability. [1]
His analogy is that the model is the engine and the agent is the car. The model supplies capabilities; the surrounding software organizes work and connects those capabilities to tools. That helps explain why we must examine the entire deployed system. It does not establish that a model provider can never bear responsibility, or that a harmful output is inconsequential until an autonomous tool acts.
If an AI-supported workflow gives a customer incorrect advice, investigators may need to examine the model, application design, source material, permissions, supervision, and the decision to deploy it. A model provider, software integrator, deploying business, or another participant may have relevant obligations. Identifying a technical failure does not automatically determine legal liability.
I would separate three questions in every review: what failed, who may be legally responsible, and whether an insurance contract responds. Applicable law, facts, contracts, and policy wording matter at different points in that analysis.
In my insurance work, AI exclusions are already part of the conversation. Published market guidance provides concrete examples. ISO’s optional CG 40 47 endorsement addresses generative AI exposures across CGL Coverages A and B. CG 40 48 addresses Coverage B. The distinction matters because the first reaches bodily injury and property damage as well as personal and advertising injury, while the second is narrower. [6]
These are optional forms. Their availability does not establish that every carrier uses them or that every AI-related loss is excluded. The definition of generative AI also matters; a reference to AI in a product description tells us little about how a particular exclusion applies.
An exclusion can leave a business retaining a loss for which it remains legally responsible. It does not remove the underlying exposure.
I would examine the full insurance program against specific loss scenarios. Cyber, professional liability, technology E&O, and other coverage may be relevant depending on the operation and the loss. None should be assumed to fill a CGL gap automatically. Equally, the absence of an AI exclusion is not an affirmative promise to cover every AI-related event.
The evidence I would want before deployment
For a business introducing an agent into a consequential workflow, I would start with a short operational record:
- The assigned task, approved data, available tools, and named business owner.
- The actions it can perform and the actions that require independent approval.
- Test results showing that prohibited actions are blocked and allowed outputs are checked.
- Protected records of requests, decisions, approvals, and outcomes, with appropriate retention and access limits.
- A practical way to revoke access, contain an incident, and restore the affected process.
- A review of relevant vendor obligations and insurance wording against plausible losses.
My view is that this evidence can make an underwriting conversation more specific. It gives an insurer something to examine beyond a general statement that the organization uses AI responsibly. It cannot guarantee coverage, favorable terms, or freedom from liability.
Standards and innovation belong in the same conversation
Huang’s regulatory position is more nuanced than opposition to oversight. He discusses industry standards, independent audits, and benchmarking. He wants policies that leave room for open models, young companies, and businesses adopting AI across many industries. Asked about frontier labs’ motives, he says he assumes their concerns are genuine while warning against regulatory capture, whether intentional or inadvertent. [1]
In the China discussion, he describes regulation as something that should develop as understanding of the technology improves. He also characterizes model distillation as competition and suggests that providers who object can restrict customer access. Those are his policy and commercial positions. The analogy to testing a competitor’s product does not, by itself, resolve questions about intellectual property, contracts, or authorized use. [1]
The interview closes with infrastructure investment and shareholder returns. The connection to the earlier discussion is clear in Huang’s own argument: broad adoption depends on public confidence in safe deployment. NVIDIA also has a commercial interest in that adoption. I would assess its proposed controls on evidence of what they prevent, detect, and contain.
The browser analogy makes a difficult subject accessible because it shows how useful access and enforceable limits can coexist. Applying that lesson to AI requires careful engineering and clear ownership of the business process.
For anyone deploying agents, my question is straightforward: can you show what the system is allowed to do, demonstrate what stops it from exceeding that authority, and explain who carries the consequences when it still gets something wrong?
Sources
- Jensen Huang CNBC interview, September 28, 2026. CNBC episode listing.
- Chromium, Site Isolation.
- NVIDIA, AI Security Is an Engineering Problem, September 21, 2026.
- NVIDIA, Open Agent Safety Platform announcement, September 28, 2026.
- OWASP, LLM06 2025 Excessive Agency.
- Independent Insurance Agents and Brokers of America, Verisk general liability exclusions, October 21, 2025.
- Gallagher, ISO Introduces Generative AI Exclusion in Commercial General Liability Policies.
- NIST, Generative Artificial Intelligence Profile, NIST AI 600-1.
- Anthropic, Reasoning Models Do Not Always Say What They Think.