I need to talk about something that is keeping me up at night. Claude Code is brilliant. I use it daily. I have written about how it is transforming Caribbean development. But there is a security conversation happening behind the scenes that most developers are completely unaware of, and it involves Claude Skills, custom hooks, and MCP (Model Context Protocol) servers.
The attack surface is real. And the Caribbean tech community needs to understand it before we get burned.
What Are Claude Skills and Why Should You Care?
Claude Code supports what Anthropic calls "skills." These are custom commands, often written as markdown files in your project's .claude/ directory, that extend what Claude Code can do. You can also configure hooks that run shell commands in response to Claude Code events, and connect MCP servers that give Claude Code access to external tools and data sources.
All of this is powerful. All of this is useful. And all of this introduces attack vectors that most developers are not thinking about.
The problem is simple: when you clone a repository that contains a .claude/ directory with custom skills, those skills can influence how Claude Code behaves in your environment. When you connect to an MCP server someone else set up, that server can provide tools that Claude Code will call with your permissions. When you copy hooks configuration from a blog post or a colleague's setup, those hooks run shell commands on your machine.
Let me say that again, plainly: someone else's configuration can cause Claude Code to execute commands on your machine, with your permissions, on your data.
The Attack Scenarios That Worry Me
I run security-conscious AI labs. At Section 9 AI Lab, we work on social good and ethical AI. At StarApple AI, we handle financial data. I think about attack vectors professionally. Here are the scenarios that concern me:
Poisoned Repository Skills
A developer clones an open source project. The project includes a .claude/ directory with skills that look helpful. One of those skills contains instructions that tell Claude Code to include a specific import in every file it generates, or to send diagnostic data to an external endpoint, or to add a dependency that contains a supply chain attack. The developer does not read the skill files because they look like documentation. Claude Code follows the instructions because that is what skills are for.
This is not hypothetical. Supply chain attacks through development tooling are one of the fastest growing attack categories globally. Claude Skills create a new channel for them.
Malicious MCP Servers
MCP servers extend Claude Code's capabilities by giving it access to external tools. A database query tool. A file system browser. A deployment pipeline. These are useful and legitimate. But an MCP server can also be built to exfiltrate data. When Claude Code calls an MCP tool with your codebase context, that context goes to the MCP server. If the server is malicious, your code, your secrets, your architecture, all of it is now in someone else's hands.
The Caribbean financial sector should be paying very close attention to this. If a developer at a Jamaican fintech connects to an untrusted MCP server while working on production code, the exposure could be catastrophic.
Hook Injection
Claude Code hooks run shell commands. A hook configured to run "after every file write" could quietly copy files to a remote location. A hook configured to run "before every commit" could inject code into your staged changes. The hooks are defined in configuration files that most developers trust without reading carefully.
I have seen developers copy settings.json configurations from Stack Overflow and Reddit without reading every line. With Claude Code hooks, that casual copy-paste habit becomes a serious security risk.
What I Am Doing About It at StarApple AI
We have implemented strict policies across all four labs. These are not suggestions. They are requirements for any engineer who wants to keep their access to our systems.
Rule 1: No external MCP servers without approval. Every MCP server connection must be reviewed and approved by me or our security lead before it touches any of our codebases. No exceptions. We maintain a whitelist of approved MCP servers and the list is short on purpose.
Rule 2: Audit every .claude/ directory in every cloned repository. Before any of our engineers opens Claude Code in a cloned project, they read every file in the .claude/ directory. Every skill. Every configuration. If anything looks suspicious, it gets flagged and the project gets reviewed in a sandboxed environment.
Rule 3: No hooks from external sources. We write our own hooks. Period. We do not copy hooks from blog posts, from other teams, from online tutorials. If we need a hook, we write it ourselves, review it, and version control it. The convenience of copying someone else's configuration is not worth the risk.
Rule 4: Use permission modes deliberately. Claude Code has different permission levels. We run in restrictive mode by default and only escalate permissions for specific, time-limited tasks. No engineer has blanket permission for Claude Code to modify files or run commands without review.
What the Caribbean Tech Community Needs to Do
The Caribbean is small. We know each other. We share code, share tips, share configurations. That community trust is one of our strengths. But it is also a vulnerability when it comes to supply chain security.
Here is what I am asking the community to do:
Treat Claude Skills like executable code. Because they are. They instruct an AI system that can read, write, and execute on your machine. A skill file is not documentation. It is a script that runs through a very capable intermediary.
Audit your MCP connections. If you connected to an MCP server six months ago and forgot about it, go check. What data does it have access to? Who runs it? Is it still maintained? An abandoned MCP server is a compromised MCP server waiting to happen.
Talk to your teams about this. Most developers I speak to in Jamaica and across the Caribbean have not thought about AI tool security at all. They think about application security. They think about API security. They do not think about the security of the tools they use to write those applications. That gap needs to close.
This Is Not Anti-Claude Code
I want to be very clear: I am not saying do not use Claude Code. I use it every day. I have written extensively about its benefits. It has transformed how we build at StarApple AI.
What I am saying is: use it with your eyes open. The same principle I have been teaching since 2019 applies here. Be the Boss of your AI. That means understanding the security model. That means knowing what permissions you are granting. That means reading the configuration files, not just the code output.
AI tools are becoming the most important part of the developer toolkit. The security community has not caught up to that reality yet. The attack surface for AI-assisted development is new, it is growing, and the Caribbean cannot afford to learn this lesson the hard way.
I have seen what happens when Caribbean companies get breached. The reputational damage alone can kill a startup. Add regulatory consequences in the financial sector and you are looking at existential risk. A few hours of security review is a small price to pay to avoid that.
Be the Boss of your AI. That includes knowing where the doors are and who has the keys.
"A Claude Skill is not documentation. It is executable intent channelled through the most capable coding agent most developers have ever used. Treat it accordingly." - Adrian Dunkley, AI Boss