How it works

One installation per company: its own database, storage, network and pool of workspaces. Nothing of one company's is reachable from another's.

Paid installations go into your Kubernetes with a Helm chart. Trials and Observation Mode run the same thing, hosted by us, single-tenant. The repository, the builds and the running app stay inside that installation.

A session is one unit of work: a contractor's ticket, or one agent run. It starts from a grant: a purpose, a set of files and a time box. A grant that touches an Absent path waits for a named approver before anything starts.

Occlude resolves the grant into a manifest that gives every path in the repository one of the four states, signs it, and starts a workspace. The workspace refuses a manifest that is unsigned or expired. When the grant ends or is revoked, the workspace closes.

Inside the workspace, the person's processes and the build's processes run as different users, each with its own view of the filesystem. The person's shell, editor and language server see Visible and Read-only files, plus generated declarations wherever their code imports an Occluded module. The compiler, test runner and dev server see the real repository, minus Absent paths.

The person starts a build by name: npm run dev, npm test. It runs on the build's side. The person cannot attach a debugger to it or see its processes. Its output comes back sanitised: a failure inside an Occluded module shows as a protected module, next to the line in the person's own file that called it.

Every file operation from the person's side is answered by one table. Nothing else decides.

Some paths are dangerous whatever the task, so every profile starts with them handled:

• Git history. It holds every version of every Occluded file. Git runs on the build's side, by name.
• Build output, coverage and source maps. Bundles carry Occluded code. The preview is served from the build's side.
• Package manifests and lockfiles are Read-only for contractors: whoever edits scripts decides what the build runs.
• Credentials, .env files and data seeds are Absent.
• Dependencies are Read-only: the language server needs their types, and nobody needs to edit them.

A door is any client attached to the person's side: the browser workspace, VS Code over SSH, an agent such as Claude Code, Codex or Cursor over MCP, or the agent that runs inside Occlude. All of them speak one protocol to the same workspace, so a file refused through one door is refused through every door, and the record is the same apart from the door's name.

Local mode, where a developer runs Occlude's bridge on their own machine, is outside this claim: whoever owns the machine owns the workspace. It is labelled unenforced everywhere, and an admin can forbid it per repository.

Every refused attempt is recorded with the rule that refused it, the process that asked, the path, the operation and the time. The record is append-only. An alert fires only on an actual attempt at an Occluded or Absent path, never on a guess, so it is worth reading.

At audit time, one export per session: the profile it ran under, every file touched, every refusal and which rule refused it. The export verifies itself.

The compiler must read Occluded files, so they are in the workspace's memory. The person's processes cannot read it: they run as a different user and cannot attach a debugger or open the build's memory. In the end the kernel holds that line, so the claim depends on the rung:

• runc, today. Separate users, a syscall filter, no debugger across the two sides, on the host's shared kernel. A kernel bug could cross that line, so the claim is compartmented, not exfiltration-proof.
• gVisor, before any session sold as a hardened boundary. A user-space kernel stands between the workspace and the host, so a kernel bug has far less to reach.
• Firecracker, for teams that ask for it. Hardware virtualisation per session.