Why Ryzek exists
Agent skills became a supply chain before anyone built the checks.
In about a year, skills and MCP servers went from a novelty to something people install from a link without reading. The review process didn't come with them.
The problem, plainly
An agent skill is a set of files that tells an AI agent how to do something. An MCP server gives an agent new tools. Both run with whatever the agent can reach — your files, your network, sometimes your credentials.
People add them the way they add a package: quickly, from a link someone shared, without reading the contents. That was survivable when a package could only run code. It's a different proposition when the thing you install can also instruct the agent, in text a person never sees.
A package can run code. A skill can change what the agent believes it was asked to do.
That distinction is why Ryzek exists. Classic security scanning asks whether code does something dangerous. Agent skills need a second question: is anything in here talking to the model instead of to me?
Who builds it
Ryzek is built by a small, independent team working on this and nothing else. That cuts both ways, and it's worth saying so.
In your favour: a new rule can ship the week a technique is published. Every rule exists because it was worth writing, not because it filled a comparison table.
Against: there's no large support organisation behind this, and no formal SLA on the standard plans. If you're comparing Ryzek with a heavily funded vendor, weigh that honestly.
How it's built
Every finding states its reasoning. A confidence score and a plain-language reason on every result, so a weak signal never reads like a confirmed attack. People who learn to ignore false alarms also ignore real ones.
Your files aren't kept. Uploads are scanned in memory and discarded. What's stored is a scan count and tool fingerprints for drift detection — never contents.
Detection isn't paywalled. Every rule runs on the free plan. Paid plans are about volume and automation.
It says where it stops. A scanner that claims to catch everything is one you can't calibrate against.
This isn't hypothetical
Every case below is publicly documented. For each, the honest question isn't "would Ryzek have stopped this" but which part of it Ryzek can see, and which part it can't.
Secrets in MCP config files
GitGuardian's 2026 State of Secrets Sprawl found 24,008 unique secrets in MCP-related configuration files on public GitHub — 2,117 of them still valid.
What Ryzek does: this is exactly what mcp-credential-in-config catches. It flags a literal secret in a config value and ignores ${VAR} references, so configs that already do it properly stay quiet.
Source: GitGuardian, 2026
The postmark-mcp backdoor
In September 2025, Koi Security found that an npm package called postmark-mcp — made to look like an official Postmark integration, but unrelated to Postmark — had added one line in version 1.0.16 that BCC'd every outgoing email to the attacker. It was downloaded 1,643 times before removal; Koi estimated 3,000 to 15,000 emails a day were being copied.
What Ryzek does: mostly nothing, and it's important to say so. The backdoor was one line of JavaScript inside the package, and Ryzek reads the skills, configs and manifests your agent loads — not the source of every dependency. If the server's tool definitions had changed, drift detection would have flagged it. They didn't need to.
Source: Koi Security, September 2025
The STDIO configuration flaw
In April 2026, OX Security disclosed that MCP's official SDKs for Python, TypeScript, Java and Rust pass STDIO configuration straight into command execution. The research led to CVEs in projects including LiteLLM, Agent Zero, DocsGPT and Windsurf. Anthropic described the behaviour as expected and declined to change the protocol, so each downstream developer owns the fix.
What Ryzek does: mcp-stdio-injection-surface checks whether a config sits on that pattern and grades by whether a real injection path exists, rather than flagging every STDIO server. mcp-known-vulnerable-version flags LiteLLM pinned below the fixed release.
Source: OX Security, April 2026
Poisoned skill marketplaces
Snyk's February 2026 audit of 3,984 published agent skills found 13.4% carried at least one critical issue, and confirmed 76 malicious payloads. The same month, the ClawHavoc campaign placed at least 1,184 malicious skills on ClawHub, many telling users to install a "helper tool" that was actually malware.
What Ryzek does: the "download this and run it" instruction is what untrusted-external-install looks for, and hidden commands in documentation are what concealed-instruction looks for. A convincing publisher profile is something no scanner can assess.
Sources: Snyk, February 2026 · Antiy Labs, February 2026
The trojanised Oura server
In February 2026, attackers cloned a real Oura Ring MCP server, used fake GitHub accounts and forks to make it look established, and published a trojanised version to MCP registries that installed the StealC infostealer.
What Ryzek does: partially. It reads what a skill's configuration and bundled scripts do, not who published them — so credential reads and outbound sends in those files trip the relevant rules however convincing the project looks. It can't tell you a maintainer is fake.
Source: The Hacker News, February 2026
The Asana cross-organisation leak
Asana launched an MCP server on 1 May 2025. On 4 June it found a bug that had let some customer data appear to other organisations using the feature, and took the server offline to fix it.
What Ryzek does: nothing. This was a bug inside someone else's hosted service, which no scanner of your files can see. What limits the damage in that situation is how much access each connected agent had — and Ryzek does flag permissions broader than a tool needs.
Source: BleepingComputer, June 2025
Where Ryzek stops
Knowing precisely where a tool stops is what makes the rest of it usable. Ryzek is a static scanner: it reads files and doesn't run them.
- Behaviour that only appears at run time. In August 2026, Pillar Security described an MCP server that returned harmless tool metadata until a client had made three tool calls, then switched. Ryzek sees what's in the files; a server that changes while running needs runtime monitoring.
- What's inside compiled programs.
opaque-payloadreports that an unreadable binary ships with a skill. It can't say what the binary does. - Deliberate evasion. July 2026 research showed malicious skills can be rewritten or packed to get past static skill scanners most of the time. Ryzek catches some of those tricks — string reassembly, encoded blobs — but not all of them.
- Live servers and hosted services. Ryzek reads configuration, not what a running server returns, and not bugs inside services you connect to.
- Reputation. Static analysis can't tell you whether a publisher is who they claim to be.
Sources: Pillar Security, August 2026 · Ji et al., July 2026
Where this is going
Now: the web scanner, 54 rules, drift detection and a free plan.
Next: paid plans, and CI integration so scans run automatically when a skill or config changes.
Exploring: ways to notice when a running server's tools stop matching what was approved — the gap the Deadbugz campaign used.
For what's happening in agent security right now, and what it means for Ryzek, see news.
Run it against the skills you already use.
Free plan, every rule included.