Skip to content
orlop

What is orlop?

orlop is a multi-tenant, zero-trust file plane for agent sandboxes. It gives each untrusted AI agent its own durable, auto-expanding POSIX directory that the agent mounts over FUSE and uses like an ordinary disk. The bytes live remotely in a content-addressed chunk store, so the data outlives the sandbox and the next run for the same agent re-mounts the same disk with zero idle compute.

The problem it solves

Section titled “The problem it solves”

AI agents run in ephemeral, untrusted sandboxes. They need a place to keep working state — scratch files, tool outputs, datasets, and the raw transcripts a memory layer later indexes — that is durable, cheap to update, and safe under multi-tenancy. The usual options force a bad trade:

  • A local disk in the sandbox is fast but dies with the process.
  • A network filesystem or object bucket survives, but handing the agent a storage credential means one compromised agent can read or destroy every other tenant’s data.

orlop removes the trade-off: persistent, POSIX-shaped storage where the agent holds no credential that could reach the store directly.

How the zero-trust model works

Section titled “How the zero-trust model works”

The property that separates orlop from “wrap a network filesystem in a CLI” is that the agent never sees a storage credential:

  • Each agent is issued its own short-lived mTLS client certificate whose identity (a SPIFFE SAN) is the only thing that authorizes access.
  • The data-plane server confines every connection to that agent’s own path prefix, server-side.
  • A compromised agent therefore cannot read another tenant’s bytes, cannot widen its own path, and has no key it could exfiltrate to reach the store.

Architecture at a glance

Section titled “Architecture at a glance”

orlop is three pieces joined only by a wire protocol (mTLS + QUIC + msgpack):

Component Language Role
orlop-control Go Control plane: CA, auth, disk allocation, enroll, lease issuance
orlop-server Go Data plane: content-addressed chunk store, manifests, GC, mTLS
orlop Rust Mount client that runs inside the sandbox (FUSE/NFS)

The mount client is Rust because it sits on the hot path of every filesystem syscall inside the untrusted sandbox — no GC pauses, a small static binary, and a mature FUSE/NFS/QUIC ecosystem. The control and data planes are Go because they are network services where Go’s velocity and ecosystem shine.

Where orlop fits in an agent-memory stack

Section titled “Where orlop fits in an agent-memory stack”

orlop is the substrate, not the memory system. It stores bytes durably, deduplicates them by content hash, and isolates tenants — but it does no extraction, ranking, or semantic consolidation. A memory layer built on top gets durable storage that survives the sandbox, keeps the full raw trace cheaply, and can atomically overwrite a stale fact in place. See Agent memory for the full picture.

Next steps

Section titled “Next steps”