GitHub Agentic Workflows adds enclaves to cap what agents leak from private repos

GitHub Next detailed enclaves, an experimental feature that limits an agent's answers about a private repo to a small, metered schema.

GitHub Next has detailed enclaves (Nov 2, 2026), an experimental feature in GitHub Agentic Workflows that targets GitLost-style leaks. In GitLost, Noma Labs had a malicious public issue steer an agent into posting a private repo's contents as a public comment. If you run agents that read private repos and write to public ones, enclaves change how you can wire that up.

Per GitHub Next, the primary agent can only read its own repo. To ask about a private repo, it launches an enclave: a single-use sandbox run by a trusted broker. The enclave must answer in a schema the primary agent defines, typically Booleans, enums, bounded integers and combinations of those. The broker rejects any response outside the schema. Each repo also gets a bit budget per run, set by its sensitivity. confidential allows 8 bits and internal allows 64. A free-form string schema is rejected for confidential repos. Calls draw on a shared ledger, so asking many yes/no questions can't rebuild a secret. There are two kinds: script enclaves run bounded Python over read-only snapshots with no network, and agent enclaves run a separate coding agent.

GitHub Next says plainly that this bounds communication rather than making every answer safe. A compromised agent can still signal within its budget.

Enclaves shipped as an experimental feature in the GA release on Oct 28, which covers Free, Team and Enterprise. The sources don't say whether enclaves need opt-in or which engines support them.

In our view, enclaves don't replace basic hardening. Matthews Wong's GitLost breakdown lists other controls. You can scope allowed-repos, raise min-integrity, cap safe-outputs comments, and restrict who can trigger the workflow.

Sources