Use AI to Reconstruct an AI Inference Breach Without Guessing the Missing Evidence

Why this inference incident deserves a new review pattern

NEAR AI published a November 9 incident report saying an attacker exploited a remote-code-execution vulnerability in SGLang, the inference engine running on one of its servers. The company says the intruder could observe requests processed on that server on November 8, reached an internal system behind the deprecated Private Chat product, downloaded account details for about 100 users, accessed chat history, settings and logs for 18 legacy agents, and exposed two customers’ cloud API keys in logs. NEAR AI says it contained the incident, rotated credentials, deployed a fix across inference servers and notified affected users.

The Hacker News reported the incident on November 10, and other security outlets and threat-research pages analyzed the attack path. Those reports create a current-attention signal, not independent proof of every vendor finding. NEAR AI did not name the affected SGLang version or a CVE in its incident report. CERT/CC published a July advisory describing six other SGLang vulnerabilities, including RCE and credential disclosure; it is useful older context but must not be presented as the same flaw without confirmation.

Audience, tools and evidence boundary

This workflow is for incident responders, platform engineers, cloud administrators and security teams operating model-serving infrastructure. Collect read-only exports of inference requests, agent execution traces, workload identity events, token issuance and revocation, DNS and proxy records, cloud audit events, host telemetry, service inventories, deployment manifests and incident tickets. Use an organization-approved AI assistant with appropriate retention and training controls.

Preserve raw evidence outside the model. Replace user details, prompt content, API keys and token values with stable evidence IDs. Give the assistant bounded time windows and normalized rows, disable tool execution and outbound connectors, and require every factual statement to cite an evidence ID. If a credential value appears, stop and remove it rather than asking the model to mask it.

• System of record: immutable logs, images, manifests and analyst notes.
• AI role: align timestamps, group related events, expose contradictions and draft a review queue.
• Human role: determine scope, containment, notification, attribution and restoration.
• Stop condition: unexplained clock drift, conflicting identity, missing critical logs or secret material.

Step 1: separate four security layers

Create four inventories: confidential-computing boundary, software inside that boundary, surrounding control plane and legacy services. For each component record owner, version, network route, workload identity, credentials, data class, logging source and lifecycle status. NEAR AI explicitly noted that confidential computing protects against the operator and host but not against a vulnerability in software running inside the environment.

Do not collapse a trusted execution environment, inference engine and application into one trusted box. A protected hardware boundary does not prove the code inside it is safe, and a deprecated application is still in scope while it remains reachable or retains data.

Step 2: build a reachability and observation matrix

For each sensitive service, distinguish possible reachability from observed use. A role and route establish a possible path. A request ID, timestamp and response record establish observed activity. Missing response logs do not prove no data was returned. Add explicit fields for unknown, conflicting and unavailable evidence.

Create one row per path with source workload, identity, credential label, destination, policy, first and last observation, request evidence, response evidence and confidence label. Prioritize intersections where valid credentials, reachable sensitive data and observed requests overlap.

Step 3: prompt for a cited incident timeline

Process a bounded batch and require structured output. The assistant should return observed events, source IDs, conflicts, possible paths and the next human verification. It must not infer a missing event from sequence alone or label a vulnerability as a known CVE unless the evidence supplies that mapping.

Example prompt: “Using only evidence rows IR-100 through IR-180, build a timeline of observed requests, identity events, network paths and credential actions. Separate observed activity from possible reachability and unknowns. Cite evidence IDs for every fact. Flag clock conflicts and missing telemetry. Do not infer attacker identity, map the flaw to a CVE, expose prompt content or conclude that unlogged access did not occur.”

• Expected output: a cited timeline, reachability table and unresolved-evidence queue.
• Reject a claim that lacks an evidence ID.
• Recalculate time normalization outside the model.
• Have a second analyst review high-impact conclusions and every unknown.

Step 4: verify containment before restoration

Rotate sessions, administrative credentials, agent tokens and exposed cloud keys through the authoritative systems. Remove or isolate legacy services, deploy the verified software fix, capture the resulting versions and hashes, and confirm that access paths are closed. Search for reuse of the old credentials and for unexpected requests after the containment time.

A named incident owner should sign a restoration packet containing the affected assets, fixes, credential rotations, segmentation changes, clean telemetry window, remaining unknowns and rollback plan. The model may draft the packet but must not close the incident or restore service.

Realistic limitations

An assistant cannot recover logs that never existed, prove what an attacker saw, validate a patch from prose, or determine intent from access alone. Model summaries may merge similar identities, normalize timestamps incorrectly or turn possible reachability into asserted compromise. Confidential prompts and customer data can also become a second incident if copied into an unsuitable AI service.

This article did not test SGLang, NEAR AI or any incident-response product. NEAR AI’s scope and remediation are company-reported. The absence of a named version and CVE in the report means readers should not extrapolate exposure from product name alone; inventory the deployed version, restrict network access and follow authoritative project or vendor guidance.

Why this topic was selected

A focused Firecrawl search on November 11 for “SGLang RCE NEAR AI agents data breach November 2026 primary advisory” returned November 10 coverage from The Hacker News first, an independent attack-path analysis second and NEAR AI’s November 9 incident report third. Additional current coverage appeared in the same result set. That placement and breadth show active public attention; they do not establish Google rank, search volume or traffic. The useful gap was a reproducible evidence workflow that keeps the assistant from converting missing telemetry into certainty.