Palantir just published a 28-page doctrine with a thesis you can fit in one sentence: every time your company talks to someone else’s AI model, a little of what makes you valuable leaks out — and you should treat that like the security problem it is.
The paper is called Institutional Sovereignty in the Age of AI. It’s written like a treaty — fifteen numbered clauses, roman numerals, a call to arms at the end. It is also dense enough that most of the people it’s aimed at will never finish it. So here is the whole argument, translated.
The setup: why they think you should be paranoid
The core worry is simple. Model providers charge you per token, not as a share of the value they help you create. Palantir reads that as a tell: your incentives are not aligned. A frontier lab has every structural reason to absorb your “tribal knowledge” — the workflows, judgment calls, and institutional knowhow that make you different — into its model weights, and then lease that capability to everyone, including your competitors. In the extreme case, it stops selling to your industry and starts being your industry.
Whether or not you buy the full paranoia, the paper’s posture is zero-trust: assume any frontier model used without hard contractual protections is what it calls an extraction-prone model — one you should treat as if it’s learning from you, because it may be.
The fifteen steps are the countermeasures, organized in four layers.
Foundations — Steps I–III
I. Get zero data retention, in writing. A ZDR agreement means your prompts and outputs are processed in memory and never stored — not written to disk, not used for training, never seen by a human. Most enterprise contracts already say your data won’t be trained on, but contract wording is porous and policies change. ZDR is structural: data that was never stored can’t be trained on later, can’t leak, and can’t be swept up in litigation discovery. One sharp detail: some providers’ ZDR terms exclude your content but quietly keep the metadata — safety-classifier scores and monitoring logs derived from what you sent, retained for up to two years. Negotiate that closed too.
II. Decide workload by workload, not vendor by vendor. Not everything needs a frontier model, and some things shouldn’t touch a model at all. The paper’s decision tree starts with a question most AI strategies skip: does this workflow even need model inference? If deterministic software solves it, own the tool and create no extraction surface. From there, classify the data — public, internal, high-alpha, classified — and match each class to the strongest protection it needs.
III. Audit your own architecture first. Before buying anything, know where you stand at each of three layers: the models (can you move between providers, or are you locked in?), the compute (do you know who can physically touch the machines running your work?), and the control layer (are you capturing your own knowhow, or letting it evaporate into a chat window?).
The model layer — Steps IV–VI
IV. Assume misaligned incentives. Covered above; the point of stating it as a step is posture. Trust the structure of the deal, not the vibes of the lab.
V. Stay liquid. Model liquidity is the ability to swap any model for any other with no friction. The last four years supplied the argument: outages, retention-policy changes, shifting refusal behavior, geopolitical restrictions. If switching is cheap, none of those are existential — and a credible threat to walk is also your negotiating leverage on everything else, including ZDR. Liquidity also just gets you better output: run continuous evals, route each task to whatever is best and cheapest this month.
VI. Own the flywheel. Usage generates signal, signal becomes structured knowhow, knowhow improves the system, the better system generates more usage. That loop is where compounding advantage lives — and the only question that matters is who captures it. If it compounds inside a provider’s weights, you gave it away. There’s a legal catch, too: most frontier labs’ terms of service prohibit training your own models on their outputs. Rely wholly on closed models and you may not have the right to compound. The paper’s remedy is open-weight models — you can fine-tune them, learn from them, and run them on infrastructure you own. It ends this section with an actual call to arms for capable American open-weight models, calling NVIDIA’s Nemotron releases a watershed but still the exception.
The compute layer — Steps VII–IX
VII. Think in assurance, not brands. The guarantee that your data is safe rests on one of two things: a contract (someone promises) or structure (the physics of the setup makes it so). Structural beats contractual. The paper’s ladder, strongest to weakest:
- Owned, air-gapped hardware. The assurance is the physical boundary itself. For classified work and core company secrets.
- Attested rented compute. Someone else’s GPUs, but the silicon cryptographically proves your workload ran sealed in an enclave the host couldn’t inspect. For sensitive workflows.
- Frontier model under ZDR. Full capability, but the assurance is a contract. For day-to-day sensitive tasks.
- Standard API access. No ZDR. Treat everything you send as observed. Public information only.
Match each workload to the rung it needs. Most work doesn’t need rung one. Some work should never leave it.
VIII. If you own hardware, own adaptable hardware. GPUs are scarce, expensive, and slow to acquire — but general-purpose. Chips optimized for today’s architecture are a bet that the architecture won’t change, and it already has once (dense transformers to reasoning models). Owned, flexible compute is also insurance: chip supply and cloud model access are both hostage to geopolitics.
IX. Verify compute you don’t own. When you must run on rented infrastructure, don’t settle for promises. Confidential computing gives you hardware attestation — the chip signs a proof that your workload executed inside an isolated enclave, out of the host’s view. A structural guarantee on someone else’s machines.
The control layer — Steps X–XV
This is the layer the paper cares most about: the system that sits above the models, that you own, where the models plug in as interchangeable parts.
X. Be model-agnostic by construction. No single model is the default; the control layer routes each task by your preferences and constraints. A side benefit: if you reach models through a shared model-agnostic layer, your traffic blends with everyone else’s at the API endpoint — anonymity by aggregation.
XI. Give agents permissions the way you give people permissions. Real organizations aren’t structured as database tables; they’re people, roles, and workflows. Model your organization as a digital twin — an ontology — and derive access from that structure: role-based, purpose-based, following the data’s lineage. This matters enormously for agents. An agent with undefined permissions can end up seeing more than any employee ever could. And there’s a quiet legal point: trade-secret cases often turn on whether you actually protected the thing you claim is secret. Defined agent permissions are that protection, on the record.
XII. Log everything, and set canary traps. An append-only audit trail — who asked what, which model, what data it touched, what came back — lets you reconstruct any decision. It also enables the paper’s most cloak-and-dagger suggestion: test new models from your providers against material containing answers only you could have supplied. If the model knows, you’ve detected misappropriation — and an audit trail is what gives that suspicion legal weight.
XIII. Make cybersecurity adaptive, and let it make you faster. AI-scale attacks are coming for institutional IP, but the paper’s sharpest point runs the other way: security done right is what lets you ship faster, because you’re not stopping for lengthy manual scans before every release. Its test for any organization: is your rate of shipping software the same as six months ago? If yes, something is deeply wrong.
XIV. Build by branching. Let agents work on forked copies of real systems — code, data, even the organization’s whole digital twin — validate the result, then promote or discard. Reversibility collapses the worst tradeoff in agentic deployment: without it you either fence agents off from anything real or accept unbounded risk. With it, mistakes are cheap and agents can be given real surface area.
XV. Own the context flywheel. The model flywheel (step VI) compounds through weights. This one compounds through context: the structured record of your institution’s decisions and actions, captured in an ontology that exists outside any model. If your only assets are prompts plus somebody’s hidden weights, your knowhow is trapped inside a single vendor relationship. If the knowledge layer is yours, every model — present or future — becomes a replaceable engine you attach to it.
Now, the honest reading
You may have noticed the shape of this document. Palantir sells an ontology-based control layer. The paper prescribes an ontology-based control layer. AIP, Evolve, Evals, and Apollo — Palantir products all — appear throughout as the worked examples, and step III helpfully includes an email address for a free sovereignty review.
So yes: this is a doctrine that doubles as a brochure, written by the vendor best positioned to profit from its own advice, and its zero-trust framing of frontier labs conveniently makes Palantir the neutral party in a room full of suspects.
And yet. Strip the sales motion out and the questions survive on their own: Do you actually know what your model provider retains? Could you switch providers next quarter without pain? Is your institution’s accumulated judgment being captured anywhere you own — or is it evaporating, one prompt at a time, into weights that someone else rents back to you?
Those questions are worth answering no matter whose software you buy. The institutions that answer them deliberately will own their flywheels. The ones that don’t are doing free R&D for the most expensive vendors in history.
The fifteen clauses, the assurance ladder, and the vendor selling the cure.