Install
$ agentstack add skill-officialunofficial-skills-mkit-attest ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
mkit-attest
An mkit attestation is an in-toto v1 Statement (a typed predicate about a subject) sealed in a DSSE envelope and attached to a commit. Downstream consumers verify it against a trust-roots registry — the set of public keys they're willing to trust. The subject is always a commit (its BLAKE3 id); the predicate is your claim (provenance, code review, SBOM, test results, …).
The chain is: signed commit → one or more DSSE attestations → verify against trust roots. A commit must already be signed (mkit keygen first); attestation adds claims on top of the commit signature.
Attestation signer keys
Attestation signers are separate from the Ed25519 commit key and are written by keygen --algorithm:
mkit keygen --algorithm ed25519 # → .mkit/keys/ed25519.key
mkit keygen --algorithm p256 # → .mkit/keys/p256.key
mkit keygen --algorithm secp256k1 # → .mkit/keys/secp256k1.key
> These do not create a commit key. If commit then reports "no signing > key", run plain mkit keygen for the Ed25519 commit key. Keep the two roles > distinct in your head: one key signs the commit, another signs the attestation.
Produce an attestation
# Attest HEAD (or --commit ) with a predicate document:
mkit attest --algorithm ed25519 \
--predicate-type https://example.com/review/v1 \
--predicate-file review.json
# Multiple co-signers — all-or-nothing (any signer failure aborts; no partial
# envelope is written). Multi-signer is shell-only:
mkit attest --algorithm ed25519 \
--additional-signer "algorithm=p256,signer=repo-key" \
--predicate-type https://example.com/provenance/v1 \
--predicate-file provenance.json
The predicate file is your claim as JSON; --predicate-type is the URI that tells a verifier how to interpret it. Omit both to attest the bare subject.
Verify attestations
mkit verify-attest --commit \
--trust-roots ~/.config/mkit/trust-roots.toml
Security gate — always pass --trust-roots explicitly. verify-attest refuses an in-repo trust-roots file, because a hostile clone could ship its own roots and make verification falsely print "ok". The default path is $XDG_CONFIG_HOME/mkit/trust-roots.toml. Exit codes:
| Exit | Meaning | |------|---------| | 0 | every attestation has ≥1 verified signature | | 65 | at least one attestation failed verification | | 1 | the commit carries no attestations |
Branch on these codes, not on stderr text — 1 (nothing to verify) is a different decision from 65 (present but invalid).
Prefer MCP when available
Through the mkit MCP server (mkit mcp --repository ), mkit_attest and mkit_verify_attest are stricter and safer than the shell — use them for single-signer flows:
- The
attestpredicate file must resolve inside the repo. - The
verify_attesttrust-roots path must resolve outside it (in-repo roots
always rejected — the hostile-clone defense).
- Signing is pinned to ed25519 with the repo key; ambient
attest.*config never
steers it.
Multi-signer and external-signer attestation (--additional-signer, --signer external) are shell-only — the MCP tool is single-signer by design.
In CI
- Generate or provision the attestation signer out of band; never commit private
keys. In an agent/CI context, pass the predicate via --predicate-file (no interactive paths).
- Verify with a trust-roots file that lives outside the checked-out repo
(e.g. a runner-level config path), so a malicious PR can't smuggle its own roots into the verification.
- Gate the pipeline on the exit code: treat
65as failure, and decide
deliberately whether 1 (no attestations) should block or pass.
For the wire format and predicate details, see docs/specs/SPEC-ATTESTATIONS.md and docs/specs/SPEC-SIGNING.md (or get_spec ATTESTATIONS / SIGNING via the mkit docs MCP).
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: officialunofficial
- Source: officialunofficial/skills
- License: Apache-2.0
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.