Undisk MCP Blog

Connect Undisk to Any MCP Client in One Command

undisk-team — Tue, 14 Apr 2026 00:00:00 GMT

Undisk MCP works with every major AI coding client. One terminal command registers a versioned, reversible file workspace — and every write your agent makes from that point forward is automatically snapshotted and restorable.

This guide covers the three clients developers ask about most: Claude Desktop, OpenAI Codex, and Gemini CLI. If your client supports remote HTTP, you can skip the proxy entirely. Instructions for that are at the end.

Prerequisites

You need two things before running any of the setup commands below:

An Undisk API key — sign up at mcp.undisk.app and generate a key from the dashboard. It starts with sk_live_.
Node.js 18+ — the stdio proxy runs on Node. If you have npx available, you are good to go.

Claude Desktop

The fastest path. A single npx command configures everything:

npx @undisk-mcp/setup-claude

The setup script finds your claude_desktop_config.json, adds the Undisk server entry, and prompts for your API key. Restart Claude Desktop after running it, and the Undisk tools appear in the tool picker.

Under the hood, the script registers @undisk-mcp/stdio-proxy as a stdio-based MCP server with your key baked into the environment block.

OpenAI Codex

Codex has a built-in mcp add command. Pass the API key with --env so the proxy can authenticate:

codex mcp add undisk --env UNDISK_API_KEY=sk_live_YOUR_KEY -- npx -y @undisk-mcp/stdio-proxy

Replace sk_live_YOUR_KEY with your actual key. Codex stores the configuration locally and starts the proxy when you begin a session. You can verify it is registered by opening Settings → MCP Servers inside Codex.

To test, ask Codex to "list files in my Undisk workspace." If it calls list_files, you are connected.

Gemini CLI

Gemini CLI connects directly over HTTP — no proxy needed:

gemini mcp add --transport http --scope user -H 'Authorization: Bearer sk_live_YOUR_KEY' undisk https://mcp.undisk.app/v1/mcp

You can confirm the server is registered with:

gemini mcp list

Start a Gemini session and ask it to create a file. If Undisk tools show up in the tool list, the connection is live.

How the Stdio Proxy Works

Claude Desktop, Codex, and other clients that only support stdio expect MCP servers to communicate over stdin and stdout — the stdio transport. Undisk's server runs on Cloudflare's edge and speaks Streamable HTTP. Something needs to bridge the two.

Note: Gemini CLI supports HTTP transport natively, so it connects directly to Undisk without a proxy.

That bridge is @undisk-mcp/stdio-proxy. Here is what happens when your client sends a message:

The client writes a JSON-RPC message to stdin.
The proxy reads the line, parses it, and determines whether it is a request (has an id) or a notification (no id).
Requests are forwarded to https://mcp.undisk.app/mcp over HTTP with your API key in the headers. The server's JSON-RPC response is written back to stdout.
Notifications (like notifications/initialized) are forwarded but produce no response — the proxy stays silent, which is what the MCP spec requires.
Messages are processed serially through a promise queue to prevent race conditions on stdout.

The proxy is stateless. All workspace state lives on Undisk's edge servers. If the proxy crashes, restart it — nothing is lost.

Direct HTTP — No Proxy Needed

If your MCP client supports remote Streamable HTTP transport natively, you do not need the stdio proxy at all. Connect directly:

Setting	Value
URL	`https://mcp.undisk.app/mcp`
Auth header	`Authorization: Bearer sk_live_YOUR_KEY`
Alt header	`x-api-key: sk_live_YOUR_KEY`

Clients that support this today include GitHub Copilot, Cursor, Windsurf, and VS Code (via the MCP extension). For example, in VS Code's .vscode/mcp.json:

{
  "servers": {
    "undisk": {
      "type": "http",
      "url": "https://mcp.undisk.app/mcp",
      "headers": {
        "Authorization": "Bearer sk_live_YOUR_KEY"
      }
    }
  }
}

No proxy process, no npm install, no stdin/stdout — just HTTPS.

Verify Your Connection

Regardless of which client you use, the quickest way to verify the setup is working:

Ask the agent: "What Undisk tools do you have?" — it should list tools like write_file, read_file, list_versions, restore_version, and others.
Create a test file: Ask the agent to write a file called hello.txt with any content.
Check versions: Ask the agent to list versions of hello.txt. You should see at least one version with a timestamp and content hash.
Restore: Ask the agent to write hello.txt again with different content, then restore the first version. The original content should come back.

If all four steps work, you have a fully functional versioned workspace. Every file operation from here on creates an immutable snapshot — no extra configuration needed.

What You Get

Once connected, your agent has access to every Undisk MCP tool:

write_file / read_file — standard file operations, but every write creates a version
list_versions — see the full history of any file
restore_version — roll back a single file to any prior state in under 50 ms
diff_versions — see exactly what changed between two versions
search_files — full-text search across your workspace
list_files — browse the workspace directory tree
delete_file — soft-delete with version preservation

Every tool call is logged in a tamper-evident audit trail. You can inspect the history, attribute changes to specific agents, and prove compliance if you need to.

One command. Full undo. Every client.

Build a Personal Knowledge Base with GBrain + Undisk

undisk-team — Sun, 12 Apr 2026 00:00:00 GMT

Your AI agent is smart, but it starts from zero every conversation. A personal knowledge base fixes that — meetings, emails, research, and original ideas flow into a searchable brain that your agent reads before every response and writes to after every interaction. The agent compounds knowledge over time.

GBrain defines how to organize that knowledge. Undisk provides where to store it with safety guarantees. We cloned and adapted GBrain's organizational pattern into Undisk's built-in Brain template so teams can apply it in one call. Together, they create a production-grade personal AI brain with undo, audit trails, and multi-agent coordination.

Why Knowledge Bases Need Versioned Storage

Knowledge bases maintained by AI agents face a unique challenge: the agent writes thousands of files autonomously, and mistakes compound silently. A bad entity merge can corrupt hundreds of cross-references. An enrichment pipeline bug can overwrite compiled truth with hallucinated data. Without per-file versioning, recovery means manual reconstruction.

GBrain's native storage is a Git repository. Git works for human-paced editing, but it has fundamental limitations for AI agent workloads:

Granularity mismatch: Git commits bundle multiple file changes. Undoing one file means reverting the entire commit, losing every other change in that batch.
No surgical undo: git revert operates on commits, not individual file operations. If an agent modifies 50 entity pages in one enrichment pass and corrupts 3 of them, Git cannot restore just those 3.
Merge conflicts: Multiple agents writing to the same brain repository create merge conflicts that require manual resolution.
No audit trail: Git log shows who committed, but not which agent instance, which API key, or which session triggered the write.

Undisk solves all of these. Every write_file, create_file, append_log, and delete_file operation creates an immutable version. Any file can be restored to any prior state in under 50ms. The audit trail records every mutation with agent identity, timestamp, and content hash.

The Architecture: Two Complementary MCP Servers

┌──────────────────┐    ┌──────────────────┐    ┌──────────────────┐
│   Your Agent     │    │   Undisk MCP     │    │   GBrain MCP     │
│                  │    │                  │    │   (optional)     │
│  read brain      │───>│  versioned       │    │                  │
│  write pages     │───>│  file storage    │    │  hybrid search   │
│  search          │───>│  with undo       │    │  (vector +       │
│  checkpoint      │───>│                  │    │   keyword)       │
│  collaborate     │───>│  audit trail     │    │                  │
│  query           │───>│                  │───>│  entity detect   │
│                  │    │  24 MCP tools    │    │  enrichment      │
└──────────────────┘    └──────────────────┘    └──────────────────┘

Undisk handles all file operations — reads, writes, deletes, moves, search, versioning, undo, checkpoints, collaboration locks, secrets, and audit trail. This is the storage layer.

GBrain (optional) adds hybrid search with vector embeddings, entity detection, and enrichment pipelines. GBrain's gbrain query provides semantic search that goes beyond keyword matching. If you do not need vector search, Undisk's search_files tool handles regex and substring search across all workspace files.

Setting Up a Brain Workspace

Option 1: Use the Built-in Brain Template

Undisk ships a brain workspace template that scaffolds the full GBrain-recommended directory structure:

Your agent calls:
  workspace_checkpoint(action: "apply_template", template: "brain")

This creates:
  RESOLVER.md          — master decision tree for filing
  schema.md            — page conventions and templates
  people/README.md     — one page per human being
  companies/README.md  — one page per organization
  deals/README.md      — financial transactions
  meetings/README.md   — event records with transcripts
  projects/README.md   — things being actively built
  ideas/README.md      — raw possibilities
  concepts/README.md   — mental models and frameworks
  writing/README.md    — prose artifacts
  sources/README.md    — raw data imports
  inbox/README.md      — unsorted quick captures
  log.md               — chronological operation log

Each README.md is a resolver document that tells your agent exactly what belongs in that directory and what does not. The RESOLVER.md at the root is the primary decision tree — your agent reads it before creating any new page.

Unfolding Brain Into An Existing Workspace

You do not need a fresh workspace. The template is idempotent:

1. workspace_checkpoint(action: "create", name: "pre-brain-unfold")
2. workspace_checkpoint(action: "apply_template", template: "brain")
   -> Created 13 files
3. workspace_checkpoint(action: "apply_template", template: "brain")
   -> Skipped 13 (already exist)

This lets you add Brain structure to a workspace that already contains code, notes, or logs without overwriting those files.

Option 2: Manual Setup

Create the directories and resolver files yourself using create_file. The key files are:

RESOLVER.md — The decision tree. Your agent must read this before filing anything.
schema.md — Page template conventions: compiled truth above the line, timeline below.
Per-directory README.md — Local resolvers with positive definitions and disambiguation rules.

The Brain-Agent Loop on Undisk

The core pattern is simple: read before responding, write after every interaction.

Read Phase

1. Agent receives a question mentioning "Sarah Chen"
2. search_files(pattern: "Sarah Chen") → finds people/sarah-chen.md
3. read_file(path: "people/sarah-chen.md") → compiled truth + timeline
4. Agent responds with full context from the brain

Write Phase

1. Agent learns new information about Sarah during conversation
2. write_file(path: "people/sarah-chen.md") → updates compiled truth
3. append_log(path: "people/sarah-chen.md") → adds timeline entry
4. Both operations create immutable versions automatically

The Undo Safety Net

1. Enrichment pipeline runs overnight, touches 200 entity pages
2. Morning review reveals 3 pages have incorrect data
3. list_versions(path: "people/sarah-chen.md") → see all versions
4. restore_version(path: "people/sarah-chen.md", version_id: "...") → instant fix
5. The other 197 correct updates are untouched

Atomic Checkpoints

1. workspace_checkpoint(action: "create", name: "pre-bulk-import")
2. Agent imports 500 new pages from email archive
3. Something goes wrong — duplicates, bad entity resolution
4. workspace_checkpoint(action: "restore", checkpoint_id: "...")
5. Entire brain rolls back to pre-import state atomically

What Undisk Adds Over Git-Based Brain Storage

Capability	Git	Undisk
Per-file undo	❌ Requires full commit revert	✅ Any file, any version, <50ms
Tamper-evident audit	❌ Rebase rewrites history	✅ Hash-chain verified
Multi-agent writes	❌ Merge conflicts	✅ Immutable versions, no conflicts
Collaboration locks	❌ None	✅ File locks with auto-expiry
Agent handoff notes	❌ None	✅ Leave notes for other agents
Atomic checkpoint/restore	❌ Branch management	✅ Named snapshots, one-call restore
Secret management	❌ .gitignore or separate tool	✅ Encrypted vault (vault_secret)
Workspace search	❌ grep across checkout	✅ search_files with regex, case control
Activity context	❌ None	✅ Recent edits shown with tool responses

Best Practices for Brain Maintenance

Always read RESOLVER.md before creating pages. The resolver prevents duplicate pages and filing ambiguity. Include this rule in your agent's system prompt.
Use append_log for timeline entries. The timeline section of brain pages is append-only. Use append_log instead of rewriting the entire file — it is faster and creates a cleaner version history.
Checkpoint before bulk operations. Before importing email archives, running enrichment sweeps, or processing meeting transcripts, create a workspace_checkpoint. The cost is negligible; the safety is invaluable.
Use search_files before external APIs. Check the brain first. The answer may already be there, and it will be faster and more contextual than a web search.
Store API keys in vault_secret. Integration credentials (email, calendar, social media APIs) belong in the encrypted vault, not in brain files.
Use collaboration locks for multi-agent brains. If multiple agents write to the same brain, use workspace_collaborate to claim locks on files during enrichment passes.

Getting Started

Create an account at mcp.undisk.app and generate an API key
Initialize the brain — have your agent call workspace_checkpoint with action: "apply_template" and template: "brain"
Start writing — follow the compiled truth + timeline pattern for every entity page
Optionally add GBrain — install gbrain for hybrid search and enrichment pipelines

The brain compounds with every interaction. Start small, let the agent maintain it, and watch it become your most valuable AI infrastructure.

Undisk MCP joins E2B for Startups

undisk-team — Fri, 10 Apr 2026 00:00:00 GMT

We are incredibly excited to share that Undisk MCP has been accepted into the E2B for Startups program!

This is a massive milestone for us as we continue to build the ultimate undo-first versioned file workspace for AI agents. Along with the acceptance, we've received $20,000 in E2B compute credits and Pro Tier access.

E2B provides secure cloud sandboxes for agent code execution, making them the perfect partner for Undisk MCP. While E2B handles the secure compute environment, Undisk MCP provides the safe, reversible file storage layer. Together, we are providing the complete infrastructure stack for autonomous agents.

Storage + Compute for AI Agents

Agents execute code inside E2B sandboxes and persist files to Undisk MCP. Every write is versioned. Any bad write can be surgically undone without rolling back other files.

The Architecture Flow: Your Agent → E2B Sandbox → MCP → Undisk MCP Storage → Versioned Files + Tamper-evident Audit Trail

The Undisk MCP × E2B Live Demo

To celebrate this partnership and put our new compute credits to good use, we've launched a brand new interactive playground.

Head over to mcp.undisk.app/e2b to try our live sandboxed interactive demo.

What you can do in the demo:

Test Undisk MCP in real-time right from your browser.
No API key required! You can start experimenting instantly.
6-Step Guided Walkthrough: Watch a full write → break → diff → restore → audit cycle.
Lightning Fast: See firsthand how any file mutation can be surgically undone in under 50ms without affecting the rest of the workspace.
Full Audit Trail: Verify the SHA-256 hash-chained, tamper-evident audit log that makes Undisk MCP EU AI Act ready.

This demo runs securely inside an E2B cloud sandbox, proving how seamlessly Undisk MCP integrates with E2B's infrastructure to protect against hallucinating agents or rogue file operations.

We believe that giving an AI agent full file system access is reckless without a safety net. With Undisk MCP and E2B, you get the capability of autonomous execution with the human control of per-file undo.

Go try out the live terminal today, and let us know what you think!

How Undisk Versions Every Agent Write in <50ms

undisk-team — Tue, 07 Apr 2026 00:00:00 GMT

Undisk versions every file write at the MCP protocol layer, producing an immutable SHA-256 snapshot in under 50ms. No VM checkpoint, no full-environment rollback — surgical, per-file undo that preserves every other change your agent made.

This article explains the architecture that makes sub-50ms restores possible, why content-addressing matters for AI agent safety, and how to integrate Undisk into your MCP workflow.

Why Per-File Versioning Matters for AI Agents

Per-file versioning solves the core problem of AI agent file safety: recovering from a single bad write without losing everything else. AI agents write files constantly. They generate code, update configurations, produce reports, and modify data. When an agent makes a mistake — and they do, frequently — the standard recovery options are painful:

VM-level rollback destroys all progress since the last snapshot, not just the bad write
Git-based recovery requires the agent to have committed before the error
Manual intervention breaks the autonomous workflow entirely

Undisk solves this by versioning at the individual file level. Every write_file, create_file, or delete_file operation through MCP creates a new immutable version. Restoring a single file to any prior state takes under 50ms and leaves every other file untouched.

The Architecture: Durable Objects + R2

Undisk achieves sub-50ms versioning by combining Cloudflare Durable Objects for metadata with R2 for content storage, with an inline optimization that keeps most files in SQLite. Undisk runs on Cloudflare's global edge network using two storage primitives:

Durable Objects (DO) handle metadata and coordination. Each workspace gets its own DO instance with an embedded SQLite database. This database stores version pointers, file metadata, timestamps, and content hashes. With less than 1GB of metadata per workspace, the DO stays well within Cloudflare's 10GB limit per object.

R2 Object Storage holds the actual file content. R2 provides unlimited capacity with zero egress fees — a critical property when agents read files far more often than they write them.

The Inline Optimization

Files smaller than 128KB skip R2 entirely. They're stored directly in the DO's SQLite database, eliminating the network round-trip to R2. Since most source code files, configuration files, and small documents fall under this threshold, the majority of agent operations never leave the DO.

This tiered approach means the storage layer adapts to file size rather than treating every file the same way.

How a Write Operation Works

A write operation goes through six steps — from MCP request to versioned response — in under 50ms at the 95th percentile. Here is the step-by-step flow when an AI agent writes a file through Undisk:

Step 1: Receive the MCP Request

The agent sends a write_file tool call through the MCP Streamable HTTP transport. The request arrives at the nearest Cloudflare edge location — one of 300+ data centers globally.

Step 2: Route to the Workspace Durable Object

The gateway routes the request to the correct workspace DO based on the workspace ID. If the DO is hibernated (no recent activity), Cloudflare wakes it in single-digit milliseconds.

Step 3: Hash the Content

The DO computes a SHA-256 hash of the file content. This hash serves as the content address — if two files have identical content, they share the same hash and the same stored blob. This is the same content-addressing pattern used by Git and IPFS, and it is patent-free.

Step 4: Store the Blob

If this content hash is new (no existing blob matches), the file content is written to storage. Files under 128KB go into SQLite inline. Larger files go to R2.

If the hash already exists, no write is needed — the content is already stored. This deduplication happens automatically and saves both storage space and write latency.

Step 5: Create the Version Record

The DO inserts a new version record into its SQLite database. This record contains:

The file path
The content hash (pointer to the blob)
A monotonically increasing version number
The timestamp
The file size
The acting agent's identity

This version record is immutable. It cannot be modified or deleted through the API. The audit trail is tamper-evident by design.

Step 6: Return the Response

The DO returns the version metadata to the agent: the new version number, content hash, file size, and timestamp. Total elapsed time from request to response is typically under 50ms at the 95th percentile.

How a Restore Operation Works

Restoring a file creates a new version pointer to existing content — no data copying — making it faster than a write. Restoring a file is even simpler than writing one:

Step 1: Look Up the Target Version

The agent calls restore_version with a file path and version ID. The DO looks up the target version record in SQLite — a single indexed query.

Step 2: Create a New Version from the Old Content

The DO creates a new version record pointing to the same content hash as the target version. The file's current state now matches the restored version, but the restore itself is versioned. You can undo an undo.

Step 3: Return the Result

The agent receives confirmation with the new version metadata. The restore did not touch any other file in the workspace. No content was copied — only a new version pointer was created.

Content-Addressing and Deduplication

SHA-256 content-addressing gives Undisk automatic deduplication, integrity verification, and efficient diffing — all without extra configuration. The SHA-256 content-addressing scheme provides several properties that matter for AI agent workflows:

Deduplication: Agents frequently write the same content to the same file (idempotent operations, retries, regeneration). Content-addressing means these redundant writes consume zero additional storage.

Integrity verification: Any consumer of a file can verify its content against the stored hash. If the content does not match the hash, the file has been tampered with or corrupted.

Efficient diffing: The version history stores content hashes, not full copies. Comparing two versions starts with a hash comparison — if the hashes match, the versions are identical, and no byte-level diff is needed.

Concurrency and Scale

Each workspace DO handles approximately 1,000 requests per second. Cloudflare Durable Objects provide single-threaded consistency within a workspace, which simplifies concurrency guarantees for version ordering and content-addressing.

WebSocket hibernation eliminates duration charges during idle agent sessions. An agent can maintain a persistent connection to its workspace without incurring compute costs when no operations are in flight.

The Cost Structure

Infrastructure cost per workspace is under $0.05 per month at scale, yielding gross margins above 99% at a $10/workspace price point. The tiered storage architecture keeps infrastructure costs remarkably low:

At launch scale — 100 workspaces processing 500,000 operations per month — total infrastructure cost is approximately $6.34 per month. At 10x scale (1,000 workspaces, 5 million operations), the cost rises to roughly $41.44 per month, or about $0.04 per workspace.

At a price point of $10 per workspace per month, gross margins exceed 99%. The per-operation cost is dominated by Durable Object request charges ($0.15 per million requests), which remain negligible at any reasonable scale.

Why This Matters for Compliance

Undisk's version history is the audit trail — every operation creates an immutable record that satisfies EU AI Act Article 12 requirements by design. The EU AI Act (effective December 2, 2027 for deployers of high-risk systems) requires tamper-evident audit trails under Article 12. Every file operation recorded by Undisk — writes, deletes, restores, moves — creates an immutable version record that satisfies this requirement.

The version history is not a bolt-on feature. It is the storage model itself. You cannot write a file without creating a version. You cannot delete a version through the API. The audit trail is structural, not optional.

Getting Started

Any MCP client can use Undisk's versioning tools without special integration — connect and start writing. Undisk exposes its versioning through standard MCP tools. Any MCP client — Claude, Cursor, Windsurf, custom agents — can use these tools without special integration:

write_file / create_file — create content with automatic versioning
read_file — read current content with version metadata
list_versions — retrieve the complete version history for any file
restore_version — restore to any prior version in under 50ms
get_diff — compare any two versions line by line

Every tool call returns the version number and content hash, giving agents full visibility into the state of their workspace.

Summary

Undisk versions every agent write by combining Cloudflare Durable Objects (metadata + small files) with R2 (large file storage) and SHA-256 content-addressing (deduplication + integrity). The result is sub-50ms restores, surgical per-file undo, and a tamper-evident audit trail — all at infrastructure costs under $0.05 per workspace per month at scale.

The versioning is not a feature you enable. It is how the storage works.

Undisk MCP and EU AI Act Compliance

undisk-team — Tue, 07 Apr 2026 00:00:00 GMT

The EU AI Act is the world's first comprehensive AI regulation, and its record-keeping requirements apply to every organization deploying high-risk AI systems in the EU. This guide explains exactly which obligations affect teams using AI agents with file access, and how Undisk MCP's architecture maps to those requirements.

The short answer: Undisk does not make you compliant by itself. No single tool does. But its immutable versioning, structured audit trails, and configurable retention policies provide the technical foundation that Article 12 record-keeping and Article 26 deployer obligations demand.

What the EU AI Act Requires from Deployers

The EU AI Act creates obligations for multiple roles in the AI value chain — providers, deployers, importers, and distributors. Most organizations using AI agents with file access are deployers: they use an AI system provided by someone else (the model provider) in a professional context.

Deployer obligations under the EU AI Act are narrower than provider obligations, but they are real and enforceable. The relevant requirements for teams running AI agents with file access fall into three categories.

Article 12: Record-Keeping for High-Risk Systems

Article 12 requires that high-risk AI systems include logging capabilities that record events relevant to the system's functioning. These logs must be:

Automatic: generated without manual intervention during normal operation
Traceable: linked to specific inputs, outputs, and decisions
Retained: kept for a period appropriate to the system's risk level and intended purpose
Accessible: available for review by national competent authorities

For AI agents that read and write files — code generators, document processors, data pipelines — the "events relevant to functioning" include every file mutation the agent makes. Which files were created, modified, or deleted. When each operation occurred. What the content was before and after.

Without automatic logging of these operations, deployers cannot demonstrate compliance with Article 12 if a competent authority requests evidence of their AI system's behavior.

Article 26(5): Deployer Log Retention

Article 26(5) is explicit about deployer responsibilities for logs:

Deployers of high-risk AI systems shall keep the logs automatically generated by that high-risk AI system to the extent such logs are under their control, for a period appropriate to the intended purpose of the high-risk AI system, of at least six months, unless provided otherwise in applicable Union or national law.

Six months is the minimum. For many use cases — financial services, healthcare, legal — national regulations or industry standards require longer retention. The key phrase is "automatically generated" — you cannot rely on manual logging or after-the-fact reconstruction.

Article 26(6): Monitoring and Reporting

Article 26(6) requires deployers to monitor the operation of high-risk AI systems and report serious incidents to the provider and relevant authorities. Effective monitoring requires audit data that is:

Structured: machine-readable, not just free-text logs
Complete: covering all system operations, not just errors
Tamper-evident: demonstrably unmodified since creation

If an AI agent creates, modifies, or deletes files in your infrastructure, your monitoring and incident response capability depends on having a reliable record of exactly what changed, when, and by which agent.

How Undisk's Architecture Maps to These Requirements

Undisk MCP was designed with auditability as a core architectural principle, not an afterthought. Every file operation creates an immutable, content-addressed version with a complete audit trail. Here is how each architectural feature maps to specific EU AI Act obligations.

Immutable Versioning Satisfies Automatic Logging

Every file operation through Undisk's MCP interface — write_file, create_file, delete_file, move_file, restore_version — automatically creates a new version record. This happens at the storage layer, not the application layer. There is no way to mutate a file through Undisk without creating a version.

Each version record includes:

Timestamp: when the operation occurred (ISO 8601, millisecond precision)
Agent identity: which MCP client performed the operation
Operation type: write, delete, move, or restore
File path: the full workspace-relative path
Content hash: SHA-256 hash of the file content before and after the operation
File size: in bytes, before and after
Version ID: a unique, sequential identifier for ordering

This directly satisfies Article 12's requirement for automatic, traceable logging of events relevant to the system's functioning. The logs are generated by the system itself during normal operation — no additional instrumentation is required.

Content-Addressed Storage Provides Tamper Evidence

Undisk uses content-addressed storage with SHA-256 hashes. Every version record includes the hash of the file content at that point in time. If any version record were modified after creation, the hash would no longer match the stored content, making tampering detectable.

This is critical for regulatory credibility. When a competent authority reviews your audit trail, they need confidence that the records reflect what actually happened, not what someone edited the records to say happened. Content-addressed hashing provides this guarantee mathematically — it is the same integrity mechanism used by Git, IPFS, and blockchain systems.

For Article 26(6) monitoring and incident response, tamper-evident logs mean that if an AI agent causes a serious incident, your audit trail is trustworthy evidence of exactly what the agent did and when.

Configurable Retention Meets the Six-Month Minimum

Undisk supports configurable retention policies that can be set per workspace. The default retention period is 180 days (six months), which matches the Article 26(5) minimum. Enterprise customers can configure longer retention periods to meet industry-specific requirements.

Retention configuration is itself auditable — changes to retention policy are logged, creating a chain of evidence that demonstrates compliance with retention obligations over time.

Structured Data Enables Machine-Readable Reporting

Undisk's version history is not a text log file. It is structured data with typed fields, queryable through the list_versions MCP tool and the web file browser's version history interface. This means:

Automated monitoring: scripts and observability tools can query version history programmatically
Incident investigation: filter operations by time range, agent identity, file path, or operation type
Compliance reporting: generate structured reports that map directly to regulatory requirements
Authority requests: respond to competent authority inquiries with complete, machine-readable evidence

Article 26(6) requires deployers to monitor high-risk AI system operations. Structured, queryable audit data makes this monitoring practical rather than theoretical.

The GDPR and EU AI Act Tension

Organizations operating in the EU face a well-known tension between two regulations. The EU AI Act requires retaining audit logs for at least six months. GDPR requires deleting personal data when it is no longer necessary for its original purpose. Audit logs may contain personal data — user identities, agent identities, file paths that include names or other identifying information.

How Undisk Resolves This

Undisk addresses this tension with a layered retention architecture designed to satisfy both regulations simultaneously.

Layer 1 — Operational logs: Full audit logs with all identifiers are retained for the active retention period. This period is configurable per workspace, with a default of 180 days. During this period, all data is available for operational monitoring, incident investigation, and immediate compliance needs.

Layer 2 — Compliance archive: After the operational period, personal data in audit logs is pseudonymized. User IDs are replaced with cryptographic hashes. File paths containing identifying information are redacted. The pseudonymized records are retained for the extended compliance period (configurable up to 10 years) to satisfy EU AI Act long-term audit trail requirements.

Layer 3 — Permanent deletion: After the compliance archive period, all records — including pseudonymized versions — are permanently deleted. No data survives beyond the defined retention window.

This layered approach satisfies GDPR's data minimization principle (Article 5(1)(c)) by reducing the personal data footprint over time, while maintaining the audit trail that the EU AI Act requires. The European Data Protection Board has acknowledged that pseudonymized data can satisfy record-keeping obligations while respecting data protection rights, provided the pseudonymization is technically robust.

Practical Implementation: What Deployers Should Do Now

The EU AI Act deployer obligations for high-risk systems apply from December 2, 2027 (extended from August 2026 under the Digital Omnibus amendment). If your organization runs AI agents that access files — code generation tools, document processors, automated data pipelines — you should begin preparing now. Here is a practical checklist.

Step 1: Classify Your AI Systems

Determine which of your AI agent deployments qualify as high-risk under Annex III of the EU AI Act. Systems used in critical infrastructure, education, employment, law enforcement, and several other domains are classified as high-risk. General-purpose AI agents that write files may fall under high-risk classification depending on their domain of use.

Not all AI agent deployments are high-risk. But even for non-high-risk systems, maintaining audit trails is a best practice that simplifies compliance if classification changes or if a competent authority investigates an incident.

Step 2: Audit Your Current Logging

Review what your AI agents currently log when they perform file operations. Common gaps include:

No logging at all: the agent reads and writes files directly to a filesystem with no audit trail
Application-level logging only: the agent's application code logs operations, but the logs are mutable and deletable
Incomplete logging: some operations are logged but deletions, moves, or overwrites are not captured
No content hashing: logs record that a write occurred, but not what was written or overwritten

If any of these gaps exist, you cannot demonstrate Article 12 compliance for those operations. Undisk eliminates all four gaps by logging at the storage layer with content hashing.

Step 3: Establish Retention Policies

Define retention periods that satisfy both your EU AI Act obligations (minimum six months) and any industry-specific requirements. Document the rationale for your chosen retention periods — competent authorities may ask why you chose a specific duration.

Configure your retention policies well before December 2027, not after. Retroactive compliance is not possible for audit trail requirements — you cannot reconstruct logs for operations that were never logged.

Step 4: Implement Tamper-Evident Logging

Ensure your audit trail is tamper-evident. Text log files on a shared filesystem do not meet this standard — anyone with write access can modify them. Content-addressed storage with cryptographic hashing (as Undisk provides) establishes a verifiable chain of evidence.

Step 5: Plan for Cross-Border Data Flows

If your AI agents process data across EU borders, ensure your audit trail infrastructure supports EU data residency requirements. Undisk supports R2 location hints for data residency configuration, allowing enterprise customers to keep files and audit logs within EU jurisdiction.

Who This Affects

The EU AI Act's record-keeping obligations affect a broad range of organizations. You are likely a deployer under the regulation if you:

Use AI coding assistants that generate or modify source code files
Run AI agents that process customer documents, contracts, or correspondence
Operate automated data pipelines that transform, merge, or create data files
Deploy AI tools that generate reports, presentations, or other business documents
Use AI agents for content moderation that involves file-level decisions

In each case, the AI agent is performing file operations that the EU AI Act considers "events relevant to functioning." Without automatic, structured, tamper-evident logging of these operations, demonstrating compliance is difficult or impossible.

High-Risk vs General-Purpose

Not every AI agent deployment is high-risk. The EU AI Act's strictest obligations (Articles 6–27) apply specifically to high-risk systems as defined in Annex III. However, there are three reasons to implement comprehensive audit trails even for non-high-risk deployments:

Reclassification risk: The European Commission can update the high-risk classification list. An agent deployment that is general-purpose today may be classified as high-risk tomorrow.
Incident response: Even for non-high-risk systems, the EU AI Act requires reporting serious incidents. You need audit data to investigate and report effectively.
Contractual obligations: Enterprise customers increasingly require audit trail capabilities in vendor contracts, regardless of the AI system's risk classification.

Undisk vs Alternative Approaches

Organizations have several options for meeting EU AI Act audit trail requirements. Here is how Undisk compares to common alternatives.

Application-Level Logging

Many teams add logging calls to their AI agent code: "log that we wrote file X at time T." This approach has fundamental limitations:

Mutable: application logs stored on disk can be edited or deleted
Incomplete: developers must remember to log every operation — missed operations create gaps
Unverified: logs record what the code claims happened, not what actually happened at the storage level
No content hashing: logs typically record that a write occurred but not the before/after content

Undisk logs at the storage layer, below the application. Every file mutation creates a version regardless of whether the application code remembered to log it. Content hashing verifies what was actually written, not what the application claimed was written.

Git-Based Versioning

Git provides excellent versioning for source code, but it was not designed for real-time AI agent file operations:

Batch commits, not per-operation: Git versions are created by explicit commit commands, not automatically on every write
No real-time logging: agents would need to commit after every file operation, which is impractical at agent speeds
Repository-level operations: checking out a prior version affects the entire repository, not individual files
No structured audit trail: Git log provides commit messages and diffs, but not structured, queryable audit data with agent identity and policy evaluation results

Undisk versions every individual file operation in real-time with structured metadata. Restoring a single file does not affect any other file in the workspace.

VM/Sandbox Snapshots

Platforms like Fly.io Sprites and Blaxel offer VM-level snapshots. While these provide a form of versioning, they do not meet EU AI Act record-keeping requirements effectively:

Coarse granularity: snapshots capture the entire VM state, not individual file operations
No per-operation logging: a snapshot records a point-in-time state, not the sequence of operations that led to it
Restore destroys progress: reverting to a prior snapshot rolls back everything, including files that were correct
No structured audit data: snapshots do not record which agent performed which operations

Timeline: What Deployers Need to Know

Date	Milestone
August 1, 2024	EU AI Act entered into force
February 2, 2025	Prohibited AI practices took effect
August 2, 2025	Governance rules and obligations for general-purpose AI models apply
December 2, 2027	Deployer obligations for high-risk stand-alone AI systems apply (Annex III, extended via Digital Omnibus)
August 2, 2028	Obligations for high-risk AI embedded in regulated products apply (Annex I)

The December 2027 deadline is the most relevant for organizations deploying AI agents with file access. Deployer obligations — including Article 26(5) log retention — become enforceable on that date. Organizations that have not implemented automatic, structured audit trails by then will be non-compliant from day one.

Summary

The EU AI Act creates specific, enforceable obligations for organizations deploying AI agents that access files. Article 12 requires automatic record-keeping. Article 26(5) requires at least six months of log retention. Article 26(6) requires effective monitoring capabilities.

Undisk MCP addresses these obligations through its core architecture: every file operation creates an immutable version with a content-addressed hash, structured metadata, and configurable retention. The audit trail is automatic, tamper-evident, and structured for machine-readable querying.

No single tool makes you EU AI Act compliant. But without automatic, tamper-evident audit trails for your AI agent file operations, compliance with Article 12 and Article 26 is practically impossible. Undisk provides the infrastructure layer that makes it achievable.

Undisk vs E2B for Agent File Access

undisk-team — Tue, 07 Apr 2026 00:00:00 GMT

Undisk and E2B solve different problems for AI agents, but they appear side-by-side in platform engineering evaluations. This article provides an honest, data-backed comparison so you can decide which to use — or whether to use both.

The short answer: E2B gives your agents a place to run code. Undisk gives your agents a place to store files safely. If you need both, they work well together.

What E2B Does

E2B provides cloud-based sandboxes for AI agent code execution. Built on Firecracker microVMs, each E2B sandbox is an isolated Linux environment where agents can run Python, JavaScript, shell commands, and other code. Perplexity, Hugging Face, Vercel, and Cursor all use E2B for their AI-powered code execution features.

E2B's strengths are clear: fast sandbox provisioning, strong isolation via microVMs, and excellent SDKs for Python and TypeScript. If your agent needs to execute code in a safe, isolated environment, E2B is a strong choice.

E2B sandboxes are ephemeral by default. When a sandbox is destroyed, its filesystem is gone. There is no built-in file versioning, no undo for file operations, and no audit trail of what the agent wrote or modified.

What Undisk Does

Undisk is a file workspace built specifically for MCP-compatible AI agents. Every file operation — write, create, delete, move — creates an immutable, content-addressed version. Any file can be restored to any prior state in under 50ms. Every mutation is logged with timestamps, agent identity, and content hashes.

Undisk does not execute code. It does not manage containers or VMs. It is purpose-built for one thing: making AI agent file operations safe, reversible, and auditable.

Feature Comparison

Where Undisk Leads

Per-File Versioning with Undo

Undisk versions every file mutation automatically. Every write_file, create_file, or delete_file call through MCP creates an immutable version with a SHA-256 content hash. Restoring a single file to any prior state takes under 50ms and leaves every other file in the workspace untouched.

E2B has no file versioning at all. If an agent overwrites a file in an E2B sandbox, the previous content is gone. The only recovery option is to destroy the sandbox entirely and start over — losing all progress on every other file.

This difference matters because AI agents make mistakes frequently. When 66% of developers say AI output is "almost right but not quite," surgical undo becomes essential. Rolling back one bad file should not destroy twenty good ones.

Structured Audit Trails

Undisk records every file operation with timestamps, agent identity, operation type, file path, content hash before and after, and policy evaluation results. These logs are append-only, content-addressed, and retained per configurable policy (default 180 days).

E2B provides no audit trail for file operations. There is no log of which files were written, what they contained, or when operations occurred. For teams that need to review, audit, or comply with regulatory requirements, this is a significant gap.

Scoped File Permissions

Undisk supports path-level access control lists. You can grant an agent read-write access to /output/ while restricting /config/ to read-only and blocking /secrets/ entirely. Policies are versioned, auditable, and support glob patterns.

E2B's isolation is at the sandbox level. Within a sandbox, the agent has full filesystem access. There is no mechanism to restrict access to specific paths or files within the sandbox environment.

EU AI Act Compliance Primitives

Undisk's tamper-evident audit logs, configurable retention, and content-addressed versioning directly enable EU AI Act Article 12 record-keeping requirements. The compliance deadline for deployers of high-risk AI systems is December 2, 2027.

E2B has no compliance-specific features. No audit trails, no retention policies, no tamper-evident logging.

Where E2B Leads

Code Execution

E2B's primary feature is sandboxed code execution. Agents can run Python, JavaScript, shell scripts, and other languages in isolated Firecracker microVMs. This is E2B's core value proposition, and it does it well.

Undisk does not execute code. It is a file workspace, not a sandbox. If your agents need to run code, E2B (or Fly.io Sprites, Daytona, or Blaxel) is the right tool.

Sandbox Isolation

E2B provides full operating system-level isolation via Firecracker microVMs. Each sandbox has its own kernel, filesystem, network stack, and process space. This isolation model is ideal for running untrusted or agent-generated code.

Undisk isolates at the workspace level using Cloudflare Durable Objects. This provides strong data isolation but does not include process isolation since there are no processes to isolate — Undisk does not execute code.

Ecosystem Integrations

E2B has mature integrations with LangChain, OpenAI Agents SDK, CrewAI, and other agent frameworks. It is used by Perplexity, Hugging Face, Vercel, and Cursor in production. The SDK ergonomics are excellent — typically 3–5 lines to integrate.

Undisk is newer and has a smaller integration ecosystem. It speaks standard MCP, so any MCP-compatible client can use it, but framework-specific integrations are still developing.

When to Use Both

The strongest architecture for production AI agents combines E2B for compute with Undisk for persistent file storage:

Agent code runs in E2B — isolated execution with full Linux capabilities
Agent file outputs persist in Undisk — versioned, auditable, restorable
If the agent makes a bad write — restore the file in Undisk without destroying the E2B sandbox
When compliance reviews happen — export the audit trail from Undisk showing every file mutation

This is not a theoretical pattern. Any team running AI agents in production faces both problems: "where does the code run safely?" (E2B's answer) and "where do the files live safely?" (Undisk's answer).

The Bottom Line

E2B and Undisk are complementary tools solving different problems. E2B gives agents a safe place to execute code. Undisk gives agents a safe place to store files with full versioning, undo, and audit trails.

If you need code execution, choose E2B. If you need reversible file operations with compliance-grade audit trails, choose Undisk. If you need both — and most production AI platforms do — use them together.

Frequently Asked Questions

Undisk vs Fly.io Sprites: File vs VM Rollback

undisk-team — Tue, 07 Apr 2026 00:00:00 GMT

Undisk and Fly.io Sprites both address the problem of recovering from AI agent mistakes, but they operate at fundamentally different levels. Sprites checkpoints entire virtual machines. Undisk versions individual files. This difference in granularity shapes every aspect of the recovery experience.

The core tradeoff: Sprites gives you a full Linux environment with VM-level rollback. Undisk gives you a file workspace with surgical, per-file undo. Which you need depends on whether you need to restore environments or restore files.

What Fly.io Sprites Does

Fly.io Sprites provides persistent, stateful Linux microVMs built on Firecracker. Each Sprite is a full Linux environment with NVMe-backed ext4 storage (100GB+), an init system, and network access. Sprites can be checkpointed — their entire state (memory, filesystem, processes) is captured incrementally in approximately 300ms. Restoring a checkpoint brings the entire VM back to that exact state.

Sprites also support scale-to-zero. When a Sprite is idle, it hibernates and stops incurring compute charges. Resume from hibernation is fast, making Sprites cost-effective for intermittent workloads.

The key characteristic of Sprites' recovery model is that it operates at the VM level. A checkpoint captures everything. A restore restores everything. There is no way to restore individual files, undo specific operations, or keep some changes while reverting others.

What Undisk Does

Undisk is a file workspace built for MCP-compatible AI agents. Every file operation creates an immutable, content-addressed version. Restoring a single file to any prior state takes under 50ms. Every mutation is logged with agent identity, timestamps, content hashes, and policy evaluation results.

Undisk does not provide a Linux environment, does not execute code, and does not manage VMs or containers. It is purpose-built for making file operations safe, reversible, and auditable.

Feature Comparison

The Granularity Problem

The fundamental difference between Undisk and Sprites is rollback granularity. This difference compounds across every aspect of the recovery experience.

Scenario: Agent Makes 20 File Changes, File 15 Is Wrong

With Sprites: You restore the most recent checkpoint before file 15 was written. This also rolls back files 16 through 20 — five good changes destroyed alongside the one bad one. If the checkpoint was taken before file 1, you lose all 20 files of progress. The agent must redo files 15 through 20 from scratch.

With Undisk: You call restore_version on file 15, specifying the version before the bad write. File 15 reverts to its prior state. Files 1 through 14 and files 16 through 20 are completely unaffected. Total recovery time: under 50ms. Total work lost: zero (except the bad write itself).

This is the difference between using Ctrl+Z on one document versus factory-resetting your entire computer. Both technically "undo" a mistake, but the collateral damage is vastly different.

Scenario: Agent Corrupts a Config File at 2 AM

With Sprites: You need to identify which checkpoint predates the corruption, restore the entire VM to that state, then manually re-apply any legitimate changes that happened after the checkpoint. If checkpoints are infrequent, the data loss window could be hours.

With Undisk: You call list_versions on the config file, identify the last good version by its timestamp and content hash, and restore it. No other file is affected. The agent can continue working immediately.

Where Undisk Leads

Surgical Recovery

Undisk's per-file versioning means recovery is always surgical. You restore exactly what needs restoring and nothing else. Every file has its own independent version history, and restoring one file never affects another.

Sprites cannot achieve this. VM-level checkpoints are inherently all-or-nothing. The entire VM state — filesystem, processes, memory — is treated as a single unit. There is no mechanism to selectively restore parts of a checkpoint.

Structured Audit Trails

Undisk records every file operation with full metadata: agent identity, operation type, file path, content hash, timestamp, and policy evaluation result. These logs are append-only, content-addressed (tamper-evident), and retained per configurable policy.

Sprites provides no file-level audit trail. Checkpoints record VM state, but they do not track which files changed between checkpoints, what the changes contained, or which agent made them. For compliance, review, or debugging purposes, this information gap is significant.

Restore Performance

Undisk per-file restore completes in under 50ms. The operation looks up a version record in SQLite, retrieves the content (inline from SQLite for files under 128 KB, or from R2 for larger files), and writes it as a new version. The simplicity of restoring a single file versus reconstructing a full VM state explains the 6x performance advantage.

Sprites checkpoint restore takes approximately 300ms. This is fast for a full VM restore — impressive, even — but it is slower than Undisk's file-level operation by a significant margin.

MCP Native

Undisk speaks MCP natively. Any MCP client — Claude, Cursor, Windsurf, or custom agents — can use Undisk's file tools (write_file, read_file, list_versions, restore_version, get_diff) without special integration.

Sprites does not implement MCP. Integration requires building a bridge between MCP tool calls and Sprites' REST API — additional code to write, test, and maintain.

Where Sprites Leads

Full Linux Environment

Sprites provides a complete Linux environment with NVMe-backed storage, an init system, network access, and support for arbitrary software. Agents can install packages, run services, execute complex build pipelines, and interact with databases.

Undisk is a file workspace only. It provides file CRUD operations (read, write, delete, list, search, move) with versioning, but it does not execute code or provide a Linux environment. If your agent needs to run code, Sprites gives it a full machine to work with.

Large Storage Capacity

Sprites offers 100GB+ of NVMe-backed ext4 storage per VM. For workloads involving large datasets, media files, or extensive build artifacts, this capacity is significant.

Undisk's storage is backed by Cloudflare Durable Objects and R2, with per-file size limits (256 MB) and per-workspace storage quotas defined by tier. For most AI agent file workloads this is more than sufficient, but Sprites offers more raw capacity.

Process State Recovery

Sprites checkpoints capture not just the filesystem but the entire VM state — running processes, memory contents, network connections. Restoring a checkpoint brings the VM back to an exact running state, including all in-flight computations.

Undisk versions files only. It does not capture process state, memory, or any runtime context. If your recovery scenario requires restoring a running environment (not just files), Sprites is the right tool.

When to Use Both

The strongest architecture for production AI agents pairs Sprites for compute with Undisk for file persistence:

Agent runs inside a Sprite — full Linux environment with code execution capabilities
Agent stores files through Undisk — every write versioned, auditable, restorable
Bad file write happens — restore the file in Undisk in under 50ms, Sprite continues running
VM crashes or corrupts — Sprite checkpoint restores the environment; Undisk's file versions are unaffected because they live outside the VM
Compliance review — Undisk provides the full audit trail of every file operation

This separation of concerns — compute in Sprites, storage in Undisk — eliminates the granularity problem entirely. You get full Linux capabilities from Sprites and surgical file recovery from Undisk.

The Bottom Line

Sprites and Undisk solve recovery at different levels. Sprites restores entire environments. Undisk restores individual files. The right choice depends on what you need to recover:

Need to restore a running environment — choose Sprites
Need to undo a single file change — choose Undisk
Need both — run agents in Sprites, store files in Undisk

For AI agent file safety specifically — the ability to undo bad writes without losing other work — Undisk's per-file versioning is the more precise tool. For full environment recovery including process state, Sprites' VM checkpoints are unmatched.

Frequently Asked Questions

Why AI Agents Need Undo

undisk-team — Mon, 06 Apr 2026 00:00:00 GMT

AI agents that write files need undo. Not eventually, not as a nice-to-have — as a fundamental primitive. Without per-file reversibility, every autonomous write is a one-way door that developers cannot safely walk through.

This article explains why irreversible file operations are the primary blocker preventing teams from granting agents write access, what the current alternatives get wrong, and how per-file versioning changes the equation.

The Trust Crisis in AI-Assisted Development

Developer trust in AI-generated code is declining, not growing — and that trust gap directly blocks autonomous file access. The numbers tell a clear story. In 2025, 84% of developers use AI coding tools, but only 33% trust the accuracy of AI-generated output — down from 40% the year before. Only 3% report "high trust." Two-thirds of developers say AI output is "almost right but not quite," and 45% find that debugging AI-generated code takes longer than writing it manually.

Developer sentiment toward AI tools dropped from above 70% positive in 2023–2024 to 60% in 2025. The honeymoon is over. Developers have learned that AI agents are powerful but unreliable — capable of impressive output and catastrophic mistakes in the same session.

This trust gap has a direct consequence for file operations: developers refuse to grant autonomous write access to tools they do not trust. And without write access, AI agents cannot do the work they were built for.

Why Current Recovery Options Fail

When an AI agent makes a bad write, teams have three recovery paths — none of which actually work:

VM-Level Rollback

Platforms like Fly.io Sprites offer VM checkpoint and restore. The agent's entire environment is snapshotted periodically, and you can roll back to a previous checkpoint. The restore takes roughly 300ms.

The problem: rolling back a VM destroys everything since the checkpoint. If the agent made 50 good changes and 1 bad change, you lose all 50. For agents that work on multiple files in parallel — which is most real-world use cases — VM rollback is a sledgehammer where you need a scalpel.

Git-Based Recovery

Some teams configure agents to commit frequently to Git. In theory, this provides a history of every change. In practice, agents rarely commit at useful granularity. They either commit too often (creating noise) or too rarely (leaving gaps). And Git's undo model — git revert, git reset, git checkout — operates on commits, not individual file operations. You cannot undo a single file write without also undoing every other change in that commit.

Manual Intervention

The fallback: a human watches the agent, catches mistakes, and manually fixes them. This defeats the entire purpose of autonomous agents. If a human must supervise every write, the agent is not autonomous — it is an autocomplete with extra steps.

The Irreversibility Problem

Standard file systems treat every write as permanent — there is no built-in undo. The core issue is that file writes are irreversible by default. When an agent calls write_file on a standard filesystem, the previous content is overwritten. Gone. If no one made a backup — and in an autonomous agent workflow, no one did — the data is lost.

This is not a theoretical risk. It happens constantly:

An agent refactoring code overwrites a file with a version that compiles but has a subtle logic error
An agent updating a configuration file removes a critical section it did not understand
An agent generating a report clobbers the previous version that contained manually verified data
An agent working on one task accidentally modifies a file belonging to a different task

Each of these scenarios is recoverable if every write creates a version. Without versioning, each is a potential data loss event that erodes the trust developers need to let agents work autonomously.

What Per-File Versioning Changes

Per-file versioning transforms write access from a high-risk permission into a routine one by making every change reversible. Per-file versioning means every write operation — write_file, create_file, delete_file — automatically creates an immutable snapshot of the file's state. No explicit save, no manual commit, no agent cooperation required. The versioning is structural, not behavioral.

This changes the agent permission model fundamentally:

Before: "Should I let this agent write to my files?" → Only if I am watching and can catch mistakes in real time.

After: "Should I let this agent write to my files?" → Yes, because any write can be undone in under 50ms without affecting anything else.

The undo capability transforms write access from a high-risk permission into a routine one. Developers can grant agents write access with confidence because the worst case is a quick restore, not permanent data loss.

The Compliance Dimension

The EU AI Act makes reversible AI operations a legal requirement by December 2027, with penalties up to €35 million. Beyond developer trust, regulatory requirements are making reversible AI operations mandatory.

The EU AI Act, effective December 2, 2027 for deployers of high-risk systems, establishes two requirements that directly apply to AI agent file operations:

Article 12 — Record-Keeping: Deployers must maintain tamper-evident audit trails of AI system operations for a minimum of six months. Every file operation — writes, reads, deletes, restores — must be logged in a way that cannot be retroactively modified.

Article 14 — Human Oversight: Deployers must maintain the ability to reverse AI outputs. If an AI system produces a file, a human must be able to undo that action. This is not a suggestion — it is a legal mandate with penalties of up to €35 million or 7% of global annual turnover for non-compliance.

Per-file versioning with immutable audit logs satisfies both requirements structurally. The version history is the audit trail. The restore operation is the human oversight mechanism. Compliance is not a feature bolted on after the fact — it is a property of how the storage works.

The Market Gap

No existing platform combines per-file versioning with MCP protocol support — the gap is architectural, not incremental. The current AI infrastructure landscape offers no solution that combines per-file versioning with MCP protocol support:

Sandbox compute platforms (E2B, Modal, Daytona) provide isolated execution environments but no file versioning. Files written inside a sandbox are ephemeral or snapshot-based.

VM orchestrators (Fly.io Sprites) offer checkpoint/restore at the VM level. Granularity is entire-environment, not per-file. Restore latency is approximately 300ms, and the operation destroys all changes since the checkpoint.

The MCP Reference Filesystem Server provides local-only file access with no versioning, no remote deployment, and no audit trail.

None of these platforms version individual file operations at the MCP protocol layer. The gap is not incremental — it is architectural. Adding per-file versioning to a platform designed around VMs or sandboxes requires rethinking the entire storage model.

What Developers Actually Need

Developers need a file workspace that versions every write automatically, restores in under a second, and works with any MCP client — without custom SDKs. Based on the trust data and the compliance landscape, developers need a file workspace for AI agents that provides:

Automatic versioning: Every write creates a version without agent cooperation
Surgical undo: Restore any single file without affecting other files
Sub-second restore: Fast enough for real-time agent workflows
Immutable audit trail: Tamper-evident log of every operation
MCP-native integration: Works with any MCP client without custom SDKs
Edge-native performance: Low latency globally, not just in one region

This is the design space Undisk occupies. Every file operation through Undisk MCP creates an immutable, content-addressed version. Restoring any file to any prior state takes under 50ms. The audit trail is structural — you cannot write a file without creating a version record.

The Path Forward

As the MCP ecosystem scales past 97 million monthly SDK downloads, the reversibility gap will become the primary adoption blocker for autonomous agent file operations. The MCP ecosystem is growing rapidly: 97 million monthly SDK downloads, over 8,600 public MCP servers, and 4x growth in production deployments between May and October 2025. The Linux Foundation's adoption of MCP in December 2025 removed the "what if MCP dies?" objection.

As agents move from code completion to autonomous file operations, the reversibility gap will become the primary adoption blocker. Teams that solve the undo problem will unlock the next generation of agent capabilities. Teams that ignore it will lose developer trust — and potentially face regulatory consequences.

AI agents need undo. Not as an afterthought, but as a first-class primitive that is built into the storage layer from day one.