How Does an Agentic Data Enclave Work?

This is the mechanism behind the Agentic Data Enclave, the first enterprise use case of WunderOS. Read that page for what the enclave is and why it is needed. This page is how it actually works.

The one fact everything rests on

In WunderOS, memory is a service of the operating system, not something held exclusively inside the agent. The visiting agent does not own its memory of your data. The enclave does.

Everything below follows from that simple fact. If memory lived in the agent, the agent would leave with it and you could not govern what it took. Because memory lives in the enclave, you get to govern and curate exactly what the visit is allowed to remember. Hold that one fact since the rest of the mechanism is all the consequences that come from it.

Stage one: you stand up the enclave

The data owner, that is, the enterprise (or line of business, department, etc) establishes the data enclave before any agent arrives. You decide what data exists inside it, who may authorize access to what, and what the boundary will let out. All of which operates next to your data inside your VPC. WunderOS does not supply the agents; rather it supplies their environment, necessary services, and your governance and curation leverage. It supplies the enclave. Bring any agent, a partner’s agent, a vendor’s agent, a workload in a microVM, and the autonomic operating system gives it access to your data (that is, to the subset of data you’ve determined is fitting) and governs everything it does subsequently.

Stage two: the agent comes to the data

The cloud era moved enterprise data to where the computation was, that is, to the cloud. The agentic data enclave inverts that rule. It moves the computation to the data. That is, to permit actual data sovereignty, data must not move; what must move is computation, in this case, agents must be co-located, temporarily, with the data they will analyze.the The visiting agent runs inside your OS boundary with bounded access to exactly what it needs, and your most sensitive assets never leave your control to reach a model or an operator you do not run.

Stage three: every action crosses one governed boundary

Now your supply-chain partner or critical supplier or a compliance agent has access to your data inside WunderOS-hosted enclave, which is itself running in your VPC. Every tool call, every read, and every attempt to send something out passes through a single governed boundary. The enclave decides what may leave, and an agent cannot take out what the boundary will not pass. There is no second path around it. That is why nothing leaks: leaving is not something the agent does, it is something the boundary allows.

Stage four: every access is provable and replayable

Each action traces through a bounded capability to the person who authorized it. The record holds who asked, what ran, and what it touched, so you can show a regulator or a counterparty exactly what was seen, by whom, and under what authority. So you can yourself curate the record and its results.

Because every governed decision is deterministic, the visit can be replayed and the boundary reaches the same verdicts each time. In fact, the visit can be paused in real-time, in mid-flight, and redirected, terminated, or rescoped. What was seen and allowed is something a regulator can re-run, not a log you ask them to take on trust. When something goes wrong inside the enclave, actions are reversible by WunderOS saga compensation, so an error can be undone rather than merely regretted.

Stage five: on exit, you curate what it remembers

When the agent leaves, it leaves with what you allow. Because the memory is the enclave’s, the owner curates what the visiting agent retains of the visit. What it saw can be erased, edited, or supplemented at your discretion. The agent does not decide what it carries back out.

This is the stage a data room built for human eyes cannot perform, and it is the one that matters most: the last word stays yours.

The enclave runs in real time, not only per visit

A single visit is the simple case. The same machinery runs continuously. Wired to your lakehouse’s update stream, the enclave relays curated changes as they happen, an agentic change data relay rather than a nightly export. The owner curates the stream the way it curates a visit: the boundary decides which changes flow, every relayed change is provable, and the record replays.

In this mode the enclave is an Agentic Transfer Station, a governed point through which real-time curated data moves between your systems and a counterparty’s agents. What agents learned initially was bounded by your data sovereignty rules and what it keeps learninga as underlying data changes is always continuously bounded by your rules.

The station runs in both directions. Curated updates flow out to a partner’s agents as your data changes, and curated changes flow back in under the same governance, so the boundary that proves what left also proves what entered. A partner works against live data instead of a stale copy, and you keep the gate on every change in both directions.

Why an agentic operating system has to carry this

The agentic data enclave is sovereign because the operating system owns the boundary. The agents stay focused because the system carries memory, identity, governance, and recovery for them rather than asking each agent to carry its own. The whole visit is provable because the system is deterministic and auditable by construction. None of these properties is a feature bolted onto an agent, yours or your partners’. Each is a property of the data enclave itself, which inherits them from substrate the visiting agents run on, which is why the enclave is an autonomic agentic OS put to work, and not a policy you ask a visiting agent to honor.

Common questions

How is this different from a virtual data room? A data room is a place you are shown documents under an agreement. It is built for a person who reads, forgets most of it, and is bound by contract. An enclave is a place an agent works, and the owner governs what it does and what it keeps. The agent reads, remembers exactly, and would carry that memory out unless the enclave held it.

Where do the visiting agents run? Inside your boundary (i.e., VPC), on the data, under the enclave’s governance. The computation comes to the data. The data does not go to the computation.

How is it different from a sandbox or a VDI? A sandbox isolates a process and a VDI isolates a screen. Neither governs the agent’s memory of what it saw. Neither hosts agentic executions. The enclave holds the memory itself, which is what lets the owner decide, after the work is done, what the agent is allowed to retain.

Is an Agentic Data Enclave real-time? Yes. Connected to enterprise data sources in real-time, the enclave relays curated changes as they happen, in both directions, under the same governance that applies to a visit. In this mode it also acts asAgentic Transfer Station, and a partner works against live data instead of a stale copy.

Can I prove to a regulator what an agent saw? Yes. Every access traces to the capability and the person that authorized it, and because the decisions are deterministic the visit replays to the same verdicts. You can re-run it, not just recount it.

Does the visiting agent keep its memory of my data? Only what you allow. The enclave owns the memory of the visit, so you erase, edit, or supplement it before the agent leaves.