The Ontology Is the Policy

How Palantir's Data Model Became the De Facto Access Control System for Federal AI — and Why That's a Governance Problem Nobody Has Named Yet

Somewhere in the Department of Health and Human Services, an AI agent is deciding what it can touch. Not in the way a human analyst decides, by reading a policy document, checking a clearance level, consulting a supervisor. The agent decides by querying a data model: a structured representation of what objects exist in the world, what attributes those objects carry, and what relationships govern who or what can act on them. The model answers the question. The agent proceeds.

That data model belongs to Palantir.

This is not, on its face, alarming. Every software system embeds assumptions about data structure, and every access control system has to be implemented somewhere. Palantir's ontology layer makes access decisions by design, and that's part of what agencies are buying. The more consequential question is whether the agency that deployed it actually decided what those access decisions should be, or whether it adopted a platform that decided for it. That distinction is where the governance gap lives, and it's the gap I want to spend some time on here.

The Move, Stated Efficiently

Palantir's federal civilian business has been expanding steadily since the company reoriented its go-to-market around AIP, the Artificial Intelligence Platform it began deploying in earnest through 2024 and into 2025. The pitch is integration: AIP connects to an agency's existing data sources, applies Palantir's ontology layer to create a unified object model, and then allows AI agents and human analysts to query, reason over, and act on that unified model. The ontology is the connective tissue. It's what makes a "patient record" in one system the same object as a "beneficiary" in another, and it's what governs which agents can read, modify, or trigger actions on either.

By early 2026, Palantir had active AIP deployments across at least a dozen federal civilian agencies, with the Department of Veterans Affairs, the Centers for Medicare and Medicaid Services, and the Department of Homeland Security representing the largest contract values. The company's U.S. government segment reported revenue of approximately $890 million in fiscal 2025, with civilian agencies accounting for a growing share of that figure, roughly 38 percent by my read of the segment disclosures, up from about 29 percent two years prior. On the Q4 2025 earnings call, CEO Alex Karp described the civilian expansion as "the next phase of the platform's maturation," which is the kind of language that sounds like marketing until you look at what the platform is actually doing in those deployments.

What it's doing is building ontologies. And those ontologies are doing more governance work than the contracts acknowledge.

The Puzzle

The consensus read on Palantir's federal success is roughly this: the company has clearances, relationships, and a mature data integration story that most enterprise AI vendors can't match. It has been operating in classified and sensitive environments for two decades. It knows how to navigate procurement. It knows how to survive a political cycle. When agencies need to deploy AI on sensitive data, Palantir is a credible choice in a field where credibility is scarce.

All of that is accurate. It's also not the structural question worth asking.

When an agency deploys AIP and the ontology layer starts governing what an AI agent can see, touch, and act on, who actually made those governance decisions? The agency's Chief Information Security Officer signed off on the deployment. The agency's privacy officer reviewed the data sharing agreements. The agency's contracting officer approved the task order. But did any of them specify, in policy language, that a "case record" object in the ontology should be readable by an agent with a "tier-2 analyst" role but not writable by an agent with a "tier-1 intake" role? Did they specify that a "beneficiary" object's financial attributes should be masked when accessed through an automated workflow but visible when accessed by a human analyst?

My read is that in most deployments, they didn't, not at that level of specificity. They adopted a platform whose ontology made those decisions, and they reviewed the outcome rather than the architecture. The difference matters enormously, and it's the difference I want to make precise.

How the Ontology Layer Actually Works as Access Control

The argument depends on the mechanism, so let me be specific about it.

Palantir's ontology is not a simple schema. It is a typed object model that defines entities (a "person," a "case," a "transaction"), their attributes (name, status, financial value, risk score), and the relationships between them (a person is a "beneficiary" of a program, a case is "assigned to" an analyst, a transaction is "flagged by" a rule). Each object type carries metadata about who or what can perform which operations on it: read, write, link, trigger an action. In AIP deployments, AI agents interact with the world through this ontology. An agent doesn't query a database directly; it queries the ontology, which mediates what the agent can see and do.

This is, functionally, an access control system. It determines, at the object level, what operations are permitted for which principals. The fact that it's called an "ontology" rather than an "access control list" is a labeling choice, not a functional distinction. When a Palantir engineer defines that a "case record" object is readable by agents with a "workflow-automation" role but not modifiable without a "human-in-loop" flag, that engineer has made an access control decision. The decision is expressed in the ontology's type definitions rather than in a policy document, but the effect is identical.

In federal IT, access control decisions are supposed to be made by the agency's own policy layer, specifically by the combination of the agency's security classification guide, its privacy impact assessment, its system security plan, and its role-based access control policy. These documents are auditable. They are reviewed by the agency's Inspector General. They are subject to FISMA compliance assessments. They represent the agency's formal expression of who can do what with which data.

When the ontology layer is doing the access control work, those formal documents describe a policy that may or may not match what the platform is actually enforcing. The gap between the documented policy and the implemented policy is not necessarily malicious. Palantir is not trying to circumvent federal security requirements. But it is structural. The ontology was designed by Palantir's engineers to be expressive and flexible, not to map cleanly onto any particular agency's existing policy framework. When an agency adopts AIP, it is adopting Palantir's object model and then trying to configure that model to approximate its own policy. The approximation is imperfect by design, because the ontology's categories and the agency's policy categories were built by different people for different purposes.

This is the part that gets obscured by the deployment narrative. Agencies talk about "configuring" the ontology to match their requirements. Palantir's documentation describes a rich set of configuration options. But configuration is not the same as specification. When you configure a system, you are choosing among options the system's designers anticipated. When you specify a policy, you are defining requirements from first principles. Federal access control policy is supposed to be the latter. AIP deployments are, in practice, the former.

What the Agency's Structure Forces It to Accept

There is a structural reason why this gap persists, and it has less to do with negligence than with the mismatch between how agencies procure software and how platforms actually work.

Federal procurement is built around requirements. An agency defines what it needs, vendors respond, the agency selects the best match. The requirements document for an AI platform deployment will specify things like: must integrate with existing data sources, must support role-based access control, must comply with FISMA Moderate baseline, must provide audit logging. Palantir's AIP satisfies all of these requirements. The ontology layer provides role-based access control. It produces audit logs. It can be configured to implement FISMA-compliant controls.

What the requirements document does not, and practically cannot, specify is the exact object model that the ontology will implement. That level of specification would require the agency to have already built the thing it is procuring. So the agency specifies outcomes and accepts that the vendor will make architectural decisions in pursuit of those outcomes. This is rational procurement behavior. It is also how the policy layer migrates into the vendor's architecture.

Once the ontology is deployed and operational, the migration becomes self-reinforcing. The agency's analysts learn to work within the ontology's categories. The agency's AI agents are trained on data that the ontology has structured. The agency's workflows are built around the ontology's object relationships. At this point, changing the ontology is not a configuration task; it is a migration project with significant operational risk. The agency is locked in, not by contract terms, but by the accumulated weight of decisions that assumed the ontology's structure. The vendor's architectural choices have become the agency's operational reality, and the agency's own policy documents are now describing a system that the ontology is approximating rather than implementing.

That's the governance gap. Not a missing control, but a misalignment between where decision authority is formally located (the agency's policy layer) and where it is practically exercised (Palantir's ontology). The agency's CISO can update the security plan. The agency's privacy officer can revise the PIA. Neither of those updates changes what the ontology enforces until Palantir's engineers implement the change in the object model. The formal policy and the effective policy have diverged, and the effective policy is maintained by a commercial vendor.

A Digression That Earns Its Place

In the early 2000s, Microsoft Active Directory became the de facto identity and access control infrastructure for enterprise IT. This happened gradually and then all at once: organizations deployed AD to manage user accounts, then extended it to manage group memberships, then built their entire security architecture around AD's schema for defining who belongs to which group and which groups can access which resources.

AD's schema was not neutral. It embedded Microsoft's assumptions about how organizations work: hierarchical domains, trust relationships between domains, a particular model of group inheritance. When an organization needed to express a security policy that didn't fit AD's model, say, a policy that granted access based on project membership rather than organizational hierarchy, it had two options: bend the policy to fit the schema, or build a workaround that lived outside the schema and therefore outside the audit trail. Most organizations bent the policy. The path of least resistance was to express security requirements in terms that AD could implement, which meant expressing them in terms that Microsoft had anticipated.

The governance implication was not obvious at the time, but it became visible during regulatory audits. When a bank's auditors asked to review its access control policy, the bank would produce a policy document. When the auditors then tested whether the implemented controls matched the policy, they were effectively testing whether AD's schema matched the policy document, and often finding gaps that were artifacts of AD's model rather than failures of the bank's intent. The policy said one thing; the schema did another; the gap was structural.

I am not claiming that Palantir's ontology is Active Directory. The analogy is imperfect in several ways: AIP is a more recent and more explicitly AI-oriented platform, the ontology is more expressive than AD's schema, and the federal context introduces compliance requirements that enterprise IT did not face in the same form. But the structural dynamic is the same. A commercial platform's data model becomes the effective policy layer for an institution. The institution's formal policy documents describe what the platform is supposed to do, not what it actually does. The gap between the two is maintained by the vendor's engineering team, not the institution's policy team. And the gap is self-reinforcing because changing the platform's model is operationally expensive.

The AD parallel also points toward a trajectory. Microsoft eventually recognized that AD's governance role created both an obligation and an opportunity: an obligation to make the schema auditable and policy-expressive, and an opportunity to sell governance tooling on top of the identity layer. The identity layer became the platform for a governance product line. I suspect Palantir is on a similar path, and I'll return to that in the prediction.

Naming the Framework

The dynamic I've been describing is what I'll call architectural capture: the process by which a commercial platform's design decisions become functionally equivalent to a regulated institution's own governance decisions, without being labeled as such and without being subject to the same accountability structures.

Architectural capture has three stages:

1. Adoption with underspecification. The institution adopts a platform to implement a function, access control, data governance, workflow management, and the platform's architecture makes design choices that the institution's requirements document did not fully specify.

2. Operational accumulation. The institution's operations accumulate around the platform's architecture, making the architecture expensive to change and making the institution's formal policy documents increasingly descriptive of the platform rather than prescriptive of the institution's intent.

3. Governance leverage. The effective policy is maintained by the vendor's engineering team, and changes to the effective policy require vendor cooperation, which means the vendor has acquired a form of governance leverage that was never explicitly granted.

The key feature of architectural capture is that it is not adversarial. The vendor is not trying to capture governance authority; it is trying to build a useful platform. The institution is not trying to cede governance authority; it is trying to deploy a capable system. The capture happens in the gap between what the institution specified and what the platform implemented, and it is reinforced by the operational costs of undoing it. By the time the gap is visible, it is expensive to close.

This framework applies beyond Palantir and beyond federal AI. Any time a regulated institution adopts a platform whose architecture makes governance decisions that the institution's own policy layer should be making, architectural capture is the risk. The federal context makes it particularly consequential because the accountability structures, FISMA, IG audits, congressional oversight, are formal and public, which means the gap between documented policy and effective policy is eventually discoverable. In less formally regulated environments, the gap might persist indefinitely without anyone naming it.

The federal context is the right terrain for this analysis not because the risk is unique to government, but because the accountability structures make the gap legible. When a federal IG eventually asks whether the implemented access control matches the documented policy, the answer will reveal the gap. In a private enterprise, that question might never be asked with the same rigor.

The Committed Prediction

By the end of fiscal year 2027, at least one federal agency's Inspector General will publish a finding that specifically identifies a gap between the agency's documented access control policy and the effective access control implemented by a commercial AI platform's data model. The finding will not use the phrase "architectural capture." It will probably describe the gap as a "configuration management deficiency" or a "policy implementation gap." But the structural observation will be there: the agency's formal policy says one thing, the platform does another, and the agency cannot close the gap without vendor cooperation.

When that finding lands, Palantir will face a choice between two responses. The first is defensive: the gap is a configuration issue, the agency failed to implement the ontology correctly, the platform provides the tools to express any policy the agency requires. This response is technically defensible and strategically wrong, because it will invite regulatory scrutiny of the ontology's expressiveness, scrutiny that will reveal the limits of what "configuration" can achieve.

The second response is the smarter one, and it is the one I expect Palantir to eventually make: the company will build a governance product layer on top of the ontology, explicitly designed to map agency policy documents to ontology configurations and to audit the gap between the two. This is the Active Directory trajectory. The identity layer becomes the platform for a governance product line. Palantir's ontology becomes the substrate for a compliance and audit product that agencies buy because they need to demonstrate that the effective policy matches the documented policy, and only the ontology vendor can provide that demonstration.

If that product exists by the end of 2027, the prediction is confirmed. If Palantir is still describing the gap as a configuration problem, the prediction is wrong and I'll revisit the framework.

There is a third possibility worth acknowledging: Congress or OMB could move first, requiring that AI systems operating on federal data implement access control through agency-controlled policy layers rather than vendor-controlled data models. The Biden-era AI executive order gestured at this kind of requirement without specifying the mechanism; the current administration's approach to AI governance has been lighter-touch. My read is that regulatory intervention at this level of architectural specificity is unlikely before the IG finding forces the issue, but I hold that read loosely, because federal AI governance is moving faster than most observers expected two years ago.

The Structural Observation Worth Keeping

The opening image is the argument.

An AI agent is deciding what it can touch. It is doing so by querying a data model that belongs to a commercial vendor. The agency that deployed the agent has a policy document that describes what the agent should be able to touch. The policy document and the data model are not the same thing, and the data model is what the agent actually consults.

Procurement didn't fail here. Palantir's engineering didn't fail. This is a structural consequence of how platforms work: they embed governance decisions in architecture, and architecture is harder to audit than policy. The agency's formal accountability structures, its security plans, its privacy assessments, its IG audits, are designed to review policy. They are not designed to review architecture. The gap between the two is where architectural capture lives.

The federal context makes this consequential in a specific way. Federal agencies are accountable to the public for how they handle data about citizens. That accountability is expressed through formal policy documents that are supposed to describe what the agency actually does. When the effective policy is maintained by a vendor's engineering team rather than the agency's own policy layer, the formal accountability structure is describing a fiction, not a malicious one, but a fiction nonetheless. The agency is accountable for a policy it does not fully control.

Palantir did not set out to become a governance authority for federal AI. It set out to build a platform that makes AI deployable on complex, sensitive data. It succeeded at that. The governance authority is a byproduct of the success, not the goal. But byproducts have consequences, and this one is worth naming before the IG finds it.

The ontology is the policy. That's the thing that needs to be understood, by the agencies deploying it, by the oversight bodies reviewing it, and by anyone watching the next vendor make the same move in a different domain.

On Signal — The Outer Ring publishes analytical frameworks for operators and investors tracking structural change in technology markets. This piece is a preview demonstration; specific figures and deployment details are illustrative of the argument's structure and should be verified against primary sources in production.