Don't Give Your AI Agent a Super Admin: Palantir Ontology Permission Design

Palantir illustrates the permission challenge with an airline customer‑service agent: a flight is delayed, the agent finds an alternative and knows which Action to call, but the real questions remain — can the agent see the passenger’s name and phone? Can it access VIP records? Can it swap the aircraft? Does it act as the logged‑in agent or a privileged system account? Must a human confirm the rebooking?

A simple “allow AI” toggle answers none of these. Enterprise AI permissions are a chain of runtime judgments: under whose identity, on which object, viewing which properties, calling which tool, under what conditions executing which action.

Definitions vs. Instances: Two Permission Layers

Palantir separates permissions into two categories:

Definition layer — who can view, modify, or manage Object types, Link types, and Action types (the ontology resources).

Instance layer — who can see a specific object and which property values within that object.

Seeing the Passenger type structure does not grant visibility into every passenger; seeing a passenger does not grant access to their name, address, or phone. This distinction matters because many systems only control menus and pages, not the data that actually reaches the user.

Same Passenger, Different Worlds

Palantir’s documentation uses a Passenger object containing flight number, seat, name, address, phone, and a VIP flag. Visibility operates at three levels:

Object type — can the user discover the Passenger concept?

Object — can the user see a specific passenger record?

Property — which attribute values are visible for that passenger?

Object security policies enforce row‑level visibility (e.g., non‑VIP users cannot see VIP passenger objects). Property security policies enforce column‑level visibility (e.g., operations staff see flight and seat, but PII fields require explicit PII permission). When both policies apply, the result is cell‑level: the object exists but restricted properties return empty values. Permissions are computed at the intersection of user, object, and property — not by painting an entire table with one color.

An important boundary: object and property policies only govern visibility inside the Ontology. A Media Reference property pointing to an external media resource still requires separate permissions on that resource. Hiding the entry point does not secure the resource itself.

Seeing Is Not Doing: Action Permissions

Actions add another layer. The documentation breaks Action permissions into: who can see the Action type, who can modify it, and who can actually submit it with a given parameter set. Submission requires visibility into the edited object types, link types, and related data, plus passing the Action’s own submission criteria .

Submission criteria are not static role tables. They can evaluate at runtime:

Current user or user group

User’s organizational attributes

Parameters supplied in this submission

Current state of the target object and linked objects

Example: reassigning an aircraft for a flight may require the submitter to belong to the Flight Control group and the candidate aircraft to be in operable status. A different user or a grounded aircraft yields a different outcome.

Palantir recommends that new object types default to edit‑only‑via‑Actions. Granting direct write access to a dataset often exposes the entire writeback dataset — more privilege than the business action needs. Routing writes through Actions keeps input, validation, business semantics, and audit trail inside a single boundary. “Can edit data” and “can execute a specific business action” are distinct authorizations.

Agents Add Two Extra Questions

Traditional apps have fixed pages and buttons. Agents choose tools, assemble parameters, and may chain multiple tools. Therefore, beyond data and Action permissions, two questions must be answered:

Which tools does the agent have?

Under whose identity does it run?

In Palantir’s AIP Chatbot Studio, the Object Query tool can restrict which object types and properties the model may query; the Action tool can be set to auto‑execute or require user confirmation. Functions, Commands, and other tools must be explicitly configured. This demonstrates that prompts are not a permission system . “Please do not access sensitive information” may guide model behavior but cannot replace object policies, property policies, and tool scopes. Real boundaries live outside the model: don’t give it the tool, don’t return restricted properties in query results, and re‑check deterministically at Action submission.

Identity is easily overlooked. An interactive agent can act on behalf of the logged‑in user, constrained by that user’s permissions. Background agents, scheduled automations, or system integrations may run as a service user or automation owner. Neither is inherently better, but the accountability differs. If a customer‑service agent suddenly runs under a “central system administrator” service account, the carefully designed row‑, column‑, and Action‑level controls can be flattened. Service identity must be an explicit engineering choice, not a backdoor to avoid permission errors.

Palantir’s pro‑code Agents documentation marks scoped permissions as Beta. The official statement: an agent’s access scope is jointly constrained by the Ontology binding and application limits chosen at publish time. Ontology MCP distinguishes authorization‑code flow (acting for the end user) from client‑credentials flow (acting for a service user). Product details may evolve, but the principle remains: first clarify who the agent represents, then discuss what it can do.

Walkthrough: A Safer Rebooking Flow

Returning to the delayed flight, a more robust design:

The agent inherits the currently logged‑in agent’s identity.

Object Query exposes only necessary types ( Flight, Passenger, Booking) and returns only task‑required properties. If the agent lacks PII permission, the query omits name and phone.

A Function computes alternative flights and rebooking impact — it calculates, it does not bypass permissions.

The agent selects the Rebook Passenger Action, filling passenger, target flight, and reason. The Reassign Aircraft Action is not in the agent’s tool set at all.

Before submission, the Action re‑checks current user, passenger status, flight capacity, and business rules. High‑compensation or special‑passenger cases require human confirmation.

After write‑back, the log captures identity, timestamp, parameters, and result. Later audits can trace “who, via which agent, in what context, executed what action.”

This example combines Palantir’s documentation on object security, Action permissions, tool configuration, and scoped permissions; it is not an official customer case study.

Common Pitfalls: Doing Only Half the Job

The author highlights frequent gaps in enterprise systems:

Only managing project roles, not object/property visibility — sensitive rows and columns leak once the app opens.

Hiding buttons in the UI but not enforcing checks at Action submission — a different client or API call bypasses the UI.

Treating prompts as security boundaries — “the model probably won’t” is not “the system guarantees it cannot.”

All background processes sharing a single super‑service account — automation convenience erases accountability boundaries.

Notifications, attachments, and external resources using a separate permission system — the body is hidden but the email or file link leaks the content.

A specific trap from Palantir docs: when using user groups, tags, or org membership in submission criteria, avoid NOT conditions. Scoped tokens may carry only a subset of user attributes; a missing attribute can cause a NOT condition to pass unexpectedly. In security design, “absence of allow” is more reliable than “absence of deny.”

Six Questions Before Connecting an Agent to Production

Who does this execution represent — the current user, the automation owner, or a service user?

Which Object types, Action types, and Functions can it discover?

For each object, which instances and properties are visible?

Which tools are offered to the model, and which are excluded entirely?

Which Actions auto‑execute, and which require human confirmation or escalation?

Can the final audit log reconstruct identity, inputs, decisions, write‑backs, and external side effects?

If the only answer is “we have single sign‑on,” the permission design hasn’t started.

Permissions Are Part of the Decision Model, Not a Fence

Many teams treat security as a post‑launch audit item: ship features first, let security add roles and lists later. With Ontology and Agents, that order is dangerous. How objects are partitioned, which properties are sensitive, what intent an Action expresses, which identity an agent assumes, which actions need confirmation — all feed back into the business model itself.

Permissions are not a shell wrapped around the decision system. They participate in every read, every tool selection, and every write. The previous chapter gave data “verbs” via Actions. This chapter adds the judgment: a verb must carry subject, object, conditions, and an audit record to qualify for real business use.

Next chapter: RAG finds documents, Ontology finds objects — what does Ontology‑Augmented Generation add over traditional retrieval?

References

[1] Palantir Docs: Object permissioning overview —

https://www.palantir.com/docs/foundry/object-permissioning/overview/

[2] Palantir Docs: Ontology permissions —

https://www.palantir.com/docs/foundry/object-permissioning/ontology-permissions/

[3] Palantir Docs: Manage object security —

https://www.palantir.com/docs/foundry/object-permissioning/managing-object-security/

[4] Palantir Docs: Object and property security policies —

https://www.palantir.com/docs/foundry/object-permissioning/object-security-policies/

[5] Palantir Docs: Action permissions —

https://www.palantir.com/docs/foundry/action-types/permissions/

[6] Palantir Docs: Submission criteria —

https://www.palantir.com/docs/foundry/action-types/submission-criteria/

[7] Palantir Docs: AIP Chatbot Studio tools — https://www.palantir.com/docs/foundry/chatbot-studio/tools/ [8] Palantir Docs: Agents scoped permissions (Beta) —

https://www.palantir.com/docs/foundry/agents/scoped-permissions/

[9] Palantir Docs: Ontology MCP authentication and authorization —

https://www.palantir.com/docs/foundry/ontology-mcp/authentication-and-authorization/

[10] Palantir Docs: Automate permissions —

https://www.palantir.com/docs/foundry/automate/permissions/