ClarifyThe autonomous CRM that helps you sell more
Promoted
Your AI agent runs third-party skills and MCP servers with full access to your files, keys and shell — no sandbox, no review. I scanned 96,096 published skills; 751 were malicious. PanGuard vets a skill before you install it, scans what you already have, and blocks hijack attempts at runtime. Free, MIT, fully on-device. Powered by 768 open ATR rules, already merged into Microsoft, Cisco, MISP and OWASP tooling. One command: npm install -g panguard && pga up
Scanning 96k skills is impressive, and the ATR rule ecosystem is a nice trust signal. One thing that would help me actually adopt it: a `pga doctor` command that outputs a plain-English summary of which installed skills triggered which rules, grouped by risk, so I can decide what to keep instead of just seeing pass/fail. Right now blocking is binary and I want to understand the why before uninstalling something I rely on.
@erturultaaz8ux yeah that's the gap. pga status shows flagged vs safe with severity, and audit <path> --verbose gives you the finding and where it is, but nothing walks everything installed and prints skill → rule → why in one go. the json output already has all of it, I just never built the readable view on top. adding it.
honestly the runtime hijack blocking is the part that sold me. one thing though — could you add a simple diff view when panguard flags a skill as suspicious? like show which ATR rule tripped and what line in the skill triggered it. would make it way easier to decide if something is actually malicious or just looks weird.
@ensarglsoyxg9p That data already exists, it's just not in the pretty output yet. pga audit skill <path> --json returns each finding with the ATR rule id, the location, and the matched snippet — the actual line that tripped it. The default view shows severity + description; --verbose adds location.
So it's a rendering gap, not a detection gap. Rule id + the matched line inline, linked to that rule's YAML, is the right default. You should be able to disagree with a rule, not just obey it.
Honest limit while I'm here: the match gives you the line, not the intent. A rule can fire on a legitimate use of the same pattern. That's why it shows evidence instead of auto-deleting.
Love that this finally exists, scanning 96k skills and catching 751 malicious ones is no small feat. One thing I'd find super useful though: a watch mode that monitors new skills published to common registries in real time and pings me when one matching my installed list gets flagged retroactively. Would close the gap between scan day and the next malware drop.
@uurnabb Half of that exists, and it's the less useful half.
Today the daemon pulls new rules automatically signature-verified, fail-closed, an unsigned rule gets rejected rather than trusted and re-checks what you already have installed.
So a rule that lands tomorrow does catch something you installed last week.
What doesn't exist is the direction you're pointing at: watching registries for newly published skills and pushing you an alert. The loop is pull-on-schedule, not push-on-event, and there's no notification path at all.
The gap you named is the real one. 96,096 skills was a snapshot; the registry had moved by the next morning.
ran the one-liner and it flagged two sketchy skills i forgot were even installed, kind of unsettling but honestly glad i know now. the on-device scan is a nice touch.
@kumsald3fn "Unsettling but glad I know" is about the right reaction.
Nothing there is new; it was running before you scanned.
The scan is local — nothing leaves your machine unless you turn sharing on. And if you want to check whether it was a real problem or an over-eager rule, pga audit skill <path> --verbose shows the finding and where it is.
I'd rather you disagree with a rule than trust it blindly.
ran pga up against my usual skill folder and it flagged two MCP wrappers i totally forgot about, the on-device scan is genuinely nice. honestly appreciate that it's MIT and just one command away.
@nisanurbal4rn4 MCP wrappers are the ones that get people.
You install one once, it doesn't show up in any "skills" list you'd think to review,
and it carries shell plus network.
Curious which way it went for you
did the rule name make the call obvious, or did you end up opening the source to decide?
ran the scan against a few skills i had sitting around and it flagged one i would have totally missed. love that it just runs locally without sending anything off-box.