Security
Occlude is early. This page says what exists today, what does not, and what we will not claim. It changes as the product does.
What is built
- A browser development workspace that runs in isolated containers on infrastructure we control.
- An agent harness that runs tasks in that workspace, with review gates, checkpoints and a per-session record.
What is not built yet
- The occlusion layer itself: the four states and the boundary that enforces them.
- The hardened runtime on gVisor. Until it ships, the claim is compartmented, never exfiltration-proof.
- The door for external agents over MCP, and the door for VS Code over SSH.
- Observation Mode. The list on the home page is for the first cohort.
The memory-dump problem
The compiler must read occluded files, so they are in the runtime's memory. On a standard container a process can read its own address space via /proc/self/mem. Occlusion on a standard container is not enough against someone who can run code next to the build.
That is why the hardened tier is designed for gVisor, where /proc/self/mem does not exist, with the build and the person's shell under different users and ptrace denied between them. And it is why credentials and data seeds are never occluded. They are Absent: not in memory at all.
What we do not claim
- That a contractor cannot remember or re-derive what they legitimately saw.
- Protection against a collusive insider who holds full access.
- A zero-day-proof kernel boundary. We claim a hardened, monitored, logged one.
- That local bridge mode is secure against its own host's owner.
- That the agent cannot write bad code. We claim it cannot merge it past the gates unreviewed.
- Zero-trust, in any material, before the hardened runtime ships.
- That a declaration stub satisfies export-control law. Open question (§15).
Reporting a vulnerability
Write to the address below. We don't run a bounty yet. We will reply, and we will credit you if you want to be named.