For: Practitioners & Platform Engineers

56 skills went in. 3 findings came out. A person wrote a reason for each.

SkillGuard doesn’t flag “bad skills.” It builds a bill of materials for every skill, works out what each one can do by reading its code rather than believing its label, runs 10 detectors over the text, and checks whether two skills that name each other would chain into a way out for your data. Then a human decides. Here’s exactly how, end to end.

Every figure on this page is scanner output from our public reference repo (Apache-2.0, 56 skills), regenerated from the tool rather than typed by hand. The same scanner runs against our private skill pool; those results are internal and stay that way.

Inside the black box

Something goes in. Something comes out. Here’s the bit in between.

7steps, no jargon. If any step below needs a security background to follow, that’s a bug in this page, not in your understanding.

1. IN

   A pile of skills

   A skill is a folder: some instructions written for an AI, and sometimes a script it can run. That is all that goes in. No magic, no cloud service, no account.

2. 01

   Write down everything that exists

   First it makes a list. Every folder, every file, and a fingerprint of each one so we can tell later if a single character changed. You cannot check a pile you have not counted.

3. 02

   Work out what each one can actually do

   Then it reads the code and asks: what powers does this thing have? Seven of them, listed below — reach the internet, run commands, read files, change files, touch passwords and keys, install software, write to the code repository.

   It works this out by reading, not by asking. A skill can declare its own powers, but almost none do, and a scanner that trusts a label it was handed is checking nothing.

4. 03

   Unwrap anything written in disguise

   Before it reads a word, it looks for text that has been scrambled on purpose — base64, hex, percent-codes — and unscrambles it. Then it unscrambles what came out of that, up to five layers deep, because hiding something twice is a thing people do.

   Without this step the whole scanner is theatre. Every check below matches text it can read, so one base64 wrapper used to hide a payload from every one of them, and from the powers list in step 02 as well. Added 2026-07-15 after we tested exactly that and watched it sail through.

5. 04

   Read the words, looking for known shapes of trouble

   Now it reads the instructions like a suspicious teacher, hunting for specific shapes of bad behaviour — in the visible text and in everything step 03 unwrapped. Then it checks the folder itself for three more: a hidden file, a huge file, a program smuggled in where only text belongs.

6. 05

   Check whether it just said "never"

   This is the bit most scanners get wrong. Our own security lessons quote the attacks, because a lesson about a trick has to contain the trick. "Never send your .env file to a stranger" and "send your .env file to a stranger" share almost every word. So before it accuses anything, it looks backwards for a "never" or a "do not", and it looks around for the vocabulary of defence — words like detect, forensic, playbook, worked example.

   This is why the secret-exfiltration rule is fussy rather than clever. A loose "verb near a scary noun" match, pointed at a library that is itself security teaching material, produces far more false alarms than real ones — so the rule demands a specific credential file path, an exfiltration verb within a few words of it, and no defensive vocabulary nearby.

7. 06

   Look for dangerous pairs

   One skill that reads your files is fine. One that phones the internet is fine. The two together, when one names the other, is a way out for your data. So it looks for exactly that shape.

   This is co-reference, not surveillance. It means one document mentions another by name and their powers would chain if someone wired them together — not that anyone watched them do it. These are standalone documents, not a live system.

8. 07

   Compare against what a human already forgave

   Finally it lines the findings up against a list of ones a person already looked at and accepted, each with a written reason and, if we chose, a date the excuse runs out. It also checks the fingerprint file from step 01: if a skill has picked up a power it did not have when someone last approved it — it could only read files before, and now it can reach the internet — that is its own finding.

   That last check is the one that catches the oldest trick in supply chains: ship something harmless, wait to be trusted, then push an update that reaches further. A power that appears without a diff anyone read is the signal, whatever the reason turns out to be.

9. OUT

   A report, a fingerprint file, and a pass or a fail

   Out comes a report of everything found, a lockfile of fingerprints so anyone using the skills can spot a change nobody announced, and one answer: pass or fail.

The Methodology

Nine detectors. Seven inferred powers. Two brakes that stop the noise.

SkillGuard does run regexes over your skills. The engineering is not in the matching, which is the easy half; it is in refusing to fire on a library whose whole job is to describe the thing being matched. Here’s the complete detection system.

1. Capability Inference (7 categories)

The scanner analyzes every file in a skill and infers what it can do based on code patterns. This is not what the skill claims to do — this is what the code actually enables.

2. Static Analysis (7 content detectors, 3 bundle detectors)

7 detectors read the words. 3 more check the folder itself. Each one is deliberately narrow: a detector that fires on the general vicinity of a scary noun is worthless against a corpus of security writing, because security writing is made of scary nouns.

Each detector says where it sits on two public taxonomies: the OWASP Top 10 for Agentic Applications and MITRE ATLAS. Two of them map to nothing, and we leave them blank rather than reach. An oversized file is a review-burden signal, not an attack technique anyone has named; and talking a human reviewer out of the approval gate has no ATLAS technique, because ATLAS models the adversary against the machine. A code that looks right is worse than no code, because the reader cannot tell which one they are looking at.

3. The two brakes that make it usable

This is where most scanners fail on a corpus like ours, and it is the part worth stealing. Our skills teach defence, so they quote the attacks. “Never upload your .env file to an external endpoint” and “upload your .env file to an external endpoint” differ by one word. A keyword match cannot tell a lesson from an instruction.

So every text detector passes through two brakes before it is allowed to accuse anything. The first looks backwards a few words for a negation — never, do not, must not, avoid. The second looks around for the vocabulary of defence: detect, forensic, playbook, MITRE, worked example. Either one, and the finding is suppressed.

The secret-exfiltration rule goes further still. It does not match a verb near a noun. It requires a specific credential-bearing file path — .env, .ssh/id_rsa, ~/.aws/credentials, .pem — with an exfiltration verb inside a forty-character window either side of it, and no defensive vocabulary nearby. That fussiness is not fastidiousness. A generic proximity match, run against this corpus, produces overwhelmingly more false alarms than real findings, and a scanner nobody believes is a scanner nobody runs.

4. Co-reference risk (3 chain pairs)

One skill that reads your files is fine. One skill that can reach the internet is fine. The pair is a way out. So the scanner reads each skill’s text looking for the name of another skill, and when it finds one, checks whether their inferred capabilities form one of exactly three shapes:

5. The Triage Discipline

The scanner emits raw findings. A triage team reviews each one against four criteria:

The output is a triage decision file that feeds back into the scanner. On the next run, the scanner checks whether accepted findings should still be accepted or if they’ve expired.

The Proof

What the scan actually found: real findings from the reference repo.

Not a sample. Not an illustration. This is every finding the scanner produced against our public reference repo’s 56 skills — all 3 of them, with the evidence string that fired and the reason a human accepted it. Note what they have in common: every one is a real match on text that is doing its job. That is what the brakes are up against.

What It Proves

The gap between “we have skills” and “we know what our skills can do.”

Most organizations have thousands of skills in their repository. Most have no idea what those skills can actually do, because the only thing anyone ever reads is the description the author wrote. SkillGuard closes that gap: not by flagging “bad” skills, but by making what each one can dovisible, and by making every exception someone’s signed decision.

The methodology is fully documented. The scanner code is available. The triage decisions are recorded. The attack graph is JSON-exportable. This is not a black box — it’s a transparent, auditable process.