Agent support

Seal is agent-agnostic by design. The standalone CLI provides local and CI integrity checks. Native enforcement requires an integration in the agent’s load path; installing Seal or adding seal.json alone does not change how an agent loads files.

The specification defines that additional layer: verify immediately before loading, apply the configured policy, and suppress project-external extensions in sealed projects.

Want to help?

If you maintain an AI coding agent or harness, see for agent authors. If you want to track or propose an integration, open an issue in seal-spec.

What works today

Projects that commit seal.json can run the seal CLI in CI:

seal verify --quiet

This compares the current checkout with the lockfile. Under block, a mismatch or new bundle within discovery paths fails the job when its exit code is enforced. Run the check after preparing those files and before pipeline steps that use them.

CI does not protect a local session that already consumed changed instructions, or files modified after the check. Native integration must enforce verification at the time of loading. The standalone CLI also does not suppress home-directory or global extensions.

See CI / CD integration for full pipeline examples.

Adding Seal to your agent

If you maintain an agent or harness and want to add native Seal support, the specification defines these obligations:

1. Read for agent authors. It summarises the four obligations every conforming implementation must meet.
2. Read the normative spec. The full text is short.
3. Verify each project‑local bundle immediately before loading it. Apply policy. Unconditionally suppress project‑external extensions in a sealed project.
4. Open a PR and link it here.

Reference implementations live in the seal‑cli repository, which is useful as a behaviour spec when you write your own.