How to Build Secure AI Agents with Palantir’s OSDK and Ontology MCP

Why the First Step Is "Ontology Binding"

When creating an Agent in Foundry, the workflow is: select a repository → choose an Agent framework (Claude SDK / OpenAI SDK / Google ADK) → select an ontology (required) . This selection is not a formality; it performs Ontology Binding , which directly determines three aspects of the Agent:

What data it can read and write

Which scoped permissions apply

Which Ontology actions it can invoke

In other words, ontology binding defines the Agent’s permission boundary, confining it to a narrowly scoped space instead of granting a company‑wide API key.

This design solves the audit problem of traditional agents that connect directly to databases with scattered permissions; Palantir centralises all access control at the ontology layer, ensuring every operation passes through a unified security framework.

Three Reader Levels, Three Reading Approaches

🟢 Beginner: Giving the Agent a "Door Card"

Think of the enterprise building as having many rooms. The traditional approach gives the Agent a master key (API key) that opens every door, making it impossible to track which rooms were accessed. Palantir’s approach issues a "door card" that hard‑codes restrictions such as "only access the R&D floor, read‑only". This card is the ontology binding; an Agent trying to enter the finance room is blocked outright.

Ontology binding = Agent permission card .

🔵 Intermediate: OSDK + Ontology MCP Toolkit

OSDK (Ontology SDK) is a type‑safe client for developers. Using it to access the ontology gives IDE autocompletion for objects, properties, and links, and the compiler catches errors. It relies on scoped permissions, so developers do not need to provide a client ID, secret, or Foundry token; the Agent’s identity determines its permissions.

import { getOntologySdkClient } from "@palantir/agent-templates-bundle";
import { $ontologyRid } from "@ontology/sdk";

const client = await getOntologySdkClient($ontologyRid); // client.objects... now have type hints

Ontology MCP (OMCP) exposes all ontology objects, attributes, links, and actions as a standard MCP tool. Any MCP‑compatible Agent (Claude, GPT, etc.) can connect, read objects, query data, and execute predefined actions, all under the same security controls as native Agents.

A Minimal Agent Example

Providing the OMCP configuration to the model as an MCP server gives the Agent ontology access while keeping it within the security framework:

export async function runAgent(args: AgentArgs) {
  const omcpConfig = await getOntologyMcpConfiguration();

  const iter = query({
    prompt: "找出受供应商 X 中断影响的所有订单，并估算损失",
    options: {
      mcpServers: {
        "ontology_mcp": omcpConfig, // ontology injected as a tool source
      },
    },
  });

  // consume response stream...
}

The line mcpServers: { ontology_mcp: omcpConfig } shows that the Agent does not need to know the underlying database; it simply knows it can use the "ontology_mcp" tool, whose capability boundaries are locked by the ontology binding.

When publishing, tag the repository (e.g., 1.0.0) so Foundry registers it as an asynchronous function. At runtime, invoke it via Automate, the low‑code Workshop, or programmatically through OSDK.

Pitfall: Agent functions do not return values. Results must be written back to Ontology objects, reinforcing the idea that the ontology is an "operational" store rather than a place to return strings.

How This Piece Connects to Earlier Articles

Part 05 built the OWL ontology (the "model" layer).

This part (06) adds the OSDK/MCP interface layer that lets Agents "use" the model.

Part 03 described Palantir’s four‑element architecture; here the OSDK handles type‑safe data/logic access, and MCP exposes actions as tools.

In one sentence: the ontology is the semantic foundation (05), OSDK/MCP are the interfaces (06), and Palantir’s four‑element architecture organises these interfaces into a decision‑making hub (03).

Key Takeaways

Palantir makes ontology binding the first step for Agents, defining a clear permission boundary and eliminating scattered API keys.

OSDK gives developers type‑safe access based on scoped permissions, removing the need for credentials.

Ontology MCP turns the ontology into a standard MCP tool, allowing external AI models to operate under the same security constraints.

The ontology acts as a "tool factory": new object types automatically become new tools, turning specialised knowledge into shared organisational infrastructure.

Agent functions do not return values; they must write results back to ontology objects.

Full stack: ontology foundation (05) → OSDK/MCP interface (06) → four‑element decision hub (03).