Andromeda credential incident: keep AI infrastructure scope precise

Sources checked: 30 October 2026. FailSafe Research.

AI infrastructure incidents are often summarized as “models stolen” before the evidence supports that claim. Andromeda’s October statement supports a narrower and still serious concern: unauthorized access to credentials.

The vendor’s position

In its 20 October security update, Andromeda says it identified an incident on 13 October, disabled compromised accounts and rotated affected keys. It believes activity began around 9 October and affected a limited number of customer accounts. It says its investigation had not detected unauthorized access to customer models, datasets or training data within its security perimeter. Root cause remained unestablished.

“No evidence detected” describes the investigation’s findings at that stage. It is not a universal guarantee about every connected system. Likewise, the vendor’s reference to broader industry activity does not independently identify a common attacker.

Review what each infrastructure credential authorizes

An AI workload can connect compute provisioning, object storage, registries, model endpoints and billing. Map each service identity to its actual resources and actions. Distinguish permission to run inference from permission to read model weights, alter deployment artifacts or export training data.

The inventory should include operators, automation and support access. For each, document how access is approved, how long it lasts and which audit trail records its use. A regional hosting decision does not itself answer those questions.

Questions to test before the next incident

• Can a workload identity enumerate or read another project’s artifacts?
• Can a compromised application change the inference endpoint or outbound destination?
• Can an expired support session still reach the control plane?
• Does revoking the original credential also invalidate its derived access?

Test with approved identities and synthetic artifacts. The finding should identify the resource, authorization decision, observed effect and remediation owner. Avoid copying production model data or customer secrets into an assessment report.

Choose the processing boundary deliberately

FailSafe’s sovereign hosting and inference options let enterprise teams define where assessment processing runs and who operates it. In a fully local configuration, sensitive assessment processing can remain inside the agreed customer environment. Operational access, egress and integrations still require review.

FailSafe AI security testing connects model behavior to the identities and tools that can create business impact. That makes the scope measurable without claiming that every AI-related breach is a model compromise.

Explore the October incident collection for related cases and existing FailSafe coverage. Incident descriptions are attributed to the linked sources; assessment recommendations are FailSafe’s analysis. We have not conducted forensic investigations of these incidents.