Don't Give Agents a Master Key: Building Task-Scoped Toolboxes for Enterprise AI

The article opens with a common but dangerous claim: "We've connected CRM, ERP, email, tickets, and databases to the Agent; now it can do anything." While this sounds impressive, the author warns that connectivity does not equal production readiness. When an Agent queries key customers, modifies order commitments, adjusts inventory, and sends notifications simultaneously, the risk of unintended side effects becomes real.

Four Capability Layers for a Single Task

Using a regional operations manager's request—"Find key customer orders at risk of delay in the next seven days, assess impact, and propose remediation"—the author decomposes the work into four distinct capability layers:

Layer 1: Read Business Facts

The Agent queries Customer Order objects filtered by promised date, customer tier, and current risk, then traverses links to Shipment, Customer, Inventory, and related tickets. This layer is purely read-only; if the task is only a daily risk brief, the tool surface can stop here. There is no need to pre-grant write permissions because the Agent "might need them later."

Layer 2: Call Stable Functions

After retrieving orders, the Agent must prioritize them. Delay days, customer importance, breach cost, stock-out impact, and rerouting cost should not be recalculated by the LLM on every invocation. Instead, vetted business logic is encapsulated as a Function (e.g., a "Customer Impact Score"). The Agent decides when to call; the Function executes the rule deterministically. This ensures that humans, Workshop apps, custom applications, and the Agent all rely on the same calculation.

Layer 3: Generate Recommendations Without Mutating Production Data

With objects and computed scores in hand, the Agent assembles a remediation proposal containing:

Which orders to handle first

Evidence supporting each delay risk

Optional actions: cross-warehouse transfer, air freight upgrade, or renegotiated promise

Cost, risk, and impact of each option

At this stage the Agent delivers clear business value while production state remains unchanged. This boundary lets teams evaluate the Agent's selection accuracy, evidence completeness, and recommendation adoption rate before exposing any write capability.

Layer 4: Execute Only Through Explicit Actions

When execution is finally enabled, the Agent must not receive a generic "modify any object" tool. Instead, it sees only well-defined business verbs: "Submit cross-warehouse transfer," "Request air freight upgrade," "Propose new customer promise." Each Action has strict parameters, can bind Rules and Submission Criteria, and may be backed by a Function-backed Action for complex multi-object edits. The Agent receives not a free-form pen but a set of pre-approved buttons defined by the organization.

An End-to-End Invocation Chain

The article illustrates a complete high-risk order remediation flow (accompanied by a diagram):

User question or Automate trigger starts the task.

Agent queries object sets, follows links to enrich context (customer, shipment, inventory), and calls Functions to compute impact.

Agent returns recommendations with evidence. High-risk remediations go to human approval or enter a Scenario comparison; low-risk, reversible, well-validated actions may proceed directly to Action invocation after authorization.

After the Action writes back, the call identity, parameters, result, and subsequent business outcomes are retained for audit and evaluation.

A critical mistake is letting the same model propose, evaluate, and approve. If the Agent both suggests a plan and uses its own reasoning to deem it safe, the "safety check" is merely self-confirmation.

OSDK, OMCP, and Palantir MCP Are Not Synonyms

Three similarly named channels serve different personas (illustrated by a diagram):

OSDK (Ontology SDK) – A typed code channel. When building pro-code Agents or applications in TypeScript, Python, or Java, OSDK generates types and functions for a chosen Ontology subset, avoiding stringly-typed APIs.

OMCP (Ontology MCP) – An Agent-facing tool channel. It exposes Object Types, Action Types, and Query Functions from an application scope as MCP tools, allowing the Agent to find objects, read data, and execute controlled business actions.

Palantir MCP – A builder-facing platform channel. It helps builders view, create, and modify Ontology structures or other platform resources, but does not write actual Ontology business data.

One-sentence summary: OSDK lets code consume Ontology; OMCP lets Agents consume controlled business capabilities; Palantir MCP helps builders evolve the platform and Ontology structure. The current Agents template can combine all three, but "can combine" does not mean "should expose everything." An Agent responsible only for high-risk order remediation has no reason to possess Object Type creation or platform modification privileges.

Permission Is an Intersection of Multiple Boundaries

The question "Does this Agent have Ontology permission?" is too coarse. A tool invocation succeeds only if all of the following layers align:

Identity – Is the operation performed on behalf of the current interactive user or an unattended service user?

Application Scope – Which Ontology entities and tools are bound to this Agent?

Underlying Permissions – Does the current identity actually have read access to these objects, permission to call this Query, or submit this Action?

Action Gate – Are parameters valid? Do Rules and Submission Criteria pass? Is human approval required for this class of remediation?

These layers are not substitutes. Visibility of an Action in the application does not guarantee the current user can execute it; a user's standing permissions do not guarantee a specific parameter set will pass the Action's validation. Security boundaries must be enforced by the system, not encoded in prompts. "Do not modify payment data" is a behavioral guideline, not a policy. The real policy: payment objects are outside the application scope, the identity lacks write permission, and no Action capable of modifying payments exists in the tool list.

Who the Agent Represents Changes the Entire Design

OMCP builds on Developer Console's OAuth 2.0. Two identity modes must be separated:

Interactive User – The user chats with the Agent in the UI, authorizes via Authorization Code Grant, and the Agent acts as that user. Its data visibility and action capability never exceed the user's own.

Unattended Service – Nightly scans or event-driven remediations run via Client Credentials Grant under a service user. This must not become an excuse for "no one logs in, so give it full access." The service user needs a narrower object scope, fewer Actions, explicit run windows, frequency limits, and exception handling. Otherwise a helpful assistant becomes a 24/7 high-privilege automation account.

Where Humans Belong and Where Scenarios Belong

Human approval is not a universal safety button. Mandating a click for every minor action causes approval fatigue and rubber-stamping. Instead, gate by risk, reversibility, and blast radius:

Low-risk, reversible, single-object actions: execute after rule validation.

Medium-risk actions: Agent proposes; a responsible human approves before Action submission.

High-risk, multi-object, or external-commitment changes: enter a Scenario to compare alternative futures before any production write.

Humans are placed at the point of heaviest accountability, not in front of every tool call.

Six Tool-Design Anti-Patterns

One giant generic tool – e.g., run_sql, update_any_object, call_any_api. They hand all freedom to the model while stripping away semantics, validation, and audit meaning.

Hiding write side-effects inside a "query" – A tool named "Check and Fix Order" blurs the read/write boundary for both the Agent and the evaluation system. Queries and Actions must have clear semantic separation.

Treating prompts as a permission system – "Please do not delete important customers" is not an enforceable constraint. Tool allow-lists, application scope, underlying permissions, and Action validation are.

Sharing a single high-privilege service user – Erases legitimate access differences between users and makes it impossible to answer "Who did this operation represent?"

Vague, overlapping tool names – "Process Order," "Fix Order," "Update Order" without clear boundaries force the model to guess by linguistic feel. Good tool names mirror business verbs; parameters mirror organizational nouns.

Letting the Agent click the UI when an Action exists – UI automation suits legacy systems without stable APIs. If a governed, rule-bound, auditable Action already exists, driving the Agent to mimic clicks merely bypasses the stronger business boundary.

Six Gates Before an Agent Goes to Production

(Accompanied by a diagram)

Task Boundary – Can you state in one sentence what the Agent owns and explicitly does not own?

Tool Allow-List – Does every tool map to a single, well-defined business capability without hidden side-effects?

Identity & Permissions – Do interactive calls represent the current user? Does the unattended service user follow least privilege?

Write Validation – Are all mutations performed through parameterized, rule-governed, submission-criteria-gated Actions rather than direct arbitrary data edits?

Human or Scenario Gate – Which decisions require a human to own the outcome? Which should first be compared in a sandbox?

Outcome Evaluation – Can the team trace tool selection, parameters, results, and actual business consequences to decide whether to expand autonomy?

These gates are not meant to lock the Agent out forever. They provide a trustworthy upgrade path: start with read-only, then generate suggestions, then enable bounded writes after stability is proven, and finally automate only those tasks that are quantifiable, reversible, and traceable.

Prove the Agent can judge first, then unlock action level by level.

A production-ready Agent does not need to be a system administrator. It only needs a toolbox prepared for the current task, and it must know exactly how far each tool can reach.

The next article will tackle the inevitable challenge after Ontology permeates applications and Agents: when objects, properties, Functions, and Actions are all depended upon downstream, how can Ontology evolve without "pulling one thread and moving the whole body"?

References

[1] Palantir Docs: Agents overview – https://www.palantir.com/docs/foundry/agents/overview [2] Palantir Docs: Ontology MCP overview – https://www.palantir.com/docs/foundry/ontology-mcp [3] Palantir Docs: Ontology MCP authentication and authorization –

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

[4] Palantir Docs: Example MCP workflows –

https://www.palantir.com/docs/foundry/ontology-mcp/example-mcp-workflows

[5] Palantir Docs: Ontology SDK overview – https://www.palantir.com/docs/foundry/ontology-sdk/overview [6] Palantir Docs: Functions overview – https://www.palantir.com/docs/foundry/functions/overview [7] Palantir Docs: Functions on objects –

https://www.palantir.com/docs/foundry/functions/functions-on-objects

[8] Palantir Docs: Function-backed Actions –

https://www.palantir.com/docs/foundry/action-types/function-actions-overview