NEAR AI Breached Through an Inference Engine Flaw (Account Details of About 100 Users): What Was Confirmed and What Users and AI Infrastructure Operators Should Do

According to the company's report, users whose account details it confirmed were accessed, and the owners of the 18 agents, were contacted directly from security@near.ai with the steps that apply to them. Check your spam folder too. If you received a message, follow its guidance first.

If you are unsure whether a message is genuine, do not open its links; open the company's official site yourself. The company's contact is security@near.ai.

The company advises treating unsolicited messages that reference your account or balance with caution. What was taken is an email address and name, plus plan and balance information for some accounts. Together these allow convincing fake messages to be written (a general point). Do not open links; check your account through a bookmark. More in What phishing is.

What the company confirmed is that chat history, settings and logs of 18 legacy agents were retrieved, and, separately, that API keys of two Cloud customers were exposed in logs (not stated to have been taken). It also says user requests on the compromised server on November 8 could have been observed.

If you ever put an API key, password or connection string into an agent's settings or a chat, rotate it with the issuer as a precaution. You do not need to wait to learn whether it was seen. For key handling, see Environment variables and API keys basics.

The company says the keys exposed in logs belonged to two Cloud customers and have been revoked. The report gives no guidance for other customers' keys. Review where you use your keys, delete the ones you no longer use, and check that you have not written them into logs or history (our view).

What to check in your own inference and agent infrastructure in light of this incident is summarised below under "What operators of AI infrastructure should review".

In this account, code execution on one inference server led to other infrastructure. Giving an inference server no credentials or connections to internal management systems and other servers, and limiting its traffic to the destinations it needs, can shrink how far one compromised machine spreads (our view).

The account details that were taken sat in an internal system behind the previously deprecated Private Chat. For a service you stop using, do more than switch it off: delete the data, revoke the credentials and remove it from the network. Whatever you keep is what is exposed when a breach happens (our view).

The 18 agents were on a legacy deployment that was not running in the confidential computing environment. Strengthening a new environment leaves the legacy one as the weak side. Migrate it or set a deadline to retire it, and apply the same permission limits in the meantime (our view).

The company says API keys of two Cloud customers were exposed in logs. Do not write request headers or settings to logs as they are, mask keys and tokens, and limit access to where logs are stored. Prepare in advance the steps to revoke a key quickly if one does end up in a log (our view). Another case where key handling was the focus is The Northflank security incident.

The company deployed the fix across all inference servers and reported the flaw to the SGLang project. If you use an open-source inference engine, keeping a deployment path that can push a published fix to every server fast, and an inventory of the versions you run, shortens the time from noticing to fixing (our view). Another intrusion into AI infrastructure is covered in The intrusion into Hugging Face.