Your developers are installing AI coding assistants that execute with full system permissions. No runtime checks. No sandboxing. Just direct access to everything on their machines.
Mobb.ai's recent audit of 22,511 public skills across four registries found 140,963 security findings. The numbers tell part of the story: 27% contain command execution patterns, and one in six includes a curl | sh remote code execution pattern. But the real problem isn't what the audit found. It's what happens after a skill passes initial scanning.
Why These Mistakes Keep Happening
AI coding agents arrived faster than the security model to support them. Teams treat these tools like IDE extensions or npm packages, assuming someone else verified them. But registries scan skills at publish time only. Once installed, these skills run with the same permissions as your developer's shell, accessing credentials, modifying files, and executing arbitrary commands without any runtime verification.
You're not installing a static library. You're granting execution rights to code that can evolve, phone home, and act on instructions you never reviewed.
Mistake 1: Treating Registry Scans as Runtime Protection
Why it happens: Your team sees that a registry scanned a skill before publishing and assumes that's sufficient. The skill has a checkmark, maybe even a security badge.
The real consequence: A skill that passed scanning six months ago now executes on your developer's machine with today's threat landscape. No registry currently audits hook configurations specifically, meaning you have no visibility into what triggers during build, commit, or deploy events. A skill could inject code into your CI/CD pipeline, and your registry scan wouldn't catch it because the malicious behavior only activates at runtime.
The fix: Implement client-side enforcement before any skill executes. Build a policy engine that checks:
- What system calls the skill attempts
- Which environment variables it accesses
- What network connections it initiates
- Which files it reads or modifies
Don't rely on the registry to protect your runtime environment. That's your job.
Mistake 2: Installing Skills Without Reading the Manifest
Why it happens: Developers search for functionality ("generate unit tests"), find a skill that matches, and install it. Reading the manifest feels like reading Terms of Service, so nobody does it.
The real consequence: You've just granted a third-party tool access to your codebase, credentials, and network. The manifest might declare permissions you'd never approve: reading SSH keys, accessing cloud provider credentials, or executing shell commands with sudo. One in six skills includes patterns that pipe remote content directly to shell execution. That's not a theoretical risk. That's arbitrary code execution waiting to happen.
The fix: Make manifest review mandatory before installation. Create a simple checklist:
- Does this skill request file system access? Which directories?
- Does it execute shell commands? Show me the command patterns.
- Does it make network requests? To which domains?
- Does it access environment variables? Which ones?
If the manifest doesn't clearly document these permissions, don't install the skill. If it requests more permissions than the functionality requires, find an alternative.
Mistake 3: Running Skills in Your Production Development Environment
Why it happens: Setting up isolated environments feels like overhead. Your developers work in their primary development setup because it has all their tools, credentials, and configurations already in place.
The real consequence: A compromised skill now has access to production credentials, customer data repositories, and your deployment infrastructure. When ClawHub experienced a security incident, every developer running skills in their standard environment became a potential entry point. The blast radius of a single malicious skill extends to everything that developer can access.
The fix: Enforce skill execution in isolated containers or VMs. Use tools like Docker or Podman to create disposable environments where skills run with minimal permissions. Mount only the specific directories the skill needs. Don't share your main shell's environment variables.
Your container config should look like this:
- Read-only access to source code
- No network access unless explicitly required
- Separate credential store with limited-scope tokens
- Logging of all system calls
Yes, this adds friction. That friction is the point.
Mistake 4: Assuming Skills Are Immutable After Installation
Why it happens: You reviewed a skill once, approved it, and moved on. The skill sits in your developer's environment, quietly updating itself or pulling new configurations from remote sources.
The real consequence: The skill you vetted last month isn't the skill running today. Many AI coding agents fetch updated prompts, rules, or even code from remote servers. Your initial security review is obsolete the moment the skill phones home for new instructions. You're running untrusted code with trusted permissions.
The fix: Pin skill versions explicitly. Disable auto-updates. Treat skill updates like dependency updates: they require review and approval.
Set up monitoring for:
- Skills making unexpected network connections
- Skills accessing files outside their declared scope
- Skills executing commands not present in the original manifest
When a skill needs updating, review the changelog. If the maintainer doesn't provide one, that's a red flag.
Mistake 5: Skipping the "Why Does This Skill Need This Permission?" Question
Why it happens: A skill requests broad permissions, and your team assumes the developer knows what they're doing. Questioning it feels like blocking progress.
The real consequence: You're granting permissions based on what a skill requests, not what it actually needs. A code formatting skill doesn't need network access. A test generator doesn't need to read your AWS credentials. But if you don't ask why, you'll approve permissions that create unnecessary risk.
The fix: Apply least privilege ruthlessly. For every permission request, ask: "What specific functionality requires this access?" If the answer is vague ("for enhanced features") or absent, deny the permission.
Build an approval matrix:
- File read access: Only to source code directories
- File write access: Only to test or generated code directories
- Network access: Only to documented API endpoints
- Environment variable access: Explicit allowlist only
- Command execution: Never, unless you've audited every command
If a skill can't function with restricted permissions, find a different skill or build the functionality yourself.
Prevention Checklist
Before installing any AI coding skill:
- Read the complete manifest and permission requests
- Verify the skill runs in an isolated environment
- Confirm version pinning is enabled (no auto-updates)
- Document why each requested permission is necessary
- Set up logging for skill activity
- Establish a review process for skill updates
- Test the skill in a sandbox before production use
- Define monitoring alerts for unexpected behavior
- Create an incident response plan for compromised skills
- Schedule quarterly reviews of all installed skills
After installation:
- Monitor network connections initiated by skills
- Audit file access patterns weekly
- Review execution logs for anomalies
- Verify skills aren't accessing credentials or secrets
- Check for unauthorized command execution
- Confirm skills operate within their declared scope
The AI coding agent supply chain is new, but supply chain security principles aren't. Apply the same rigor you use for third-party dependencies, API integrations, and infrastructure access. Runtime verification isn't optional anymore. It's the only way to know what's actually running on your machines.
