Palantir was blacklisted for working exactly as designed

Palantir builds systems whose purpose is to remove the boundaries between data. Its two principal platforms, Foundry and Gotham, ingest records from separate and previously disconnected sources inside an organization and assemble them into a single operational model. Foundry describes this model as an ontology, a unified representation in which a person, a transaction, and a location that once lived in isolated tables become one connected, queryable object. This is not a hidden capability. It is the documented function of the product, and it is the reason the product has value. Once an organization grants Palantir access to its underlying data sources, the platform maintains standing integrations against those sources and resolves analysis across the whole.

The Spanish government has ordered that Palantir be blacklisted from public and private companies. The instinct is to read this as a judgment about what the software can do. That reading is wrong, because what the software can do was never in dispute. The integration works. The ontology resolves. The access, once granted, functions exactly as designed. Nothing in the technology failed, and nothing needed to fail for this outcome to arrive.

What is being acted upon is not the machine but the arrangement of trust the machine depends on. A platform that unifies data across an organization occupies a position of extraordinary concentration. It sees across silos that were deliberately kept apart, and it resolves them into a single legible surface. It does exactly what it was built to do, and in doing so it becomes the one place at which a very large volume of sensitive information is combined and made queryable. The order against it is a response to that position, not to a defect. The system is not failing. It is doing precisely what it was built to do.

The assumption underneath a platform like Foundry is that access, once granted, remains valid. When an organization authorizes Palantir to integrate a data source, that authorization is treated as a persistent fact. The integration is built once. The credentials are issued once. The lawful basis for the processing, whatever it was at the moment of authorization, is recorded once and referenced thereafter. The system does not continuously re-derive whether it should still hold the access it holds. It holds it, and it acts on it, because at some prior point the access was validated.

Trust in this model is also transferable. The grant made to Palantir as an identity extends across everything that identity subsequently does with the data. A permission established for one purpose becomes the standing basis for the platform’s operation across the entire ontology. Under Regulation (EU) 2016/679, this is precisely the distinction the law draws. A lawful basis is bound to a specific purpose, and a data processing agreement under Article 28 binds a processor to defined instructions. But the platform does not experience that legal structure as a live constraint evaluated on each query. It experiences it as a reference to a validation that already occurred. Purpose limitation is a property of the paperwork. Execution is a property of the granted access.

This is the model on which the value proposition rests. Speed comes from not re-asking the question. An analyst querying the ontology does not trigger a fresh evaluation of whether the underlying data may lawfully and appropriately be combined and examined for this reason at this moment. The combination already exists. The access already resolves. The system optimized for rapid access to unified data on the strength of a previously validated identity, and it treated the validity of that identity as durable. The assumption was that trust, once conferred, persists and carries forward. For as long as the legal and political context around the data holds still, the assumption stays invisible, because nothing tests it.

The context did not hold still. What changed was not Palantir’s software, which does now what it did before, and not the skill of any adversary. What changed was the validity of the assumption the platform inherited. The legal and societal constraints surrounding the concentration of citizen and organizational data moved. Questions about data sovereignty, about foreign control of critical analytic infrastructure, about the appropriateness of resolving public and private data through a single external vendor, hardened into a governmental position. The ground on which the original grant of trust was made shifted. The grant did not.

This is the structural fault, and it is not unique to Palantir. The platform continued to reference a validation performed in the past as though it were a validation performed in the present. Access authorized under one set of legal, political, and societal conditions kept resolving under a different set, because the system carried no mechanism to re-evaluate the trust it was operating on. It did not re-ask whether it should hold what it held. It inherited the answer from a prior state and executed against it. In practice, the platform was doing exactly what it was designed to do, and that is the problem, because what it was designed to do was to treat a past authorization as a present fact.

That assumption no longer holds. Foundry and Gotham did not become less capable, and Palantir did not become a different company. The reference the system relied on, a previously validated identity holding standing access to concentrated data, stayed fixed while everything that gave the reference its meaning moved underneath it. This is the point at which the specific story about one vendor and one government stops being interesting on its own terms. What is interesting is the shape of the failure, a system that resolves trust once, records the result, and then keeps acting on the record long after the conditions that produced it have changed. Any system built to delegate trust by persistent reference carries this same exposure, whether the reference is a signed data processing agreement under Article 28, an OAuth token, or a dependency pinned to a version that was safe on the day it was pinned.

Nothing about the sequence looks like an intrusion. A query enters the platform, the standing integrations resolve it against the connected sources, and a unified result returns. From the outside, every step is the expected behaviour of a system doing its job. There is no forced entry to observe, no anomalous credential, no exfiltration path that a monitoring surface would flag as deviation, because the operation is not a deviation. Foundry executed the query it was built to execute, against data it was authorized to reach, using access that resolved exactly as configured. The event regulators are responding to and the event the platform records as normal operation are the same event.

What the platform checks, when it acts, is the reference. The grant made to Palantir as an authorized processor is present, so the operation proceeds. The identity holding the access has become the thing that is validated, and the lawfulness of the specific combination being performed at that specific moment has become something the identity is assumed to carry. This is reference standing in for validation. The system confirms that the access exists; it does not re-derive whether the access should still exist for this purpose under the conditions now in force. Article 28 of Regulation (EU) 2016/679 binds the processor to defined instructions, but the instruction set is consulted as a recorded fact from the past, not re-evaluated as a live question in the present.

This is the substitution that matters: identity of source replacing integrity of content. The platform treats the origin of the authorization as a guarantee of the appropriateness of everything performed under it. Because the grant came from a valid source at a valid time, the operations flowing from that grant inherit its validity indefinitely, across every query the ontology resolves. The integrity of any single act of combining and examining data is never independently established. It is imputed from the identity that once held the key. And because the behaviour is expected rather than exceptional, no visibility surface built to catch anomalies will register it. If you cannot see it, you do not control it, and here there is nothing anomalous to see. The failure is legible only from outside the system, at the level of governance, because inside the system nothing failed.

The pattern underneath this is execution based on reference rather than verification. A system establishes trust once, reduces that trust to a durable token or record, and thereafter acts on the record instead of re-performing the evaluation that produced it. The reference is cheap to check and the evaluation is expensive to repeat, so the system optimizes for the reference. Speed and scale come from not re-asking the question. The exposure comes from the same place. Between the moment trust is established and the moment it is acted upon, the world that justified the trust can move, and the reference carries no knowledge that it has moved.

The same mechanism runs in certificate validation. Under X.509 and RFC 5280, a client establishes that a certificate chains to a trusted authority and falls within its validity window, and on that basis it proceeds. But a certificate can be revoked before it expires, and revocation is a present-tense fact that the original validation cannot contain. The mechanisms that exist to carry that fact forward, Certificate Revocation Lists and OCSP, are precisely the re-verification step, and they are routinely cached, stapled, soft-failed, or skipped for the same reason Palantir’s access is not re-derived on every query: checking again is expensive, and the reference is already in hand. A certificate that was valid at the handshake keeps being treated as valid long after the authority that issued it has withdrawn its trust. The private key is compromised; the certificate still resolves. The mechanism is identical. The domain is the only thing that changed.

In both cases the system is not tricked and nothing is broken. The certificate presents a real chain to a real authority, exactly as Palantir presents a real grant from a real controller. The reference is authentic. What the reference cannot express is that its authenticity is a claim about a past state, and that the present has diverged from it. Any system that governs access by persistent reference carries this, and the more that single reference governs, the more consequential the gap becomes. Concentration does not change the mechanism. It changes the blast radius. The reference stays fixed while everything that gave it meaning keeps moving underneath.

The order out of Spain is not a verdict on what Palantir can do. It is a correction applied from outside to a system that had no way to correct itself. Foundry and Gotham never held the capacity to re-ask whether they should still hold the access they hold, because that capacity was never the point. The point was to resolve, quickly and at scale, against trust already granted. Governance became the only place the question could be asked, because the platform had optimized the question away.

This is what it means to delegate trust by reference. The reference persists. Its meaning does not. And the distance between the two is invisible from inside, because from inside every operation is correct. The system is not failing. It is executing a validation performed under conditions that have since dissolved, and it will keep executing it until something external revokes the reference itself.

A platform like Foundry resolves trust once. It does not revalidate; it references. The authorization exists. The lawful basis it once stood on does not.