An attacker does not need to defeat hardware isolation if vulnerable software inside the protected environment already handles the plaintext. NEAR AI's 9 November incident report describes a SGLang remote code execution flaw on one inference server and possible observation of confidential requests processed there on 8 November.
For organizations buying private AI inference, the incident raises two separate questions. Which information was actually taken? And which parts of the service remain trusted even when the hosting operator cannot read its memory?
Confirmed access and possible exposure are different findings
NEAR AI reported stolen account details for approximately 100 Private Chat users and chat history, settings and logs retrieved from 18 legacy agents outside its trusted execution environment. Two customers' exposed Cloud API keys were revoked. It found no indication of access to stored Private Chat conversations or uploaded files.
Its report says it fixed inference servers, rotated credentials and restored Cloud access, without naming an exploited CVE or affected SGLang versions. Those omissions prevent a defensible mapping to a particular upstream release.
The approximately 100 accounts and 18 agents therefore describe confirmed access to specific systems. They are not a count of confidential prompts observed. Treating every potentially observable request as proven theft would overstate the finding; treating the confirmed account count as the complete exposure would understate the uncertainty.
The application remained inside the trust boundary
Confidential computing separates a protected workload from adversaries outside its boundary. The workload still needs to process readable inputs. If an attacker gains execution in the software entrusted with those inputs, memory isolation from the host does not remove that software's access.
NVIDIA's confidential-VM threat model makes this division explicit. Guest software, including the kernel, driver, libraries and workload, remains trusted. The host operating system and hypervisor sit outside that runtime trust boundary. The model also lists vulnerable tenant software and sensitive logging among the ways protected assets can still be exposed.
That documentation explains a general security boundary; it does not establish the exact layout of NEAR AI's compromised deployment. The public incident account does not provide enough detail to reconstruct the attack path between every service. It supports an application-compromise explanation, rather than evidence that the attacker broke the underlying CPU or GPU isolation mechanism.
Attestation can approve vulnerable software
Remote attestation supplies evidence about an environment. Under the IETF's RATS architecture, published as RFC 9334 in January 2023, a verifier evaluates that evidence against policy, then a relying party uses the result to make a trust decision. Authentic evidence and an appropriate acceptance policy are separate requirements.
Consider an illustrative service that releases a model key only to an approved software build. If that build contains an undiscovered request-processing flaw, a correct attestation result can still precede an application compromise. This is a hypothetical example, not a reconstruction or runtime test of NEAR AI's system.
The response to a software vulnerability must consequently reach beyond proving that the expected binary is present. Operators also need a way to withdraw approval for vulnerable builds and accept replacements. Attestation makes those decisions enforceable; it does not decide which application code is safe.
Downstream integrations require their own exposure evidence
Brave's 15 October technical announcement describes Leo's encrypted inference integration with NEAR AI. It says the browser encrypts requests to an attested environment, while Brave's relay separates the user's IP address from the prompt. Its verification design checks hardware evidence and approved software images. The third-party model runtime is pinned through a deployment log rather than rebuilt from source.
Those are meaningful protections against interception and unauthorized infrastructure access. They do not imply that a vulnerable approved runtime becomes harmless. Nor does a commercial integration prove that its users' requests passed through the compromised server. Neither the NEAR AI report nor the cited Brave announcement establishes that Leo conversations were affected.
Our confidential GPU computing explainer examines the underlying attestation and key-release model. This incident adds a narrower operational concern: a service can have hardware-backed confidentiality while its inference application and adjacent systems still create paths to sensitive information.
Legacy services belong in the security assessment
The public findings span inference, a deprecated chat product, legacy agents and credentials in logs. Evaluating only the enclave would miss much of that confirmed loss. For a buyer, a confidential-inference claim needs an accompanying account of service separation, credential reach and the retirement of old products.
The most valuable follow-up disclosure would identify the vulnerable SGLang component, affected releases and the scope of request exposure. Until then, a provider's statement that its own deployment is fixed cannot serve as an upstream version advisory for every organization using SGLang.