GitHub Next has introduced enclaves, an experimental safeguard for GitHub Agentic Workflows that lets an AI agent draw on a private repository without being able to repeat what is in it. GitHub Next published the design on 2 November 2026, days after Agentic Workflows reached general availability at GitHub Universe.
The problem is easy to describe. Give an agent permission to read private code and to post in a public place, and anyone who can talk to it in public can try to talk it into pasting the private material. Noma Labs researchers showed exactly that in the attack GitHub Next calls GitLost. They built an agent that could read an organization’s public and private repositories and answer issues in a public one. A booby-trapped public issue then made it publish the private repository’s files as a comment. No sandbox was broken and no password was stolen. The agent simply did what a persuasive stranger asked.
Enclaves split the job in two. The main agent stays in the public repository and never sees the private one. When it needs something from private code, it asks a separate, single-use enclave to look, and it must say in advance what shape the answer can take: a yes or no, a pick from a short list, a small bounded number. A trusted broker sits in the middle and checks every reply against that shape. Free-form text, attached files and chatty explanations are thrown out.
The limit is counted in bits, the smallest unit of information. A yes-or-no answer is one bit. A choice among four options is two. The workflow’s author sets how many bits a repository may release per run, according to a sensitivity label. Per GitHub Next, “confidential” allows 8 bits, “internal” allows 64, and “sealed” allows none, so no question is even admitted. The broker charges the worst case before the enclave starts, not whatever answer happens to come back, and the account is shared across every call in the run. Asking again with a different shape does not refill it.
Timing and errors are treated as leaks too. Response times are rounded into fixed buckets with a random delay added, and the budget reserves four bits for them. One more bit marks success or failure, and failures return a single canonical error instead of a diagnostic that could carry private text. Script enclaves have no network at all, and agent enclaves can reach only their configured model provider.
GitHub Next walks through the example. Picture a public issue asking if the second major release of a library will work with a private integration. The enclave reads the private code and returns a compatibility verdict and a migration flag, and the public agent writes a comment from those two values. If an injected instruction made the enclave tack on the private README, the reply would fail validation and the main agent would get an error instead.
The post is candid about the gaps. One bit can still answer a sensitive question, and a hijacked agent could signal something within its allowance. The schema also says nothing about whether the answer is right. Agent enclaves send repository content to the model provider, so the budget caps what the main agent learns while the provider still sees the content. The budgets are per run, so a workflow that fires often can leak more in total.
The design matters beyond GitHub because it replaces a request that agents behave with a hard limit on what they are able to say. Anyone wiring agents across repositories with mixed visibility should work out how many bits each workflow actually needs, because the sensitivity setting turns that number into the ceiling.
Reported by GitHub Next on 2 November 2026.
