Question the product
A local clone already keeps unpushed work private. Veil earns its place when a coding agent is doing work you still own: it seals the candidate before Git, reconstructs and checks that exact snapshot—including with private gates the agent cannot edit—and publishes only the exact patch whose digest you approved.
Purpose
For ordinary manual work, you should. An unpushed clone is already private. Veil does not make that fact more true.
Veil becomes useful when a coding agent is doing work you still own: its authority is restricted, one candidate is sealed before Git, and only the exact patch you reviewed can be published.
A Git branch records and shares work after it enters repository history. Veil controls the candidate before that point. It separates the coding agent from Git authority, seals one exact result, evaluates that result with pinned public and private gates, and only lets an approved patch digest cross into Git.
You can, and for low-risk work that may be enough. Veil is for cases where review discipline alone is not the desired control. It removes Git metadata and publication credentials from the agent workspace, destroys the disposable execution view, and verifies a sealed result before release.
Maintainers and platform teams that need controlled agent work, private acceptance gates, or evidence connecting a base commit, checked result, and published patch. A solo developer making routine edits may not need it.
The public beta accepts public GitHub URLs and clean, already-authenticated local GitHub checkouts, including private repositories. It does not provide hosted private-repository import.
Agent authority
It separates code generation from repository history and publication authority. The agent can edit the working tree it was given, but cannot use that workspace to rewrite history, inspect hidden Git state, commit, or push.
Instructions are guidance; missing credentials and missing Git metadata are boundaries. Veil does not rely on the model remembering a policy when the workspace itself can make the prohibited action unavailable.
Sealed result & verification
Veil seals one candidate result derived from an immutable base commit. Its encrypted record preserves the captured snapshot and provenance; the review evidence binds the patch digest, recipe digest, tool version, and gate outcomes to that result.
Git metadata, publication credentials, Veil’s private state, and evaluator-owned private gate source do not enter the candidate or published patch.
It is independent from the mutable agent workspace and from private gates the agent cannot modify. Veil reconstructs the sealed candidate in a separate evaluation view and runs the pinned recipe there.
It is still local verification. The public beta does not claim independence from the host operating system, the installed Veil binary, or a malicious machine administrator.
Ordinary local tests run against whatever files currently exist in a working directory. Veil first seals the candidate, reconstructs that exact snapshot in a separate evaluation view, and runs its pinned recipe there with network access disabled.
The resulting status belongs to the sealed result and recipe—not to a directory that may change afterward. Evaluator-owned private gates can also remain unavailable to the agent and outside the published patch.
CI normally begins after code enters Git or a pull request. Veil acts before publication and can run private local gates whose source and output are excluded from the patch. Existing CI should still run after publication; Veil is an additional pre-Git gate, not its replacement.
Repository tests are part of the candidate and can be changed, so reviewers must inspect those changes. Veil can also run separately encrypted private gates that the agent cannot edit and that never enter the candidate snapshot or published patch.
Veil reports the result as unchecked; it does not turn a missing test suite into a security guarantee. A maintainer can add a versioned verification recipe or decide whether an unchecked patch is acceptable.
Publication receipt
Veil generates publication from the reviewed sealed snapshot—not from a mutable working directory. The publication intent is bound to the current result, mode, branch when applicable, patch SHA-256, and expiry. Before release, Veil reruns the configured recipe and refuses publication if the result, approval details, or generated patch digest no longer match.
The receipt also identifies the immutable base commit, so the approved change cannot silently be applied to a different starting point.
No. New manual capture, new agent completion, a changed branch, a different publication mode, an expired intent, or a different patch requires a new review and confirmation. Agent-generated text is never approval.
The local Ed25519-signed attestation binds the repository, immutable base commit, exact patch digest, recipe digest, tool version, gate outcomes, publication intent, and final publication result. A verifier can detect a modified payload or a patch that does not match the reviewed result.
The managed agent workspace receives no GitHub publication credentials. Publishing is a separate maintainer action and requires explicit confirmation. Agent completion is never treated as publication approval.
Nothing on a developer-controlled machine. Veil provides a controlled workflow and evidence; it is not, by itself, an organization-wide enforcement system. Teams would need repository protections and policy enforcement if bypass prevention is required.
Limits & adoption
No. If you authorize a model to work on source code, that provider may receive the code needed for the task. Veil controls the local workspace and publication lifecycle; it does not claim secrecy from an authorized model provider.
No. Your operating-system account, authorized tools, editor, and host can access plaintext while work is active. Veil is not a hardened boundary against the machine owner, host compromise, memory inspection, or forensic recovery.
No. Verification uses the documented macOS sandbox or Bubblewrap boundary, but the public beta does not claim hardened host-wide read isolation or production containment for arbitrary hostile code. Use it with repositories you trust and are authorized to change.
Encryption gives Veil durable state that can be retained without leaving objectives, artifacts, and captured results as ordinary plaintext files. It protects a ciphertext-only storage view without the relevant keys. It does not protect against your logged-in OS account while plaintext is in use.
Not for every change. The cost is additional capture, verification, review, and publication steps. It is justified when agent authority needs narrowing, private gates matter, or the team values a receipt linking what was checked to what was released.
The supported path is macOS or Linux, public GitHub URL imports or clean already-authenticated local GitHub checkouts (including private repositories), local manual or Codex-assisted work, recipe-driven checks, signed result attestations, optional encrypted dispatch to a foreground Connector, and local patch or draft-PR publication. Windows, symlinks, submodules, Git LFS, hosted private-repository import, hosted execution, and production hostile-code isolation remain outside the current product claim.
Decision point
If you only need a private folder, stop here and use Git. If you need a sealed candidate, private gates, and digest-bound publication, run the local workflow and inspect the signed evidence yourself.
Start locally