Analysis · DiggingBeagle record
Three AI-service incidents, three different paths into protected customer data
Railway, NEAR AI and Fireworks disclosed different intrusions into services surrounding AI workloads. Their differences show why build isolation, inference enclaves and credential rotation cannot substitute for authorization at the next service boundary.
- Published
- Nov 11, 2026
Overview
Railway’s intruder began in a build. NEAR AI’s intruder began inside an inference server. Fireworks’ incident involved evaluation credentials and later research infrastructure. All three affected companies that serve AI workloads, but a shared label such as “AI platform breach” obscures the very controls that mattered.
The recent public records offer a useful test of security claims: after the first component was compromised, which other identity accepted its requests, what data could it reach, and what evidence confirms the downstream effect? These are separate incidents, not an attributed common campaign.
Railway: the build credential traveled farther than the build
Railway says the attacker exploited a filesystem-isolation weakness on October 20, obtaining a builder credential that should have been confined to build-related operations. An internal Temporal service also trusted that credential, enabling retrieval of 353 build histories and Railway source. Source-level knowledge then supported attempts against a CI-to-cloud OIDC trust configuration, ultimately reaching an orchestration credential that could ask the cloud key-management service to decrypt some customer variables.
Railway’s query evidence identifies AI provider credentials as a specific target, and the company estimates about $740,000 in unauthorized AI usage. Its description of modified models and an ARTEX-like harness is an attribution assessment. It does not prove ARTEX was the deployed tool, nor that an autonomous agent made every move. The defensible architecture finding is more concrete: a secret obtained from a low-trust builder was honored by internal services with broader privileges. The Railway report documents the chain.
An ephemeral VM per build narrows how a customer workload can reach host files. Image-specific credentials narrow what a stolen builder identity can do. Exact workload-bound OIDC claims restrict which cloud role a service may assume. These are three different fixes to different transitions. None alone revokes a third-party AI key already copied and subsequently used outside Railway.
NEAR AI: confidential computation still runs software
NEAR AI disclosed remote code execution in SGLang on one serving instance. That placed untrusted execution inside the inference process, after the hardware isolation boundary had admitted the workload. The attacker then reached separate internal systems, downloading older account records and accessing 18 agents from a legacy service outside the confidential-computing configuration.
NEAR explicitly distinguishes possible exposure of requests running on the affected server on November 8 from the account and legacy-agent data it confirmed retrieved. Hardware-backed isolation can protect a serving process against host observation without protecting that process from its own vulnerable code or from overly broad credentials. The NEAR report identifies that distinction without publishing the specific SGLang flaw.
A meaningful boundary test therefore needs two threat models. First, can an infrastructure operator or neighbor inspect enclave data? Second, if an attacker executes code inside the enclave, can that workload reach customer databases, legacy chat services or unneeded API-key logs? The second question is not answered by the first system passing hardware attestation.
Fireworks: an incident report has a revision history
Fireworks first reported unauthorized access to evaluation-job secrets in October. The November 9 revision added account and billing information, limited datasets and incomplete model weights, and described additional access through its R&D cloud provider on October 24. Notion subsequently confirmed that Fireworks-held data included AI Insights transcripts for fewer than 1% of its workspaces. Its notice says most such transcripts lacked direct author or workspace labels and that it stopped the affected integrations.
The chronology prevents a common editorial error. The initial Fireworks statement that it had not detected model or dataset impact was a preliminary observation. The revised bulletin supersedes it for those categories. At the same time, the expanded account does not justify claiming every inference request or stored training record was taken. Fireworks reports no detected impact to named zero-data-retention services, with its investigation ongoing. Notion says its own infrastructure was not breached.
The practical response differs for each category: revoke third-party credentials at their issuing providers, notify customers whose stored materials were confirmed affected, check transcript text for pasted secrets and isolate research environments from production credentials. An account label being absent from an AI transcript does not automatically make its contents harmless.
A test that works across all three
In each case, ask for an execution chain with five fields: the initial principal, the permission used at each next service, the exact operation, the data or external effect reached, and the independent evidence confirming that effect. A host that blocks prompt injection but grants its model worker extensive database credentials has not solved this class of risk. A build process isolated from other tenant builds but trusted by CI administration has not either.
Scope and recovery are part of the same audit. A potential exposure ceiling must remain a ceiling; denied calls must remain failed calls; credentials copied before rotation require revocation at their original issuers. An incident can be materially serious without a headline that converts uncertainty into extra victims.
This comparison cannot establish a common actor, an industry-wide attack rate or the first safe software versions for every component. It instead provides three independently documented paths where an AI-adjacent service accepted authority from a component with a different trust level. Those paths are where operators can demand proof of containment, and where investigators can test an explanation against actual effects.