seal.

Review → pin → verify

Your team reviews a skill and its helper scripts. Later, an installer changes one of those scripts, or a new skill appears in the same directory. Seal checks the files on disk against your pinned snapshot and reports the difference.

1. Review the files

Inspect the instructions, scripts, and resources you intend to use. Pinning records their contents; it does not establish that they are safe.

2. Pin the snapshot

Run seal init, inspect the proposed paths, and commit seal.json through your normal review process. It records per-file SHA-256 hashes and discovery patterns.

3. Verify in CI

Run seal verify. Under the default block policy, changed bundles and new bundles within configured discovery paths return exit code 1.

4. Review updates

Inspect the changed files, then run seal pin. Review the content and lockfile diffs together before accepting the new snapshot.

# After reviewing your installed agent files, from the project root:
seal init

# In CI, check the installed files against the committed snapshot:
seal verify --quiet

# After reviewing an intentional update, record its new contents:
seal pin .agents/skills/code-review

With .agents/skills/* in discovery, a changed code-review/scripts/review.sh reports Mismatch. A new .agents/skills/deploy/ bundle reports Unverified. Both fail verification under block. Removing an entire bundle reports Drift and does not fail by itself.

Already using Git?

If your agent files are tracked, reviewed, and loaded from a clean checkout, Git already gives you much of this protection. Seal is useful when you want an explicit content baseline for installed files, including files copied or generated outside Git’s tracked set, and a dedicated verification command for CI.

Control	What it gives you
Git review and clean-checkout checks	History, reviewed changes, and checks against the index and commit. These may be sufficient for your workflow.
Read-only permissions	Restrictions on who can write files. Seal complements them by checking file contents when invoked.
Skill package managers	Dependency installation and synchronization. Tools such as dotagents manage which agent resources are installed.
Seal	A snapshot of selected local bundles, discovery of additions within configured paths, and offline integrity verification.

Compare Git, read-only files, dotagents, and Seal →

Cover the files your project uses

Seal can pin project-local files and directories outside .agents, including prompts, rules, hook scripts, and tool configuration:

# After seal init, pin existing files or directories you have reviewed:
seal pin prompts/review.md config/agent-hooks

Coverage follows the paths in seal.json. Pinning one file checks that file; to catch new siblings, configure a broader pattern such as prompts/*.md. A whole-directory bundle is another option, but it must replace any nested file entries and their discovery patterns. Verification does not automatically discover every path an agent might load.

Know what verification guarantees

Today: the CLI checks local files when you run it. CI can stop a pipeline on a mismatch. Preventing an agent from loading changed files requires an integration in the agent’s load path; installing the CLI alone does not provide that enforcement.

The boundary: Seal hashes local bundle contents. If a pinned script downloads and executes remote code, Seal checks the script, not the downloaded payload. It does not resolve or pin a transitive dependency graph.

The trust anchor: your review process protects seal.json. Changing both a bundle and its recorded hashes can pass verification. A matching hash proves the contents match the snapshot, not that they are safe or approved by a particular person.

Read the threat model →

Get going

QuickstartReview, pin, verify, and handle an intentional update.

Why Seal?When it adds value alongside Git and dependency tooling.

Agent supportWhat the CLI checks today and what native enforcement requires.

Read the specThe portable format and verification rules for implementers.