Welcome, enclaves: control the channel, not the agent

This summer Noma Labs disclosed GitLost, in which an attacker opened an ordinary issue in a public GitHub repository with the goal of making a legit agent workflow exfil private information. In a classic injection attack, the issue asked the agent, in plain English, to fetch a private repository’s README and publish it in a public comment. The agent happily did that, since it held both permissions legitimately.

Four months later, GitHub Next shipped an answer, GitHub Enclaves (GHE): a primary agent that cannot read a private repo spawns a single-use sandbox, a script or agent enclave, through a trusted broker. The enclave does the private work and can answer only through a JSON schema with an explicitly enumerated answer set, which is charged against a per-repository information budget measured in bits.

Coincidentally, I developed WunderOS’s Agentic Data Enclave (ADE), version 1, this July, without noticing GitLost then. It has some similarities with GitHub Enclaves, which we’ll look at in detail in this post.

The pieces of GitLost are simple and universal: an agent has an access channel to data holdings. I noticed this pattern in big enterprises that share data with their partners in, say, supply chain or due diligence. The solution is simple to state: the data access channel has to be controlled by something that isn’t an agent.

Comparing ADE and GHE

GHE says that our agent needs to ask a question of their private repository, and the enclave broker controls what our agent learns about their repo, by using a mix of response schemas, a bit budget, and a ledger per run.

WunderOS ADE says something very similar: a partner’s agent visits our data estate in order to learn some approved things from our data. ADE controls what the agent guests can learn and what they take home when they leave. So a guest agent accesses data inside the enclave, everything it does there is governed, and its return trip home is curated.

The shape of the pieces is an agent on one side, a data estate on the other, and a data-access channel in between. GHE is a security primitive inside CI and it controls the relationship between a pair of repos. ADE is a boundary mechanism for multi-party agent work in an agent operating system. I published more about ADE in PLRN-016, and the reference pages explain it in more detail.

GHE gets three things right

First, the problem is framed as need-to-know, that is, compartmentalizing access more than clearance per se.

Second, a clear statement of limitation:

The guarantee is a bound on communication, not a judgment that every possible question or answer is safe.

Third, the worst-case charge is reserved before execution. The broker computes what a schema-compliant response could possibly contain, including the status and timing channels, and subtracts that amount from the repo’s per-run budget before running anything. Calls share a ledger. Their schemas can’t be changed. A request that doesn’t fit in the balance is denied.

The differences

1. Timing is budgeted and certified, not bucketed. The GHE boundary reserves four bits for twelve fixed timing buckets plus up to a second of jitter. They say that the random delay “adds jitter, but does not eliminate the timing channel”. ADE certifies the visit’s total residual covert capacity with a corrected mutual-information bound, using a technique adopted from a paper, “An Application-Layer Multi-Modal Covert-Channel Reference Monitor for LLM Agent Egress” arXiv:2605.20734.

2. ADE’s whole export is governed, not just the answer. GHE ends at the validated response. ADE intervenes decisively at an exit curation phase. An ADE visit results in facts that leave as symbolic bundles with per-fact lineage verdicts. Extracts from structured data, i.e., relational databases, are only taken away by agent guests under schema contracts that declare columns and rows, aggregation thresholds, precision rounding, and deterministic ordering. All binaries are denied by default. Optionally, the agent’s proposed takeaway is provided to explicit human review. ADE also enforces an exhaustiveness rule: the only things that survive a visit are the curated export and the audit record.

3. Replayability is a requirement, not a bonus. GHE’s broker validates each launch and response in real time. ADE’s must survive audit questions after the fact, that is, variations of why did the boundary decide that? at some future time. Every ADE decision can be derived again from recorded inputs, including whole-visit deterministic execution replay. A broker that checked the request once and then couldn’t answer auditor questions later isn’t good enough, as I describe in a recent blog post.

4. Capabilities with teeth. An ADE guest carries an owner-minted capability during its visit: permissions subject to one-way narrowing that never widens again; revocation that works even when the guest doesn’t cooperate; delegation chains; and replay-pinned evidence. GHE’s broker checks each launch request before its enclave runs. That check is missing two pieces: rules for how a narrowed grant composes down the delegation chain and a revocation story.

5. Model-provider trust is governed, not footnoted. GHE says that “provider selection and data-handling requirements remain part of the maintainer’s security decision.” Which makes sense. ADE cannot afford to take this option. Since a model call crosses the enclave boundary twice, once as a tool call and once as network egress, ADE can govern it effectively. The ADE customer, which is the data owner, can force agent guests to only use inference from an in-VPC model tier. Secrets are brokered in at boot. No model credential exists before ADE says so. Another, smaller asymmetry worth mentioning is that GHE doesn’t distinguish denied from waiting for a human. ADE separates these since otherwise we’d be vulnerable to retry storms, which the GHE post doesn’t mention.

GHE’s ingress ledger is worth stealing

The ingress ledger. Their cumulative budget is charged on the caller’s side, at admission, before each response can be requested, so a repeated run of one-bit questions spends the same finite pool as one ambitious question. The ADE ledger sits on the export side. On the ingress side, a guest’s cumulative learning is governed per call: capability scope, narrowing obligations, rates and byte counts.

Volume bounds are not information bounds. A rate-limited visitor can still ask one-bit questions, one after another, and our current corpus doesn’t track what those questions collectively reveal. GitHub’s admission-time charging is the right idea, taken in the direction ADE doesn’t yet support.

Welcome

Welcome to the age of agent enclaves: an agent on one side, a data estate on the other, and a channel between them that’s immune to the agent. Agents are a weird mixture of user and application. Enclaves are one way to let them work without letting them run wild.