Spain rips Palantir out of its data pipelines

Spain issued a directive to remove Palantir from public and private sector data operations. Public bodies and critical infrastructure operators instructed to strip the vendor from their processing chains. No CVE attached. No CVSS vector. No affected version range. No patch boundary. That absence is the signal.

This is not a memory-safety bug. There is no heap corruption, no type confusion, no primitive to chain. The vulnerability is architectural. The bug class is concentration of a privileged data plane inside a single commercial provider. Palantir Foundry and Gotham are not applications that sit beside operational data. They ingest it, model it, and become the analytical layer over it. The vendor’s software holds read access to the full operational corpus - case files, sensor feeds, financial records, biometric and movement data, intelligence product. The trust boundary is not at the network perimeter. It is at the data model. And the data model runs on infrastructure the customer does not fully control.

Map it to ATT&CK. This is T1199, trusted relationship, expressed as a standing condition rather than a discrete intrusion event. In the normal reading of T1199 an attacker compromises a third party and pivots through the trust link into the target. SolarWinds was the canonical case - T1195.002, compromise of a software supply chain, where a signed update from a trusted build system carried a backdoor into roughly 18,000 downstream environments. The Okta support-system breach in October 2023 was the same shape at the identity layer. An actor reached Okta’s support tooling, pulled session material, and used the trust relationship to reach Cloudflare and 1Password downstream. In each case the enabling condition was identical. The privileged provider sat inside the perimeter by design, and the customer’s controls were not positioned to see abuse of that position.

The concentration case is worse than the pivot case. When a single provider becomes the analytical plane over a nation’s operational data, the trusted relationship is not a link between two systems. It is the system. The provider holds the identity resolution, the entity graph, the cross-source correlation. Everything the customer knows about its own operations is mediated by software the customer did not write and cannot fully audit. That maps to T1213, data from information repositories, and T1530, data from cloud storage - but the technique framing understates it. The repository is not one source among many. It is the fused product of every source.

Consider the exploit path in the abstract, without enabling anything. An adversary does not need a renderer bug or a kernel primitive to reach this data. The data is already centralized, already correlated, already indexed for query. The privileged access exists as a feature. Three conditions turn that feature into exposure. First, compromise of the provider itself - vendor credentials, an insider, a build-pipeline substitution in the provider’s own delivery chain. T1078, valid accounts, at the provider tier. Second, legal or political compulsion applied to the provider under a foreign jurisdiction, forcing disclosure the customer never authorized. Third, the provider’s commercial incentives diverging from the customer’s operational security. None of these require breaking the software. They require the software to work exactly as built, in the hands of a party whose interests no longer align with the data owner. Spain’s action reads as a response to the second and third conditions, not the first.

The centralization is the multiplier. In a distributed model, a compromised database exposes one dataset. The blast radius is bounded by what that system holds. In the fused model, a single compromised analytical plane exposes the correlations - who contacts whom, which entities resolve to the same person, what the intelligence picture actually is. The value of a graph is superlinear in its edges. So is the damage when the graph leaks. This is why intelligence services treat concentration as a first-order risk and not a procurement footnote. The provider does not need to be malicious for the concentration to be dangerous. It only needs to be reachable.

Now the part that matters to detection engineers. What does this look like in telemetry? For the customer, almost nothing. That is the finding. When operational data lives inside a vendor-operated plane, the customer’s EDR sees egress to the provider’s endpoints. The SIEM sees API calls, authentication events, scheduled ingestion jobs. Network sensors see TLS to the provider’s ASN. What none of them see is what happens to the data after ingestion. Processing occurs inside the provider’s environment, under the provider’s telemetry, governed by the provider’s audit configuration. The customer consumes the audit log the provider chooses to emit. If the provider is compromised, or compelled, or simply acting on its own read, the record of that access is authored by the entity the customer would need to detect. A log you cannot generate and cannot verify is not a control. It is a courtesy.

This is the detection gap that trusted-relationship compromise exploits every time. Third-party access does not fire the rules built for external intrusion. There is no anomalous process tree, no LSASS handle, no beaconing pattern on the customer’s wire, no Sysmon Event ID 1 for a spawn that never happened on customer infrastructure. The activity is indistinguishable from sanctioned use because it is sanctioned use, executed by a party inside the trust boundary. Correlation rules keyed on failed authentication, lateral movement, or unusual internal enumeration have nothing to bind to. The privileged provider generates no anomaly because privilege is its baseline.

Where a customer retains any visibility, it is at the ingestion and export edges. Volume and cadence of data flowing to the provider. Newly created service accounts and API tokens on the customer side of the integration. Export and bulk-download operations from the analytical plane back out. Changes to the provider integration’s scope or permission grants. These are the observable events. They are also the events most likely to look normal, because bulk movement into and out of an analytics platform is the platform’s function. Detection here is a signal-to-noise problem, not a coverage problem. The engineering work is baselining the legitimate flow tightly enough that a divergence is visible before the data is already gone.

Real-world grounding. Meta’s history with data concentration - the Cambridge Analytica case - showed that the leak vector is not always a breach in the technical sense. It was authorized access, scoped too broadly, used for a purpose the data owner did not sanction. That is the trusted-relationship failure mode without a single exploited vulnerability. The Okta and Cloudflare disclosures showed the pivot version, where trust in a provider became the initial access others inherited. Spain’s directive is the state-level version of the same recognition. The lesson holds across all three. The trust designation itself is the risk, because it removes the scrutiny that would otherwise be applied.

There is no patch here. That has to be stated plainly, because practitioners are trained to look for a fixed version and a boundary. Removal of the vendor is not revocation of what the vendor already holds. Data already ingested is already correlated. Models already trained on that corpus retain what they learned. Exported artifacts, cached derivations, and any material transferred under prior agreements sit outside the customer’s reach. Provenance does not reverse on contract termination. A blacklist changes the forward posture. It does nothing to the backward exposure. Residual risk after removal is defined by everything the provider processed before the directive, and by whatever downstream copies exist in jurisdictions the directive cannot bind.

For operators holding critical infrastructure data, the SOCI regime and the Privacy Act frame this as a data-residency and control question, not a vendor-preference question. Where operational data is subject to a foreign provider’s jurisdiction, control over that data is shared with a legal system the data owner does not answer to. That is a concentration exposure a security team can measure - which datasets, which provider, which jurisdiction, which contractual audit rights, which export controls actually enforceable. Teams carrying this exposure should route it to their own security and legal functions for formal assessment rather than treat it as settled by the vendor’s compliance attestations.

The technical reality is unchanged by any single procurement decision. Centralizing a full operational picture inside one privileged provider creates a single point whose compromise, compulsion, or drift exposes the correlations, not just the records. The provider does not have to be attacked for the exposure to be real. The exposure is the architecture. Spain treated the architecture as the vulnerability. That is the correct read.

See also: NordVPN for tunneled traffic when operating outside controlled networks.

---

#ad Contains an affiliate link.