NEAR AI: scoping data and software in inference
An AI integration review needs to follow the software processing each request and the credentials around it. Organize evidence by service before deciding which data and operations can return to the workflow.
Leer en portuguésBy Pentesty
The scope reported by the provider
In its November 9 disclosure, NEAR AI reports exploitation of a vulnerability in SGLang on one inference server and possible access to November 8 requests, including confidential ones. The company distinguishes Private Chat data from legacy agents and says it deployed a fix and revoked credentials. This is the provider’s account.
For an enterprise customer, the starting point is its own usage routes. Identify applications, projects, service accounts and request times. Connect each integration to an owner who can explain its configuration and suspend its use. This map supports specific questions to the provider and helps prevent a single conclusion from being applied to every product sharing the same brand.
Record what receives each request
Build an authorized sample using fictional inputs selected to represent the data classes the application uses. Record the destination, contracted service mode, request identifier and configuration version. Keep approved retention and access policies alongside the operational observation. Where a field cannot be observed, record the dependency on a provider statement and the person responsible for resolving it.
An integration may use different destinations depending on its model, region or requested feature. Check the configuration actually applied to each relevant business path. Pentesty’s analysis of AI provider routing can help structure this inventory. Keep the proposed test within authorized environments and accounts, using information that can safely be discarded afterward.
Connect the component to its deployment
Request enough evidence to connect an update to the service handling your application: component identification, correction reference, deployment and activation time. If the provider withholds technical details, record that limitation and establish a contractual response criterion. Avoid filling gaps with a version found in another project or a bulletin that merely mentions the same product.
Within infrastructure your team administers, connect the dependency inventory to the deployed artifact and running instance. Preserve the change record and the acceptance owner. A package list becomes more useful when it can be reconciled with the observed service. The operational objective is for another person to repeat the check without relying on the memory of whoever performed the update.
Make separate decisions for data and identities
Organize investigation by dataset, period and identity capable of accessing it. Request content, stored history, operational logs and account information require different questions. Record what has been confirmed, what remains possible and what has not been determined. Preserve the origin of each statement so a later provider update can change the corresponding conclusion precisely.
For credentials your team administers, prepare a controlled replacement with an owner, dependency list and execution window. Confirm rejection of the old credential and operation of the replacement through a small authorized transaction. Keep identifiers and results while protecting secret values. Where other integrations depend on the change, check continuity for each one before closing the work.
Define acceptance through observable results
Select a representative workflow and agree beforehand which evidence will permit its return. Record a request containing fictional data, its expected response, the approved configuration and the decision owner. Add a stop condition for an unexpected destination or an unresolved dependency. Approval should have an explicit scope identifying the projects and functions it covers.
Keep outstanding investigation questions separate from completed operational tasks. The review of data held by providers offers complementary scoping questions. At a later review, check whether changes to a model, feature or credential changed the previously accepted route. Document the new result so the decision remains connected to observed behavior rather than an assumption.
Frequently asked questions
Does this analysis establish exposure at my company?
Local scope depends on projects, periods and data used. Connect your records to the disclosure and keep unanswered questions explicit until the necessary evidence is available.
What changes when reviewing confidential computing?
NEAR AI says the protection does not cover vulnerabilities in software running inside the environment. Include that dependency in the review.
Which version should be installed?
Require a reference applicable to the component and deployment in use. This article does not assign a fixed version number that the disclosure does not provide.
What belongs in the acceptance record?
Integration identification, approved configuration, authorized test results, known limitations and an owner. Protect the record so it does not expose secrets or real customer information.
Sources and references
Original Pentesty analysis, published November 10, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.