The complete guide to protecting your AI Agent Skills.

“Protecting” an AI Agent Skill is a different problem from protecting a binary or a closed-source product. The artefact is plain text. It's designed to be read by an LLM, which means it's also trivially readable by humans. Copy-paste is the only attack you need to worry about, and it works against every Skill on the market.

So “protection” doesn't mean preventing copies — that's impossible. It means having something concrete to point at when a copy surfaces. This guide walks through the three layers of protection that actually work for .mdc and SKILL.md files in 2026, and the practical hygiene that makes those layers worth more.

What can actually go wrong

Before reaching for tools, it's worth being concrete about the failure modes. Four scenarios in rough order of likelihood:

• Verbatim copy with attribution stripped. Someone takes your file, removes the author line, and publishes it under their name. Most common when Skills get traction.
• Near-verbatim copy with small edits.Same content, lightly reworded — a synonym here, a reordered sentence there. The byte-level hash differs but the meaning doesn't.
• Semantic copy with significant rewrite. The same approach and prompt scaffolding, with substantial surface-level changes. Hard to detect by hash alone; obvious to a human reader who knows both files.
• Contested authorship between collaborators. Two people worked on something; later they disagree about who authored what. No bad actor, just a missing record.

Different layers of protection address different scenarios. Stacking them is what works.

Layer 1: Exact-match detection with SHA-256

The bottom layer is the cryptographic hash. SHA-256 produces a 64-character fingerprint of any byte sequence. Identical bytes produce identical fingerprints; any change — a space, a newline, a comment edit — produces a completely different fingerprint.

Registering the hash establishes a permanent claim: these exact bytes existed at this exact moment, attributed to this person. Anyone who later presents the same bytes can be matched against the registration in milliseconds, with no judgment call required.

What this layer catches: scenario 1 (verbatim copy). What it misses: scenarios 2 and 3 — any modification at all defeats hash matching.

Layer 2: Semantic near-duplicate detection

The middle layer is semantic similarity. The SkillAuthor registry runs an embedding-based similarity check against the full registry after every paid registration. The check doesn't care about whitespace, word order, or surface-level rewording — it compares meaning.

How embedding similarity actually works

The pipeline:

1. Each registered file's text is fed through OpenAI's text-embedding-3-smallmodel, producing a 1536-dimensional vector that represents the content's meaning.
2. Vectors are stored in PostgreSQL with the pgvector extension, indexed using ivfflat with the cosine-distance operator.
3. On each new registration, the new vector is compared against every existing vector with a cosine similarity query. Pairs with similarity above a per-recipient threshold (default 0.84) trigger an alert.

Two files that share the same approach, tool definitions, or characteristic phrasing will score high on similarity even if they share no consecutive runs of text. Two files that happen to use overlapping vocabulary but cover different topics won't — the embedding distinguishes by meaning, not by surface form.

Why 0.84 cosine similarity

The default threshold (0.84) is chosen empirically: high enough to avoid false positives on unrelated Skills that happen to share vocabulary, low enough to catch deliberately reworded copies. It's also per recipient: every registration carries its own threshold that the registrant can adjust.

When you flag an alert as a false positive, your personal threshold rises by 0.04 (capped at 0.92). The system learns your tolerance over time: noisy alerts get rarer for you while remaining sensitive for others.

How alerts work and who gets notified

When the similarity check finds a strong match between a new submission and an older one, the older registrant gets the alert email. The new registrant is not notified — they made the submission, they know what they registered.

The email contains: the matched registration number (yours), the new registration number, the similarity percentage, the new registrant's declared name and email, and a pre-filled mailto so you can reach out directly if you want to. There's also a one-click false-positive button that tunes your threshold.

What this layer catches: scenarios 2 and 3 (reworded and rewritten copies). What it misses: registrations that never enter the SkillAuthor registry. If someone copies your Skill and never registers their version, the semantic check can't fire — but they also lack the cryptographic record that would let them dispute your authorship.

Layer 3: A verifiable, immutable timestamp

The third layer is the public verification page. Every registration has a permanent URL at /v/<reg> that anyone can visit. The page shows the registration number, declared author name, filename, SHA-256 fingerprint, file size, registration timestamp, and (if any) the number of near-duplicate alerts this registration has triggered.

This is the layer that makes the proof portable. You can drop the URL — or the QR code that's embedded in the PDF certificate — into your README, your docs, your invoice, or a court filing. Anyone with the original file and the URL can verify authorship in two clicks.

What this layer catches: scenario 4 (contested authorship between collaborators), plus situations where one of the two parties controls the platform you'd otherwise rely on as a tiebreaker.

Best practices for developers in 2026

Always hash before sharing

Even if you don't register every version, hash every version. shasum -a 256 file.mdc gives you a permanent identifier that you can attach to any shared artefact (commit message, email, chat). If a copy surfaces later, you have the original's fingerprint to compare against.

Register meaningful versions, not just first drafts

Each registration is permanent and independent. A common mistake is to register the initial version and not the major updates. If your Skill matures across versions, register the versions that ship — each one gets its own number and certificate. The version history becomes the public record.

Publish your verification URL alongside the skill

Don't keep the registration secret. Put the verification URL or QR code in your repository's README, on the download page, in the file's frontmatter, on the PR that introduces the Skill. Visible attribution is what stops the theft attempt before it starts — most opportunistic copiers move on once they see a clear authorship trail.

Don't rely on private timestamps

Internal Notion timestamps, Slack message dates, screenshots of your file system, dated emails to yourself: in a dispute, none of these survive an adversarial review. You control the system; you could have edited the timestamp. The whole point of a third-party registry is that you can't edit the record after the fact.

Register before sharing widely, not after

The cheapest and most effective time to register is before the Skill is broadly distributed. After a copy surfaces, you'll still want a registration — but the prior copy now competes with yours on timestamp. Register first.

When an alert fires — what to do next

If you receive a near-duplicate alert, the appropriate response depends on context:

• If the match is obviously coincidental(a different Skill that happens to use overlapping vocabulary), click the false-positive link in the email. Your threshold rises, future scans get stricter, and the alert is logged as a flag — it doesn't retract the new registration but it does tune the system to your tolerance.
• If the match looks like genuine independent work (two people solving the same problem in similar ways), the email gives you the new registrant's contact. Reach out. Coordinate. Two independent registrations is a feature, not a bug — SkillAuthor doesn't arbitrate.
• If the match looks like a copy, you now have evidence: a timestamped registration of your version, an email with the new registrant's declared identity, and a permanent record you can point at. Whatever you do next (private message, public callout, lawyer) is on much firmer ground than it would have been without the record.

Limitations worth being honest about

Automated protection has limits. Three to know:

• Detection requires registration on both sides. The semantic check fires when the copy is registered with SkillAuthor. A copy that lives on someone's GitHub but never enters the registry won't trigger an alert. The registration of your version still establishes prior authorship, but you have to find the copy yourself.
• Threshold is heuristic. Cosine similarity at 0.84 reflects a tradeoff between false positives and false negatives. Sophisticated rewrites can score below the threshold; very similar but genuinely independent files can score above. The per-recipient threshold adjustment is the mitigation.
• Registration anchors evidence, not enforcement. SkillAuthor doesn't issue takedown notices, doesn't represent you in disputes, and doesn't arbitrate who “really” authored what. The registration is the evidence; the enforcement is up to you (or a lawyer).

None of these are reasons not to register — they're reasons to register and keep practising basic hygiene. The protection is layered for a reason.