1000 Agent Skills Just Dropped Into Every Coding Agent. Not One Has Authorization.

The TL;DR. VoltAgent/awesome-agent-skills landed on GitHub with 1,100+ pre-built skills for Claude Code, Cursor, Codex CLI, Gemini CLI, Antigravity, and more. Anthropic, Stripe, Cloudflare, Trail of Bits, Vercel all contributed official skills. It is the largest collection of its kind so far.

Not one of those 1,100+ skills has pre-execution authorization.

Every single one runs with the agent's full permissions. The same permissions that let it read your ~/.ssh/, push to production, deploy infrastructure, and delete databases.

This is not fear-mongering. This is the math of what happened in the last 90 days:

Incident	What	Scale
ClawHavoc (Feb 2026)	341 malicious skills on ClawHub: keyloggers, infostealers, crypto miners	12% of all published skills were malicious
Hugging Face nullifAI	Broken pickle files that run code before Picklescan errors out, per ReversingLabs; TNW counts 352,000 unsafe or suspicious issues across 51,700 models	51,700 models flagged
Snyk ToxicSkills	36% of all AI agent skills contain security flaws, ~900 skills called malicious	Cross-ecosystem audit
CLI-Anything (May 2026)	Mass-generates SKILL.md files (30,000+ GitHub stars since March); VentureBeat notes no mainstream scanner has a detection category for malicious instructions inside them	Instruction-layer attack surface
Claude Code --dangerously-skip-permissions	Writes to .claude/skills/ now bypass permission gates entirely	Deprecated safety rails

Here is the uncomfortable question: what are we actually doing about it?

The authorization gap nobody is filling

Let me be specific about the problem.

Authentication in the agent world is solved. Claude Code knows it is talking to Claude. Cursor knows it is connected to your project. GitHub Copilot knows who you are.

Authorization is missing. The question "should this agent tool be allowed to do this specific thing, in this context, at this privilege level?" does not exist in any of these stacks.

Here is what happens when your agent resolves a skill:

1. Discovery. Agent finds skills/ directory or marketplace listing
2. Load. Agent reads the SKILL.md or manifest
3. Trust. Agent assumes the skill is legitimate
4. Execute. Agent runs tool commands with YOUR credentials

Step 3 is the gap. There is no step 2.5 that says: "Hold on. This skill wants to write to ~/.aws/credentials. Did you authorize that? Was that in the description? Is this even the same skill you saw two days ago?"

When Anthropic introduced --dangerously-skip-permissions and stopped prompting for writes to .claude/skills/, they essentially said: "Skills are trusted by default." In a world where ClawHub had 12% malicious skills, that is a bet I am not willing to make.

The vector is worse than you think

The ClawHavoc campaign was not sophisticated. The 335 malicious skills linked to that single operation did not exploit zero-days. They just published skills that did bad things. And because the agent ecosystem has no authorization layer, those skills ran with full privileges the moment an agent selected them.

Here is the specific attack chain that keeps me up at night:

1. Attacker publishes a "code quality" skill to a marketplace
2. The skill claims to lint your project and fix formatting
3. Agent downloads the skill because "linting" is a common request
4. The skill's real payload: read ~/.env, exfiltrate AWS_SECRET_ACCESS_KEY via DNS lookup
5. There is NO prompt. No "this skill wants network access." No sandbox. No boundary.

This is not theoretical. Snyk found 30 skills from a single author that silently turned AI agents into cryptocurrency miners. The TNW investigation confirmed: 341 malicious skills on ClawHub alone.

Why this is different from browser extensions

You might be thinking: "This sounds like the browser extension security conversation from 2009."

You are right. And wrong.

Browser extensions eventually got permission manifests. Chrome extensions declare what they need (tabs, storage, cookies) and Chrome gates those capabilities. It is imperfect. Extension creep happens. But there is a system in place.

Agent skills have zero equivalent. Zero.

The differences that matter:

	Browser Extensions (Today)	Agent Skills (Today)
Permission declaration	Manifest declares capabilities	No standard
User consent	Granular prompts per capability	One yes/no for the whole agent
Context awareness	"This tab only" vs "all tabs"	No boundary
Runtime revocation	Disable/remove any time	Requires deleting the skill
Audit trail	Chrome Web Store review	No review process

And browser extensions took 10+ years to get to this point. We do not have 10 years. The adoption curve for AI coding agents is measured in months.

What I built: Open Agent Passport (OAP)

About 9 months ago, I started working on Open Agent Passport (specification). It is an open standard for pre-action authorization in AI agents. The idea is simple:

Before an agent executes ANY skill action, verify authorization through a policy decision point.

Not authentication. Authorization. The difference between "who are you" and "what are you allowed to do."

The architecture looks like this:

Agent > Resolves Skill > OAP Guardrail Intercepts >
  Policy Engine Evaluates (action, resource, context) >
  ALLOW with constraints / DENY with reason

OAP defines:

• A policy language. Declarative rules for what skills can and cannot do.
• A passport payload. Signed metadata about what a skill claims to do. This is the "manifest" equivalent.
• A verification layer. Hooks into the agent's before_tool_call lifecycle to enforce policy before the tool touches anything.

The key idea: the policy moves with the agent. You do not trust "skill marketplace X says this is safe." You trust your own policy engine.

Three things you can do today

You do not need to adopt OAP to start closing this gap. Here is what I would recommend right now:

1. Audit your agent's skill directory

# See what skills your coding agent is loading
find ~/.claude/skills/ -name "SKILL.md" | wc -l
# Check what commands they run
grep -r "exec\|bash\|run\|command" ~/.claude/skills/*/SKILL.md

Read the matches. Any skill that makes outbound network calls its description never mentions is a candidate for deletion.

2. Lock down dangerous capabilities

Most agent runtimes support some form of deny list. In Claude Code, permissions.deny in settings.json takes tool rules, and a deny rule wins over any allow rule:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

This blocks matching actions unconditionally, whichever skill asked for them. It is a tripwire, not a fine-grained authorization system. But it is better than nothing.

3. Verify skill integrity before first use

Before running a skill from a marketplace:

• Compare the skill's current content against its initial published version
• Check for recent commits that changed behavior without version bumps
• Look for unexpected tool calls in the SKILL.md
• Cross-reference the publisher's identity across ecosystems

VentureBeat's reporting on CLI-Anything makes the point: no mainstream security scanner has a detection category for malicious instructions embedded in a skill definition, so a poisoned SKILL.md never shows up as a CVE or in an SBOM. The right question is whether this is the actual skill the author intended you to run. Coming from an official source does not answer that.

What I am not saying

I want to be clear about the limits of this argument.

None of this is an indictment of VoltAgent, awesome-agent-skills, or any specific marketplace. They are doing what every new ecosystem does: focusing on growth, distribution, and developer experience. That is the right call for adoption.

None of it is a claim that every skill is malicious either. The vast majority of skills are written by developers who want to share useful tools. The problem is structural. When 1,100 skills ship into an ecosystem with zero authorization gating, the bad ones do not need to be common. They only need to exist.

This is also not a pitch to abandon open source skills. I am building OAP because I believe the open model works. But open needs boundaries the same way the web needed CSP and CORS. Skills need the same treatment.

What the numbers add up to

1,100 skills in a single curated collection. 341 malicious on another platform that was supposed to be trustworthy. 36% of all agent skills have flaws somewhere in the ecosystem. And the entire authorization model is: "the agent decided to run it, so it must be fine."

We solved authentication. We solved API gateways. We solved container sandboxing. We can solve agent skill authorization.

The question is whether we do it before the next ClawHavoc or after.

I am building Open Agent Passport (OAP), an open standard for pre-action authorization in AI agent systems. What are you seeing in your agent deployments? I am genuinely curious what gaps other teams are finding.