mcp claude-code security

MCP Security: What Claude Code Users Need to Know

Drakon Systems · 8 February 2026 · 6 min read

If you're using Claude Code, you've probably added MCP servers. Maybe a memory system. Maybe GitHub integration. Maybe a database connector. They're incredibly useful — and they have direct access to your system.

MCP (Model Context Protocol) is Anthropic's standard for connecting AI assistants to external tools and data sources. It's powerful. It's also a trust boundary that most users don't fully understand.

Let's fix that.

What MCP Servers Can Do

When you add an MCP server to your Claude Code configuration, you're granting it significant capabilities:

  • Read and write files on your system
  • Execute commands in your shell
  • Make network requests to any endpoint
  • Access environment variables (including secrets)
  • Store persistent data that influences future sessions

This isn't a bug — it's by design. MCP servers need these capabilities to be useful. A file search server needs to read files. A git server needs to run git commands. A memory server needs to persist data.

The question is: do you trust every MCP server you've installed?

The Trust Problem

Most MCP servers are open source. You can audit the code. But realistically, how many developers actually read through every dependency before running npx?

Consider the attack surface:

1.
Malicious MCP Server
An attacker publishes a useful-looking MCP server with hidden backdoor functionality
2.
Supply Chain Compromise
A legitimate MCP server's dependency gets hijacked (like the event-stream incident)
3.
Data Exfiltration
An MCP server quietly sends your code, secrets, or conversation history to an external endpoint
4.
Memory Poisoning
A memory MCP server stores malicious instructions that influence Claude's behaviour in future sessions

Memory Systems: A Special Case

Memory MCP servers deserve extra scrutiny. Unlike a file search server that just reads data, a memory server persists information that shapes future interactions.

If an attacker can write to your memory system — either through a compromised MCP server or by injecting content that gets saved — they've achieved persistent influence over your AI assistant.

This is the "memory poisoning" attack vector we've written about previously. It's particularly relevant for Claude Code users because:

  • Claude Code processes code from many sources (repos, npm packages, Stack Overflow)
  • Developers often grant extensive permissions for productivity
  • Coding assistants handle sensitive data (API keys, infrastructure details, business logic)
  • Memory persistence means attacks have long-term impact

Practical Security Measures

1. Audit Your MCP Configuration

Check what's in your ~/.claude/settings.json:

cat ~/.claude/settings.json | jq '.mcpServers'

For each server, ask:

  • Do I actually use this?
  • Who maintains it?
  • When did I last check for updates?
  • What permissions does it need vs what it has?

2. Prefer Established Packages

When choosing MCP servers:

  • Check npm download counts and GitHub stars
  • Look for active maintenance (recent commits, issues addressed)
  • Prefer packages from known organisations
  • Be wary of brand-new packages with minimal history

3. Use Defence Layers for Memory

If you're using a memory MCP server, add a security layer. ShieldCortex provides:

  • Input scanning — Blocks prompt injection and encoded payloads before they reach storage
  • Trust scoring — Weights memories by source reliability
  • Sensitivity detection — Catches secrets and PII
  • Audit logging — Full forensic trail of memory operations
npm install -g shieldcortex
npx shieldcortex setup

4. Review Permissions Regularly

Claude Code's permission system exists for a reason. Don't auto-approve everything:

  • Check what tools are being called and why
  • Be cautious with Bash(*) wildcards
  • Consider per-project permission profiles

5. Monitor for Anomalies

Keep an eye on:

  • Unexpected network traffic from MCP processes
  • Unusual file access patterns
  • Memory content that doesn't match what you've discussed
  • Claude behaving differently than expected (possible memory poisoning)

The ShieldCortex Approach

We built ShieldCortex because we use Claude Code daily at Drakon Systems. We run MCP servers for memory, file access, and custom integrations. We needed a way to trust that workflow without blindly hoping nothing malicious gets through.

ShieldCortex acts as a security middleware for AI agent memory:

  • Universal — Works with any MCP-compatible agent (Claude Code, OpenClaw, Moltbot)
  • Transparent — Scans without changing your workflow
  • Auditable — Every memory operation is logged
  • Open source — Inspect the code yourself

The core defence pipeline is free. Because MCP security shouldn't be a premium feature.

Key Takeaways

  • MCP servers have significant system access — treat them like any other privileged software
  • Memory systems are particularly sensitive because they enable persistent attacks
  • Audit your MCP configuration regularly
  • Prefer established, actively maintained packages
  • Add defence layers for memory systems
  • Don't auto-approve permissions blindly

GitHub: github.com/Drakon-Systems-Ltd/ShieldCortex

Docs: shieldcortex.ai/docs

ShieldCortex is open source under the MIT licence. Built by Drakon Systems.