← Blog

Karp, The Token Tax, and the Application Layer

3 July 2026 · JD Fortress AI

Palantir’s CEO went live on CNBC and told us what enterprise customers are really thinking. The application layer is the missing piece that turns models into tools, and it is not a luxury for the big.

On Wednesday 1 July 2026, Palantir CEO Alex Karp appeared on CNBC’s Squawk Box and delivered what can only be described as a near-monologue on enterprise AI. He was promoting a partnership with Nvidia around sovereign AI capabilities. The interview, which ran to twenty minutes, revealed something more useful than marketing copy.

Karp said what many enterprise customers are thinking but are not saying publicly. The result was a transcript worth studying for anyone building AI systems for UK businesses in regulated sectors.

The quotes

Karp was characteristically direct. When discussing the token model used by frontier labs:

I am paying for tokens that create no value. These people are stealing the weights and alpha of my business, and they are creating a wealth tax that does not help the poor, it just punishes.

His description of enterprise sentiment was even more specific:

The basic view among enterprises in this country is I’m going to chillax and waste my time with tokens, I’m going to get no value, and they’re going to get my IP.

When pressed on why the labs charge for tokens rather than taking a cut of the value they claim to create, he answered:

If it was so valuable and let’s say I can make you a billion dollars, then tomorrow, wouldn’t I say, ‘I’ll make you a billion dollars, and I want 30%’. Why are they charging for tokens if it’s so valuable?

Karp insisted he was not throwing shade at OpenAI or Anthropic. He also said the real issue was structural:

We need to re-build trust, and that trust is going to happen where everyone gets to ask and answer basic questions — who owns the data, where is it cached, are the prompts secure?

What the application layer actually is

The most substantive part of Karp’s interview came when he described the technical stack. He identified three elements: the model, an application layer, and compute. The application layer, he argued, is what turns a language model into a tool you can actually deploy in an enterprise.

In Palantir’s product line, that layer is called the Ontology. It is a governed knowledge graph — not just a database, but a typed, structured representation of business objects, their relationships, properties, and actions.

The Ontology is live. It updates in real time as operational data changes. It enforces fine-grained security controls at the property level, not just the table level. And when it supplies context to a language model via Palantir AIP, it delivers scoped, structured objects — not raw data dumped into a prompt window.

This is not a minor distinction. The application layer sits between the model and the organisation’s data, and it controls what reaches the model and under what conditions.

How Ontology differs from standard RAG

Retrieval-augmented generation works by embedding chunks of text into a vector space and then retrieving the most similar chunks when a question is asked. It is useful for straightforward lookup. It is less reliable for complex relationships.

The problem with vector similarity is that it treats all text as essentially the same kind of thing. A chunk about a supplier contract and a chunk about that supplier’s compliance status will score similarly if they share vocabulary. The model then has to figure out the relationship from context it may never have had.

An ontology supplies that relationship explicitly. Human operators define the structure: what objects exist, how they relate, what properties they carry, and what actions can be taken on them. When the system queries the knowledge graph, it returns that structure alongside the data — the model does not have to infer it.

The result is more reliable reasoning about complex domains where relationships matter more than keyword overlap. More importantly, the organisation controls what structure gets presented. The model never sees raw data outside the scope of the defined objects.

The IP argument

Karp’s point about intellectual property exposure is worth taking seriously. When an enterprise uploads proprietary workflows, training data, or business history to a frontier model provider — the same labs that have shown the ability to surprise their own customers — that data leaves the organisation’s control. It may contribute to model improvement. It may be used to replicate business logic. The terms of service rarely clarify these points with precision.

The Ontology approach attempts to limit exposure by restricting what reaches the model to governed, scoped objects — not the raw source material. The model interacts with representations, not originals.

This is not a guarantee. It is a design choice that reduces the surface area of exposure. Whether it is enough depends on the sensitivity of the data and the organisation’s threat model — and on how you think about the backdoors and latent behaviours that may exist in any model you do not fully control.

Security and control

The interview also touched on security mechanisms built into the Ontology system:

  • Role-based and dynamic permissions that control which users and AI interactions can see which properties
  • Selective property exposure that prevents the model from accessing raw data fields
  • Audit logging of all AI interactions for compliance review
  • Support for on-premises and sovereign deployments, including with open-weight models through partnerships with providers like Nvidia

For UK organisations handling sensitive client or operational data, these features matter. Uncontrolled external processing of personal or commercial data raises compliance considerations under GDPR, DPA 2018, and sector-specific rules — the kind of regulatory risk that keeps firms thinking about on-premises AI.

The option to run everything on-premises, with an open-weight model and the application layer in your control, addresses those considerations at the architectural level rather than through contractual promises.

The comparison to lightweight agents

Karp’s three-layer stack — model, application layer, compute — is designed for enterprise scale. It addresses problems that do not always exist in smaller deployments.

Lightweight agent harnesses, including systems like Hermes Agent, use a different approach. Instead of a formal knowledge graph, they rely on persistent markdown files — identity and principles documents, skill files, context documents. These are effective for personal or small-team agentic work because they are flexible prompt-engineering tools. They adapt quickly to changing requirements. They work without infrastructure overhead.

We’ve written about agentic AI systems before, and how the right approach depends on the scale of the problem you’re trying to solve.

But they do not provide enterprise-grade data integration, formal semantic modelling, write-back governance, or the ability to enforce organisation-wide rules across siloed operational systems. They are not designed to replace the application layer Karp describes. They are designed to solve a different problem: giving individual users or small teams reliable, private AI assistance without the complexity of an enterprise stack.

The trade-off is real. Lightweight systems sacrifice formal structure for flexibility and speed. That trade-off makes sense in many contexts. It does not make sense in others.

Where the spin comes in

The JD Fortress angle to this interview is straightforward. Karp’s complaints about token economics, data exposure, and vendor control map directly onto the concerns that drive UK businesses toward on-premises AI.

The token tax is real. Enterprises that built workflows on cloud APIs are now exposed to cost volatility and data risk — a reality that hit home when Microsoft canceled Claude Code licenses and Uber burned through its AI budget in four months. The application layer is the missing piece that turns models into tools you can deploy with confidence.

What Karp did not say, probably because it is self-evident from his business model, is that the Ontology approach only works if you can afford the investment. Palantir is not a startup tool. It is enterprise infrastructure.

For most UK businesses, the question is not whether to buy Palantir’s Ontology. The question is whether to build something that addresses the same concerns — data control, cost predictability, and capability sovereignty — at a scale that makes sense.

That is the conversation we have with clients. It starts with the same concerns Karp raised on Squawk Box. It ends with a different stack, built for a different budget and a different threat model — one that works for law firms and accountants, not just defence contractors.

But the concerns are the same. The enterprise customers are right to be livid. The only question is what you do about it.


JD Fortress AI builds secure, on-premises RAG and agent solutions for UK businesses in regulated sectors. If you’re exploring always-on, private AI teammates — with predictable costs and data you actually control — get in touch for a confidential discussion.

Enjoyed this article?

If you're thinking about secure AI for your business, we'd love to have a conversation.

Get in Touch →
JD Fortress AI Internal Access