Skip to content
~$ seal

Seal

seal — secure coding agent

seal@runtime:~$

Seal

The cryptographically secured AI coding agent. Designed as a defense against rogue agents, prompt injection, and curl scripts that delete your production database — without slowing the agent down.

Install Read the docs

What Seal is

Section titled “What Seal is”

Seal is an AI coding agent where the agent itself runs inside a WebAssembly sandbox and can only touch your system through cryptographically signed capabilities. The security model isn’t a wrapper around an off-the-shelf agent — it is the design.

The leading agents start from the opposite shape: a long-lived process with broad shell access, gated by a permission prompt that defaults to “remember this.” After a few sessions the user is clicking through without reading, and the agent is running with whatever blanket grant the click implied. Five things Seal does differently:

  • The agent itself runs in a WebAssembly sandbox. Compiled to wasm32-wasip3 with zero WASI imports — no filesystem, no network, no syscalls. The only doors out are typed WIT calls into the host daemon, which checks every one against the manifest. Prompt injection that would let a normal agent process open a socket or read ~/.ssh instead surfaces as a capability the model has to ask for and you have to approve.
  • Every command Seal runs is sandboxed with no off-switch. Subprocesses enter bwrap (Linux) or sandbox-exec (macOS) on every spawn. There is no flag, no permission prompt, no escape hatch that lets a command run unsandboxed; the popular alternative — sandbox off by default, or an “approve this once” bypass — is security theatre, and Seal does not ship it.
  • Capability-typed and per-command scoped. Every tool call carries a typed capability that the dispatcher checks against seal.toml before executing. The scope is the command pattern, not the process: cargo sees ~/.cargo/registry and crates.io, gh sees ~/.config/gh and github.com, neither can reach the other’s surface — and neither can reach ~/.ssh. Coarse sandboxes bind the whole filesystem read-only for every command they wrap; Seal binds only what each command’s grants name.
  • Prompts that don’t burn out. Four choices, not two — Allow once and Allow always are split, so silencing a narrow grant doesn’t silence the whole tool family. The suggested pattern is adjustable at the prompt; the matcher picks the most specific. Patterns layer cleanly: a broad git:* prompt sits alongside narrow silent allows for git status and git diff:* without either shadowing the other, and new subcommands always surface for approval before they run.
  • Tamper-evident audit. Every grant is hashed and signed. The signed-manifest hash flips when anything changes, forcing re-approval. Every sandbox-enforced denial lands in the per-session audit log.

Why this matters

The two sandboxes compose. The WASM envelope means the agent process itself can’t reach anything outside the WIT surface. The OS envelope means every command the agent spawns is bounded at the kernel boundary regardless of what the agent or its dependencies try. Between them sits a manifest you have to sign — every grant attributable, every denial logged, no path that quietly widens the surface.

Read the full “Why Seal” page →

Permission model

The four-way prompt and how grants accumulate. Learn more →