AI Infrastructure Security Playbook After the NEAR AI RCE

Quick Answer

AI infrastructure that relies on TEEs for privacy still needs hardening like any other production system: patch fast, reduce trust in logs, and design for containment.

In NEAR AI’s incident, SGLang ran inside the TEE, so an RCE in that software created a path to see requests processed that day, including confidential-mode requests. The fix is less about ‘more enclave’ and more about disciplined vulnerability management across the serving stack.

What We Know From The Incident Report (And What It Implies)

Last Sunday, an attacker exploited a remote code execution flaw in SGLang, the open-source inference engine, and ran code on one of NEAR AI’s inference servers. NEAR AI later said the attacker could also have seen requests processed on that server that day, including requests sent in confidential mode.

Confidential mode processes requests inside a trusted execution environment (TEE) designed to keep them private even from the company itself. NEAR AI’s key nuance was blunt: the TEE does not protect against a vulnerability in the software running inside the environment. Because SGLang ran inside the TEE, the attacker could reach data flows there. Access to that server was closed, but not before the attacker moved further into internal systems.

Why AI Infrastructure TEEs Don’t Eliminate RCE Risk

From a security engineering perspective, TEEs are best viewed as a privacy control, not a patch management strategy. They can limit exposure to a malicious host or operator, but they do not magically harden the binaries you ship into the enclave. If the inference engine inside the TEE has an RCE, then the attacker’s ‘trusted boundary’ becomes your blast radius.

The practical takeaway is uncomfortable: confidential compute can create a false sense of closure for leadership teams. It is a layer in a defense-in-depth story, not the story. Your model serving path is still software. It still has parsers, plugins, networking, and request-handling logic. Those components need the same vulnerability management cadence you apply to the rest of production.

• Treat inference engines as internet-facing software, even when wrapped in confidential-mode branding.
• Assume attackers will pivot: close the initial hole, then hunt for adjacent credentials and logs.
• Make ‘inside the TEE’ a scoped trust claim, not an excuse to relax change control.
• Test your containment plan against an RCE scenario, not just data-at-rest threats.

The Attack Path Shows Where Containment Actually Failed

NEAR AI reported that after closing access to the affected inference server, the attacker had already moved further into its systems. They reached an internal system behind Private Chat, a product the company had already deprecated. NEAR AI confirmed the attacker downloaded account details for about 100 users there: email addresses and names, and for some accounts, plan and balance information.

This is the ‘deprecated product’ trap in real life: something not actively marketed can still be reachable, still authenticated, still logging, and still connected to internal systems. Deprecation is a roadmap status; security needs a lifecycle endpoint. If a path exists from your serving tier to a legacy internal system, you have an architectural debt item—not a backlog nicety.

What Was Exposed: Data Classes That Matter To Engineering Leaders

NEAR AI said it found no sign that stored Private Chat conversations or uploaded files were accessed. That distinction matters because it points to where the attacker had leverage (account metadata and operational data), versus where they apparently did not (stored content). Still, metadata can be enough for targeted social engineering—especially when plan and balance information is involved.

On the agents side, the attacker reached 18 AI agents on an older deployment of NEAR AI Agents that did not run inside the company’s TEE. From those agents, they took data including chat history, settings, and logs. Two customers’ NEAR AI Cloud API keys were exposed in logs; NEAR AI revoked both. Analysis: if your logs can contain live keys, then your log pipeline is part of your secret management system—whether you intended that or not.

The Confidential-Mode Nuance CTOs Should Not Miss

NEAR AI explicitly stated that the TEE does not protect against vulnerabilities in the software running inside it. This is the correct mental model: a TEE can protect secrets from the infrastructure operator, but it cannot prevent an attacker from using a bug in the enclave-resident application to access data the application itself is processing.

That means your enclave threat model must include application-layer exploits, not just malicious hosts. If you’re selling ‘confidential’ as a feature, the bar rises: you now need the same secure SDLC discipline for enclave workloads as for any high-risk production service.

The Legacy-Agent Angle Is The Quiet Multiplier

The attacker reached 18 agents on an older deployment that did not run inside the TEE. This is a textbook multiplier: ‘old’ often means different guardrails, weaker observability, and stale secrets. And because agents often orchestrate downstream calls, they can become stepping stones.

Analysis: modern agentic systems frequently tie together user prompts, tool execution, and external integrations. When an attacker gets chat history, settings, and logs, they may get more than text—they may get operational context about what the agent can reach. That is why security reviews for agents should be part of the platform roadmap, not just the product roadmap.

• Inventory every inference and agent deployment, including ‘older’ and ‘temporary’ environments.
• Classify logs as sensitive by default; explicitly prove when they’re safe to share.
• Rotate credentials on incident, but also trace where they may have been replayed.
• Remove network paths from serving tiers to deprecated internal systems.
• Validate that non-TEE deployments aren’t silently handling production traffic.

Incident Response Moves That Are Worth Copying

After detecting the attack, NEAR AI revoked all active sessions and administrator credentials, replaced all agent tokens, and took Private Chat offline. It also deployed a fix for the SGLang flaw on all inference servers, rotated remaining credentials, and completed a full forensic review, according to its incident report.

They also reported the flaw to the SGLang project. However, NEAR AI did not identify the flaw by CVE number, name the affected SGLang versions, or say whether the project has released a fix. For engineering leaders, the missing version specificity is a reminder to build your own SBOM-style visibility into third-party components used in production serving.

• Revoke sessions and admin credentials early; assume cookie and token theft is in play.
• Replace agent tokens across the fleet, not just on the box you caught.
• Take deprecated surfaces offline rather than ‘monitoring them harder.’
• Patch the serving layer everywhere, then verify with deployment attestation.

Communication: Who Needs To Do Something, And When

NEAR AI contacted users whose account details or agents it confirmed were accessed, and affected users heard directly from security@near.ai with applicable steps. As a precaution, the company asked users to be careful with unsolicited messages about account or balance.

In a follow-up post yesterday, it said users who have not heard from it do not need to do anything. NEAR AI has not said whether people whose requests passed through the affected server last Sunday were among those contacted. For CTOs, the meta-lesson is to predefine ‘contact thresholds’ per data class so you can message decisively without over- or under-notifying.

How To Implement AIOps For Inference Security Without Creating Noise

Teams ask how to implement AIOps when they’re drowning in alerts and still missing real incidents. The answer isn’t ‘more dashboards.’ It’s building a small set of high-fidelity signals around your inference path: unexpected process spawns, unusual outbound connections from serving nodes, and spikes in error patterns that align with exploit attempts.

AIOps works best when it is constrained by good data engineering. Your logs, traces, and metrics must be structured, retention-scoped, and access-controlled so you can run reliable anomaly detection without turning observability into a data breach vector. If you need help hardening the platform itself—networking, isolation, and rollouts—this is where disciplined cloud software development becomes a security investment, not just an infrastructure line item.

1. Define ‘normal’ for model serving: baseline egress, CPU patterns, and request error rates per server group.

2. Detect pivots: alert on access to deprecated services, internal-only DNS zones, and sudden credential reads.

3. Reduce log toxicity: strip API keys, redact prompts where required, and limit who can query raw traces.

4. Automate response: isolate nodes, revoke tokens, and trigger forensic snapshots with approvals.

5. Review weekly: tune detections based on incident learnings, not vendor defaults.

DevOps Best Practices: What Actually Hardens Serving Tiers?

DevOps best practices matter here because the ‘serving tier’ is now a production gateway, not a research sandbox. If you can deploy a new model but can’t deploy a patch fast, your risk is dominated by the slowest part of your release process. In this incident, NEAR AI deployed a fix for the SGLang flaw across inference servers—speed like that is what prevents copycat exploitation.

Also, treat secret rotation as a routine operation, not a special event. Two customers’ NEAR AI Cloud API keys were exposed in logs and revoked. Analysis: the only sustainable stance is to make ‘keys in logs’ technically hard—central redaction, linting for dangerous fields, and runtime guards that prevent sensitive values from ever reaching standard logging paths.

• Ship patches like you ship features: staged rollout, canaries, and fast rollback.
• Segment inference nodes from legacy internal systems; deny by default, then add explicit allowlists.
• Enforce secret scanning and log redaction in CI/CD, not after a breach.
• Run production game days for RCE in model serving, including pivot and exfil scenarios.

AI Infrastructure Vulnerability Management For Model Serving And Agents

Vulnerability management in AI platforms is not only about the model. It is about the serving engine, the agent runtime, and the glue code. In this case, the entry point was an RCE in SGLang. NEAR AI reported the flaw to the project, but did not publish a CVE number or affected versions. That uncertainty is precisely why you need internal inventory: what you run, where it runs, and who can reach it.

This is where ML model engineering intersects with platform security. Engineers optimize throughput, batching, and latency; security teams need to ensure those optimizations don’t bypass controls (for example, disabling auth on internal debug endpoints). If your organization is building agentic products, the same discipline applies to tool permissions and prompt flows. For teams formalizing this work, start with an external baseline review such as cybersecurity and penetration testing focused on the end-to-end inference and agent pipeline.

The Brave Leo Detail: Third-Party Consumers Increase The Stakes

In an October 15 technical write-up, Brave said its Leo assistant runs chats with the GLM 5.3 Flash model inside a TEE operated by NEAR AI. NEAR AI has not said whether the affected server handled any of those chats.

Even without that confirmation, this is a reminder that when you operate serving for others, your security posture becomes part of their product promise. That changes expectations around disclosure speed, version transparency, and the rigor of your post-incident verification.

Make Agents Boring: Capability Scoping Over Convenience

The attacker reached agents on an older, non-TEE deployment and took chat history, settings, and logs. Analysis: agents are dangerous when they are over-permissioned and under-audited. ‘Convenient defaults’ in tool access become persistent liabilities.

If you are building agentic products, constrain capabilities the way you constrain IAM roles. Make each tool call attributable, limit what an agent can read from logs or configs, and separate environments so ‘older deployment’ cannot quietly remain connected to production data planes. If you’re building or modernizing this layer, AI agents development should include security architecture as a first-class deliverable, not a retrofit.

Closing: Build AI Infrastructure Like It Will Be Attacked

The NEAR AI incident is a clean case study in security reality: TEEs can help with confidentiality claims, but they don’t reduce the need to patch, segment, and monitor the serving stack. When an inference engine inside the enclave has an RCE, your ‘confidential mode’ can still become a visibility and pivot point.

If you want resilient AI infrastructure, budget for vulnerability management as a continuous program: version inventory, fleet patching, secret hygiene, and decommissioning that actually removes exposure. And if you’re unsure where your biggest gaps are, start by mapping every request path and producing an actionable project estimate for closing the highest-risk links.

Author: Plavno team. Last updated: November 2026.

Summarize this blog post with AI

Chat GPT Perplexity Claude Gemini