Palantir & AI operating systems
Connect agents to governed business context without turning every data source into an unrestricted prompt feed.
Operational agents need identity, scoped data access, tools, auditability, evaluation, and clear action boundaries.
Introduction
AI agents with enterprise data in practice.
Connecting agents to enterprise data is usually framed as a retrieval problem and is actually an execution permission problem. The question is not only what an agent can read, but what it can do with what it read, and under whose authority.
Operational agents need identity, scoped data access, tools, auditability, evaluation, and clear action boundaries. Retrieval quality matters, but it is the easiest of those to get right.
Common failure modes
- Treat agent access as an execution permission problem, not just a retrieval problem.
- Point tools that separate data, applications, and actions
- AI initiatives that stop at answers instead of operational outcomes
The problem
Why the current approach stops scaling.
The convenient path is to give an agent a broad service credential so it can reach whatever it needs. That makes the prototype work and makes the blast radius equal to the credential rather than to the job, which nobody discovers until an incident.
The second problem is that enterprise data carries permission semantics that a flattened index destroys. A document a user cannot see should not become reachable because it was embedded into a vector store the agent queries on their behalf.
You're likely here because
- Your agent uses a broad service account because scoping was hard
- Retrieval indexes ignore the source system's permissions
- Nobody can enumerate what the agent is allowed to do
Workflow
How the work actually runs, step by step.
Step 01
Give the agent an identity
A distinct identity with its own permissions, so access can be scoped, reasoned about, and revoked.
Step 02
Scope access to the job
Connect only the systems and records the task requires, preserving source-system permission semantics.
Step 03
Define the tools
Enumerate available actions and mark reversibility and approval requirements per action.
Step 04
Evaluate and trace
Measure behavior on real cases and record every input, decision, and action.
Architecture
The layers underneath the workflow.
Step 01
Agent identity
Its own principal with explicit permissions rather than a borrowed credential.
Step 02
Permission-aware retrieval
Access that respects the source system's rules rather than flattening them into an index.
Step 03
Tool boundary
A defined action surface with approval requirements attached per action.
Step 04
Audit and evaluation
Traceability and measurement, without which autonomy cannot responsibly increase.
Implementation path
What implementation looks like.
- 01
Define the job narrowly enough that its data requirements are enumerable.
- 02
Create a distinct identity and grant only the access that job needs.
- 03
Verify that retrieval respects source permissions on a deliberately restricted test document.
- 04
Enumerate tools and mark which require approval before use.
- 05
Run in propose-only mode, evaluate on real cases, then expand autonomy incrementally.
Controls
Controls that matter.
Control 01
Source-system permissions preserved end to end, including in retrieval.
Control 02
Consequential actions gated behind human approval until evidence supports otherwise.
Control 03
Complete audit trail of reads and actions, retained for review.
Examples
Worked examples.
Permission-preserving retrieval
A restricted document is placed in the connected source and the agent is asked about it. If it answers, the retrieval design is unsafe — a five-minute test that catches a common and serious defect.
Scoped operational agent
An agent handling one workflow gets read access to two objects and one write action, all traced. Its usefulness is unaffected and its blast radius is a fraction of the convenient alternative.
The permission question, asked too late
An agent that selects data before resolving who is asking has already made the sensitive decision by the time the permission check runs. Whether identity resolves first is not an implementation detail — it is the difference between a demo and something you can deploy.
Limitations and considerations
Limitations and considerations.
- Permission-aware retrieval is harder to build than a flat index, and the shortcut is tempting.
- Enterprise data quality directly caps agent reliability.
- Evaluation must be continuous, because model and tool changes shift behavior.
- Some data should simply be out of scope for agents regardless of technical capability.
- Access to enterprise data raises the cost of every existing data-quality and permission defect. Systems that act make organisational ambiguity consequential.
- Retrieval quality varies with the corpus. An agent grounded in stale or contradictory documents will be confidently wrong, and confidence is not a signal you can filter on.
FAQ
Questions people ask.
What does an enterprise AI agent need beyond an LLM?
It needs trusted context, identity, permissions, tools, evaluation, traceability, failure handling, and clear rules about which actions it may take.
Can we just index everything into a vector store?
Not safely. Flattening permissions into an index makes restricted content reachable through the agent, which is one of the most common serious defects in this pattern.
How do we test access control?
Place a deliberately restricted record in the source and ask the agent about it. The answer tells you whether permissions survived the retrieval design.
What is the first control to put in place?
Identity resolution before execution. Everything else — scopes, approval, audit — depends on the system knowing who is asking before it decides what to look at.
How much data should an agent be given?
The least that the specific workflow requires. Broad access is easier to configure and is the thing you will be asked to justify.
Related pages
Keep exploring.
Product path
Where this runs inside UbiVibe.
ARIA holds the operating context, Launch turns the requirement into working software, and Grow carries the commercial execution against the same connected records.
Build with Launch
Turn the operating requirement into working software.
- • Agent interfaces
- • Approval tools
- • Bounded actions
Operate with Grow
Keep the workflow connected after the interface exists.
- • Connect CRM, email, calendar, and pipeline context
- • Turn recommendations into bounded revenue actions
- • Keep outreach, meetings, pipeline, and attribution in one operating context
Connected context
Keep systems of record. Fix the gaps between them.
These are representative connections. UbiGrowth supports 700+ connections across business systems. Connection availability and permissions depend on workspace configuration.
Test the business case with your own operating assumptions.
Use the ROI calculator to model lead volume, close rate, deal value, and manual workload rather than relying on a generic outcome claim.
Open the ROI calculator →Start with ARIA
Put it to work on your own data.
Describe the outcome you want. ARIA establishes the operating context, selects the capabilities it needs, and runs the execution against the systems you already use.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Put ai agents with enterprise data to work on your own data.
Start with ARIA to establish the operating context, then build the surface and run the execution against the systems you already use.