NVIDIA’s Nemotron release makes local inference a starting point for agent privacy checks

NVIDIA’s October 15 announcement introduced Nemotron 3.5 Super VL, a 120-billion-parameter model, alongside the smaller Bolt family. The company listed Super VL and Bolt 74B-A9B 24GB as available, with Bolt E4B 4GB scheduled for October 23. It describes Bolt as suitable for local agents and says workloads can stay off the cloud. These are vendor statements, not independent privacy findings.

TechCrunch covered the release on October 19; that reporting date should not be mistaken for the launch date. Our analysis focuses on a narrower buying question: what evidence would distinguish a locally running model from an agent whose entire handling of sensitive information has been checked?

Start with the task boundary

The following is a proposed evaluation method, not a report of tests performed on these models. Imagine an assistant that reads a confidential invoice, prepares a payment request and asks a person to approve it. Running inference on a workstation would answer where the model processes its input. It would not, by itself, establish where every other component sends or stores that invoice.

For that hypothetical task, draw the route before choosing a model: document intake, text extraction, inference, tool call, approval and retained record. Mark each step with the information it receives and the destination it can reach. An assessment that stops at inference would leave the payment connector and the retained record unexamined. Conversely, an external connection would need inspection of its actual payload before anyone could conclude that confidential content had left the device.

Separate a needed connection from an accidental disclosure

A useful test case could use a synthetic invoice containing a unique invented reference. Give the assistant an allowed destination for a payment request and a separate, harmless browsing task. Then examine whether the reference appears in either request, in saved logs or in a later session. Keep the test data artificial; there is no need to put a real customer’s account information into an unverified trial.

The expected result must be written first. If the approved payment request necessarily includes the invoice reference, observing that transmission would not demonstrate a leak. Finding the same reference in unrelated browsing would be a different result. The distinction is permission and purpose, rather than the presence of any network traffic. A browser connection alone is too coarse a measure for a confidentiality claim.

Record the configuration with the result: model version, agent application, enabled tools, logging settings and the precise task. Otherwise a successful test of a stripped-down demonstration could be presented as evidence for a more connected deployment that was never tested. Passing the exercise would support only the tested scope; it would not certify every future prompt or integration.

Keep permission separate from model quality

The invoice example also makes approval observable. In the proposed trial, ask the assistant to prepare a request while withholding authorization to submit it. A well-written summary and a correct total would be useful, but neither would answer whether the action boundary held. The separate acceptance condition is that no payment instruction reaches the destination before a person approves it.

Repeat with a document that contains irrelevant instructions to send its contents elsewhere. The purpose is to observe the application’s handling of untrusted document text, not to assume any particular weakness in Nemotron. An unexpected attempted action, a blocked action and a completed unauthorized action should be recorded separately. Combining them into one failure count would conceal the role of the surrounding controls.

Choose the deployment after defining the evidence

For this hypothetical buyer, the comparison should include successful completion, rejected actions, time to human approval and the information retained afterward. Use the same task and permitted tools across configurations. If one setup omits a required connector, it is not an equivalent solution simply because its model runs locally. If another completes the task but sends information to an unapproved destination, speed would not satisfy the stated requirement.

This method deliberately makes no claim about measured Nemotron performance, a recommended hardware purchase or the safety of a particular agent application. The release supplies candidates to evaluate. The application configuration, task permissions and observed data route would supply evidence for the deployment decision. Keeping those records separate makes a later change of model or connector easier to reassess without treating the original launch announcement as a permanent assurance.

Before approving a local agent, define one synthetic end-to-end task, its permitted destinations and its approval boundary; require a recorded result for that configuration.