Documentation

Build with trust

Everything you need to install, verify, and understand agent skills. Security scanning, cryptographic signing, and full transparency.

Vett uses Sigstore for cryptographic signing of skill manifests. Every artifact is signed with ECDSA P-256 and recorded in a public transparency log, providing verifiable provenance.

Why Signatures Matter

The problem with trust in distributed systems.

Without signatures, you have to trust every hop between the source and your machine: the CDN, the network, the registry, the storage layer. Any of them could serve you different content than what was originally scanned.

Without signatures
  • CDN cache could be poisoned
  • MITM could modify the download
  • Storage could be compromised
  • Force-push could change source
  • No proof of what was scanned
With signatures
  • Tampering is mathematically detectable
  • Only Vett can produce valid signatures
  • What you install = what we scanned
  • Verification happens locally
  • All signatures publicly auditable
Defense in depth
Signatures complement hash verification. The hash ensures content integrity (no bit flips), while the signature ensures authenticity (this came from Vett).

Sigstore Integration

Modern signing with public transparency.

We use Sigstore's Rekor transparency log, the same infrastructure used by npm, PyPI, and Kubernetes. Every signature is recorded publicly for auditability.

Algorithm
ECDSA P-256 (SHA-256)
Transparency log
Rekor (hashedrekord)
Entry type
hashedrekord v0.0.1
Public log
search.sigstore.dev

Why ECDSA P-256?

Sigstore ecosystem standard

ECDSA P-256 with SHA-256 is the algorithm used throughout the Sigstore ecosystem, ensuring compatibility with Rekor's hashedrekord entry type.

Strong cryptography

P-256 provides 128 bits of security—computationally equivalent to 3072-bit RSA—with smaller key and signature sizes.

Public transparency

Every signature is recorded in Rekor, a public append-only log. Anyone can verify when a manifest was signed by searching the log.

Signing Flow

How we sign a skill manifest.

1
Serialize the manifest
The skill manifest (JSON) is serialized to bytes using canonical JSON. The exact byte sequence is what gets signed—any change produces different bytes.
2
Compute SHA-256 hash
The manifest bytes are hashed using SHA-256. This digest will be signed and recorded in Rekor.
3
Sign with ECDSA P-256
The hash is signed using our ECDSA P-256 private key. This produces a DER-encoded signature that proves the manifest came from Vett.
4
Record in Rekor
The signature is recorded in Rekor as a hashedrekord entry. Rekor returns an inclusion proof that the signature is in the transparency log.
5
Store bundle
The complete Sigstore bundle (signature, public key, and Rekor proof) is stored alongside the manifest in the registry.
sigstore bundle (simplified)
1{
2  "mediaType": "application/vnd.dev.sigstore.bundle+json;version=0.2",
3  "verificationMaterial": {
4    "publicKey": {
5      "hint": "v1-ecdsa-2025-02-04"
6    },
7    "tlogEntries": [{
8      "logId": "c0d23d6ad406973f9559f3ba...",
9      "logIndex": "12345678",
10      "inclusionProof": { ... }
11    }]
12  },
13  "messageSignature": {
14    "messageDigest": { "algorithm": "SHA2_256", "digest": "..." },
15    "signature": "MEUCIQDxT8..."
16  }
17}

Verification Flow

How the CLI verifies a downloaded artifact.

Verification happens locally on your machine. The CLI doesn't trust the registry's claim that something is valid—it verifies independently using the known Vett public key.

1
Download artifact and bundle
The CLI downloads the manifest bytes and its associated Sigstore bundle from the registry.
2
Verify public key
Check that the public key in the bundle matches the expected Vett signing key (embedded in the CLI or set via environment variable).
3
Verify signature
Using ECDSA P-256, verify the signature matches the SHA-256 hash of the downloaded manifest bytes.
4
Verify transparency log
Verify the Rekor inclusion proof confirms the signature was recorded in the public transparency log.
5
Install if valid
Only if all verifications pass does the CLI extract files to disk. Any failure aborts the installation.
verification output
vett add owner/repo/skill
...
◇  Downloaded and verified
◇  Signature verified
◇  Integrity verified (Sigstore · Rekor transparency log)
◇  Installing to vett
◇  Installed to vett
Offline verification
Once you have the bundle, signature verification can happen completely offline. Only the transparency log verification requires network access.

Transparency Log

Public accountability for all signatures.

Every signature is recorded in Rekor, Sigstore's public append-only transparency log. This provides:

Public auditability

Anyone can search the log to see what was signed and when. No hidden signatures possible.

Append-only immutability

Once recorded, entries cannot be modified or deleted. The log provides cryptographic proof of inclusion.

Timestamp evidence

The log entry provides proof of when the signature was created, providing an auditable timeline.

search rekor for vett signatures
# Using rekor-cli with the vett public key
rekor-cli search --public-key /path/to/vett-signing-public.pem

# Or browse the web interface
https://search.sigstore.dev

Git Provenance

Tracking where skills came from.

For Git-sourced skills, we record provenance information that ties the artifact back to a specific commit. This provides auditability even if the source repository changes later.

sourceUrlThe original URL used to fetch the skill
gitRefThe branch or tag name (e.g., "main", "v2.1.0")
commitShaThe exact commit SHA at fetch time (40 hex characters)
provenance metadata
{
  "sourceUrl": "https://github.com/cursor/skills/tree/main/frontend-design",
  "gitRef": "main",
  "commitSha": "abc123def456789012345678901234567890abcd"
}
Force-push protection
Because we record the commit SHA, we can prove exactly what content we fetched. Even if someone force-pushes over the branch later, the artifact we signed is immutable and traceable to a specific commit.

Content-Addressed Storage

Immutability through hashing.

Signed manifests are stored using their SHA-256 hash as the storage key. This provides immutability guarantees at the storage layer.

# Storage path
skills/e5f6a7b8c9d0e1f2a3b4c5d6...f6.json
↑ SHA-256 hash of manifest bytes
Collision resistance

SHA-256 has 2^128 security against collision attacks. Finding two different manifests with the same hash is computationally infeasible.

Natural deduplication

If two skills have identical content, they share the same storage key. This is expected behavior, not a bug.

No overwrite possible

You can't upload different content to the same path—changing the content changes the hash, which changes the path.

Security Properties

What Sigstore signing guarantees.

Integrity

Manifest bytes haven't been modified since signing

Authenticity

Signed by the Vett signing key

Non-repudiation

Signature recorded in public transparency log

Timestamp

Rekor entry timestamp proves when signing occurred