Your marketing manager installs a ChatGPT plugin to schedule social posts. Your finance lead uses a Claude skill for reports. Your HR manager has AI screen CVs. And your developer works with Cursor for code review.
They all use “skills” - extensions that give AI systems new capabilities. And they all run the same risk: 12% of those skills are malicious. Designed to steal data, infiltrate systems, or pass your business secrets to competitors.
This is not a developer problem. This is a business problem.
What are AI skills actually?
Think of browser extensions, but for AI systems. They give your AI access to extra functionality: your CRM, your financial data, your internal wiki, your production systems.
And it’s no longer niche technology. In October 2025 Anthropic launched skills for Claude. In December OpenAI adopted them in ChatGPT and their developer tools. Google followed, Microsoft too. In January 2026 they jointly founded the Agentic AI Foundation to develop skills further as an open standard.
Skills now run in Claude, ChatGPT, Codex CLI, VS Code, GitHub Copilot, Cursor, and dozens of other tools. If your team uses AI, they are probably already using skills - whether they know it or not.
The numbers: why this is not a theoretical risk
In February 2026 Koi Security researched ClawHub, a popular skill marketplace. Of the 2,857 published skills, 341 were malicious. That is 12%.
What do those malicious skills do?
- Credential exfiltration: sending passwords and API keys to external servers
- Data theft: copying files and uploading them to attacker infrastructure
- Malware distribution: installing Atomic Stealer (AMOS) malware
- Typosquatting: imitating legitimate skill names to mislead users
OWASP’s 2025/2026 data shows why this works:
- Prompt injection ranks #1 of LLM security risks
- 20% of jailbreak attempts are successful
- A successful attack takes 42 seconds on average
- 90% of successful attacks leak sensitive data
The problem is not limited to skills alone. AI-generated code has the same vulnerabilities: 45% contain security vulnerabilities.
Why non-developers are EXTRA vulnerable
In January 2026 Anthropic launched Claude Cowork - explicitly aimed at people without programming experience. Not developers, just people who want to work with AI.
The tagline: “AI that works alongside you, no coding required.”
The problem: the same vulnerabilities as Claude Code, but now for an audience that doesn’t recognize when an AI system is compromised.
Simon Willison, security researcher, wrote in February 2026:
“I do not think it is fair to tell regular non-programmer users to watch out for ‘suspicious actions that may indicate prompt injection’!”
Anthropic’s own documentation acknowledges this:
“The chances of an attack are still non-zero.”
That is corporate-speak for: we know it can happen, but we can’t prevent it.
The Lethal Trifecta
In June 2025 Simon Willison identified what he calls “The Lethal Trifecta” - three elements that make AI systems fundamentally insecure:
- Access to private data - your customer data, financial reports, strategic plans
- Exposure to untrusted content - websites, emails, uploaded files
- The ability to communicate externally - APIs, network access, cloud services
When an AI system has all three, it becomes a perfect attack vector. And that is exactly what skills enable.
Where it goes wrong: honest about the risks
The big problem is not that a competitor steals your data. That is Hollywood.
The real problem: you don’t know where your data goes.
What happens
Your marketing manager installs a ChatGPT skill. Your finance lead uses Claude for reports. Your HR has CVs screened. All logical, all useful.
But:
- Where does that data go?
- Who has access to it?
- How long is it kept?
- Can you prove it if someone asks?
For 12% of skills the answer is: to a server you don’t know, managed by someone you don’t know, for purposes you don’t know.
Why this is a problem
You can’t prove you’re compliant. Under GDPR you must be able to demonstrate where personal data goes. If your HR tool forwards CVs to an external API, and you don’t know that, you have a problem when the Data Protection Authority comes by.
You can’t trace what happened. If there’s a data breach, you must be able to explain what was leaked and how. If you don’t know which skills saw which data, you can’t.
You have no control over your own business data. Financial reports, customer lists, strategic plans - it sits somewhere on a server. Maybe it’s resold, maybe not. You don’t know.
The costs
- GDPR fine: up to 4% of your annual revenue in case of a demonstrable data breach
- Incident response: EUR 15-40K minimum to find out what happened
- Reputational damage: customers asking questions you have no answer to
- NIS2 compliance: if you’re in scope, you must be able to demonstrate this
How to protect yourself
1. Inventory what your team uses
The biggest problem: you don’t know what’s running. Marketing uses ChatGPT plugins, sales has Cursor with custom skills, operations is experimenting with local LLMs.
Action: Ask each team what they use. Not to forbid, but to gain visibility. Shadow AI is only a problem if you don’t know it exists.
2. Central approval process
For every new skill/plugin/extension: someone has to say “yes” before it’s used.
Who decides: Not IT alone (too detached), not developers alone (don’t understand the business). It has to be someone who understands what the data is worth and what the risks are. Often that is operations, compliance, or a senior manager.
What you check:
- Where does this skill come from? (large vendor vs. random developer)
- What exactly does it do? (which data does it need?)
- Where does it run? (local, cloud, external server?)
- Are there alternatives with a better track record?
3. No sensitive data without policy
Simple rule: customer data, financial data, strategic plans don’t go into AI tools unless you know where they go.
Practical:
- Test new skills first with dummy data
- Check whether data goes to external servers (network monitoring)
- Ask yourself: if this leaks, what is the impact?
If the answer is “business-critical,” you don’t use the skill without extra security. An alternative for sensitive data: run a local LLM that doesn’t send your data to external servers.
4. Training for everyone
This is not an IT problem. This is a business problem. How you, as a team, structurally learn to work with AI is described in our step-by-step plan to become AI-native. Not just skills, AI-generated code also requires conscious choices, read about the spectrum from vibe coding to agentic coding.
Every team member should know:
- What skills are and why they can be risky
- How to recognize strange behavior (why is my AI suddenly asking for credentials?)
- Who they can turn to with questions
Important: Don’t make it scary. If people think they’ll get into trouble for being honest, they won’t tell you when they see something suspicious.
Our approach: what we do
We don’t write about things we haven’t done ourselves.
Scanning skills before we deploy them
Before we use a skill in our own systems (ibgids.nl, certificeerwijzer.nl) or at clients:
- Review the source - who built this, what is their track record?
- Code review (if open source) - what exactly does the skill do?
- Monitor the network - where does data go during use?
We have already found a skill twice that sent data to an external API without it being documented. We did not use those skills.
Team training on risk recognition
Our team knows how to recognize strange behavior:
- AI requests access to data not relevant to the task
- Skill asks for credentials or API keys
- Unexpected network activity during use
We don’t train this once, but every quarter - because attackers get better.
Layered defense
We don’t rely on one line of defense:
- Skills are checked before use
- Sensitive data doesn’t go into AI without isolation
- Network monitoring detects strange behavior
- Regular audits check what’s running
This is not paranoia, this is pragmatism.
Final thought: this won’t wait until vendors fix it
AI tools are being adopted now. Skills are being used now. Vendors know about the risks but can’t fully prevent them - Anthropic’s “non-zero risk” is honest about that.
That doesn’t mean you should avoid AI. It means you have to be aware of what you use and how.
The question is not: “Is this secure?” The question is: “Do I have visibility into what my team uses?”
If the answer is no, that’s where you start.
Want to know what your team uses and whether it’s secure? Let’s talk.