lakeFS FOR AGENTIC AI
Production Data for AI Agents, Without the Production Risk
AI agents read, write, and modify enterprise data at machine speed. Your infrastructure was built for pipelines and people – agents break both assumptions. lakeFS, the control plane for AI-ready data, gives every agent an isolated, governed, and reproducible workspace on the storage you already have.
- Zero-copy isolation
- Reproducible runs
- Governed promotion
- Full auditability
THE EXPOSURE IS IN THE DATA
Most of the effort to make agents safe goes into the prompt, the workflow, and the compute. The data the agent reads and writes is left largely ungoverned – and that is where the real exposure sits.
Agents are non-deterministic, not inherently accountable, and fast. Given production access, an agent can traverse, modify, and delete data at a speed no human can monitor in real time.
WHY AGENTS BREAK YOUR DATA STACK
Your stack was built for pipelines and people. Agents break both assumptions.
Pipelines run the same code on every execution – versioned, audited, owned. People operate within defined roles, with an audit trail and someone to hold accountable. Agents are neither: non-deterministic by design, optimizing for outcomes rather than transparency about how they got there, and operating at machine speed.
Before an agent touches production data, three questions need an answer:
- Can you re-create the exact data state an agent saw when it acted?
- Can you contain what an agent writes before it reaches production?
- Can you roll back an agent’s mistake across every dataset it touched, as one unit?
Whitepaper
When Agents Touch Production Data
Trust, Isolation, and Reproducibility for Agentic AI
AGENT-READY BY DESIGN
The Solution: One control plane between your data and your agents
lakeFS adds a light infrastructure layer between your object storage and the tools, users, and agents that consume it. Existing data stays in place, under your control – no migration, no copies.
Agents work on data the way they already know how: plain file I/O on a mounted directory via lakeFS Mount, an S3-compatible gateway, or the Iceberg REST Catalog. No SDK, no MCP server, no custom integration. Underneath, a highly scalable data version control engine gives every agent workload isolation, reproducibility, and governance by design.
Isolated agent sandboxes
Every agent works on a zero-copy branch of production data. All the data, none of the risk: changes stay contained until explicitly merged, and branch protection blocks direct writes to main.
Reproducible agent runs
Every action is tied to an immutable commit: who or what changed the data, when, and with what context. Any run, report, or output can be re-created with the same inputs.
Governance in the access path
Granular RBAC and branch-scoped credentials confine each agent to its workspace. Pre-merge hooks gate what reaches production. Every read and write is audited.
Agent-native data access
Agents mount a branch as a local directory and do plain file I/O – no S3 client, no API calls, no MCP server needed. Tables are one Iceberg REST Catalog query away.
Business Impact
- Contained blast radius
An agent’s mistakes stay on its branch. One revert rolls back everything a run touched – in seconds, as one unit.
- Zero-cost sandboxes
A branch is a pointer, not a copy. Per-agent, per-run, even per-task sandboxes without duplicating a byte of storage.
- Pilot to production
Reproducibility decides whether agent workloads make it past the pilot stage. Isolation and approval gates are infrastructure, not per-project engineering.
- Audit-ready by default
Every agent read and write is recorded, every change committed and attributed – evidence built in before anyone asks.
THE DIFFERENCE
With and without lakeFS
Without lakeFS
With lakeFS
Agent access to production data
Direct writes to the production store, or full copies made per project
A zero-copy branch per agent, per run – contained until explicitly merged
Reproducing an agent run
Logs show what the agent did, but the data state it saw is gone
Every action is tied to an immutable commit – re-create any run with the same inputs
Controlling what lands in production
A human-in-the-loop prompt is a statement of intent, not a control
Pre-merge hooks enforce quality, policy, and approval gates below the agent
When an agent makes a mistake
Manual, non-atomic recovery across every dataset the agent touched
One revert – the whole run rolls back as a unit, in seconds
Agent access to production data
Without lakeFS
With lakeFS
A zero-copy branch per agent, per run – contained until explicitly merged
Reproducing an agent run
Without lakeFS
Logs show what the agent did, but the data state it saw is gone
With lakeFS
Every action is tied to an immutable commit – re-create any run with the same inputs
Controlling what lands in production
Without lakeFS
A human-in-the-loop prompt is a statement of intent, not a control
With lakeFS
Pre-merge hooks enforce quality, policy, and approval gates below the agent
When an agent makes a mistake
Without lakeFS
Manual, non-atomic recovery across every dataset the agent touched
With lakeFS
One revert – the whole run rolls back as a unit, in seconds
CAPABILITIES
Built for how agents actually work
Give every agent its own sandbox - without copying data ZERO-COPY BRANCHING
WHAT AGENTS NEED
A sandbox per agent, per run – with all the data and none of the risk. Copying petabytes per task is not an option.
HOW lakeFS HELPS
A branch is a pointer to a commit, not a copy. Branching a five-terabyte repository takes milliseconds and consumes no additional storage. Production patterns create millions of branches in a single run over data lakes measured in hundreds of petabytes – and branch protection keeps direct writes to main impossible, even with leaked credentials.
Let agents work on data natively - no new API, no MCP server lakeFS MOUNT
WHAT AGENTS NEED
File access to documents, images, audio, and video – without new protocols, SDKs, or integration work per agent framework.
HOW lakeFS HELPS
An agent mounts its branch as a local directory and does plain file I/O – glob, open, write – with no S3 client, no lakeFS API calls, and no MCP server required. The same agent code runs unchanged against a local folder. Data is fetched lazily as it is accessed, so even large repositories need no pre-loading. Teams that do run MCP-based stacks can still connect through standard protocols.
Give agents governed query access to tables ICEBERG REST CATALOG
WHAT AGENTS NEED
Query access to tables with the same isolation and audit trail as files.
HOW lakeFS HELPS
Tables and namespaces are versioned alongside files and folders. Agents query their branch with any standard Iceberg client – DuckDB, Spark, or Trino – and every table change is a versioned, committable, auditable change, same as a file modification.
Limit each agent to the data its task requires BRANCH-SCOPED CREDENTIALS + RBAC
WHAT AGENTS NEED
HOW lakeFS HELPS
Each agent operates with credentials confined to its own branch. Granular policies define what a given agent identity can read, write, commit, or merge – at the repository or object level. Sensitive repositories stay invisible to agents that do not need them.
Stop bad changes before they reach productionPRE-MERGE HOOKS
WHAT AGENTS NEED
A control a misbehaving or manipulated agent cannot skip. A human-in-the-loop instruction inside a prompt is a statement of intent, not a control.
HOW lakeFS HELPS
Rules run server-side before any branch merges into main: data quality checks, PII scans, policy validation, and a human-approval signal where required. The gate re-checks the data itself rather than trusting what the agent reported – a gate the agent cannot talk its way around, enforced below the agents.
FAQ’s
Do agents need to know about lakeFS?
No. With lakeFS Mount, a branch is just a path: the agent does plain file I/O – glob, open, write – with no S3 client, no lakeFS API, and no MCP server needed. Structured data is one Iceberg REST Catalog query away, and any tool that reads object storage works unmodified through the S3-compatible gateway.
Does lakeFS replace my existing data storage?
No. lakeFS sits between your existing object storage (AWS S3, Azure Blob, Google Cloud Storage, or any S3-compatible store) and the agents, tools, and users that consume it. Existing data stays in place – no migration, no copies.
How does this scale to thousands of concurrent agents?
A branch is a pointer to a commit, not a copy of the data, so creating one takes milliseconds regardless of repository size. Production patterns create millions of branches in a single run over data lakes measured in hundreds of petabytes, then collapse them when the run completes.
What about retrieval and RAG agents?
Retrieval state is a data state too. lakeFS versions the source corpus and the derived artifacts – the index and the embeddings – together, as one coherent state. Any retrieval answer can be tied back to the corpus version that produced it, and a poisoned or corrupted index can be rolled back.
How is this different from a compute sandbox?
A compute sandbox isolates where an agent runs, not what it does to your data. An agent in an isolated VM with unrestricted access to the data store can still cause irreversible damage. The two work together: isolated compute plus an isolated branch of the data.
How is this different from table time travel or observability?
Observability tells you what happened after the fact – it does not contain or reverse it. Table time travel can roll back a single table, but it does not understand that one agent run produced changes across several datasets that should be reverted as one unit. lakeFS does both: prevention before the write lands, and atomic rollback across everything a run touched.
Does it work for unstructured data?
Yes. lakeFS handles unstructured data (images, audio, video, documents), semi-structured data, columnar formats like Parquet, and open table formats including Iceberg, Delta, and Hudi – as one versioned, governed layer.
We already use lakeFS for ML - do we need a separate deployment for agents?
No. The same infrastructure that versions your training data handles agentic workloads. Governance rules and access controls for agent identities are additive to what is already in place.
Give your agents AI-ready data without giving up control
