MCP with Claude: Security Risks of the New Specification

Anthropic's new Model Context Protocol (MCP) specification, launched in June 2026, shifts security responsibilities directly to developers. Previously, the protocol handled it. Now, you do.

This shift isn't new. Teams deploying Claude with MCP in production—Simple Booking in hospitality, X with its MCP servers for AI agents—are already asking: where exactly are the vulnerabilities?

The responsibility shift: where the problem comes from

The new MCP specification is enterprise-ready, sure. But that word hides a reality: Anthropic deliberately pushed some security controls down to the developer layer to gain flexibility.

Concretely, that means three things:

1. No more implicit authentication

Before, MCP included security mechanisms by default. Now, you build the authentication chain yourself. An e-commerce agency connecting Claude to a Shopify customer database must manage how a Claude agent accesses sensitive data—names, emails, phone numbers. No magic here.

2. Granular permissions become your problem

MCP no longer says "this tool can read but not write." You do. An agent could potentially execute an action it's not authorized for if you haven't set the guardrails. Simple Booking knows this dilemma: their MCP connectors integrate a CRS (Central Reservation System), directly touching customer reservations. A misconfigured permission = a reservation accidentally modified.

3. Prompt injection becomes more critical

Claude is smart, but if an MCP agent accepts an external instruction without validation—"call tool X with parameter Y"—you've just created an entry point for an attacker. Adversaries aren't trying to hack the protocol. They're trying to manipulate your agent.

Four concrete pitfalls you're running into

Pitfall 1: credentials exposed in environment variables

The classic mistake. Your MCP server needs an API key to talk to a database. You put it in .env. Fine so far. Except your Docker container or AWS Lambda function exposes these variables in logs if it crashes.

With MCP, every connection error to the server surfaces to Claude. Claude logs it. And if Claude is in debug mode or logs aren't encrypted, goodbye your key.

Mitigation: use a secrets manager (Vault, AWS Secrets Manager). Inject credentials at runtime, never hardcoded.

Pitfall 2: blind trust in the MCP server

You deploy an MCP server exposing 15 tools. Claude is connected. A junior dev adds a new tool that deletes client records. Without access review, Claude can call it.

Worse: if that server is on your internal network and someone compromises another machine on it, they can pivot to send forged MCP commands.

Mitigation: each MCP tool needs an explicit list of who can call it. Claude? Yes, but only if it meets X criteria. Audit tools regularly.

Pitfall 3: infinite timeouts that block

An MCP server responds slowly or not at all. Claude waits. Meanwhile, a user request stalls, the session stays open, memory bloats. Not a direct security flaw, but it creates DoS vectors.

Worse if intentional: someone sends a request that forces MCP to perform a very long operation (scanning a massive database, an expensive computation).

Mitigation: strict timeout on every MCP call. 5s, 10s max. No infinity.

Pitfall 4: no logging or insufficient logging

If Claude calls an MCP tool and you don't log the action, timestamp, parameters, result, you have zero traceability. A hotel agency discovering 500 canceled reservations has no trail to trace what happened.

Defenses to implement

1. Strong authentication between claude and your MCP server

MCP uses JSON-RPC over stdio or HTTP. If HTTP, use HTTPS + a valid Bearer token. Better: mTLS with client certificates.

Test: your MCP server must reject any request without valid authentication. No exceptions.

2. Role-based (rbac) or attribute-based (abac) authorization

Define explicitly who can call which tool.

Agent Role	Authorized Tools	Limited Parameters
ReadOnlyAnalyst	GetBookings, GetReviews	No sensitive parameters
ReservationManager	CreateBooking, ModifyBooking	Mods < 3 days before arrival
Admin	All	No limits

Implement this in your MCP server. Before executing a tool, check Claude's role (or more precisely, the session context using it).

3. Strict validation and sanitization

Every parameter received by MCP must be validated:

• Correct type (string, number, etc.)
• Limited length (no 10 MB text in a field)
• Format validated (a date is a date, an email is an email)
• No escaped characters that could cause SQL injection

// Example: endpoint that creates a booking
// BAD
app.post('/MCP/create-booking', (req, res) -> {
  const booking = req.body; // Direct danger
  db.insertBooking(booking);
});

// GOOD
app.post('/MCP/create-booking', (req, res) -> {
  const schema = z.object({
    clientId: z.string().uuid(),
    checkIn: z.string().date(),
    nights: z.number().min(1).max(365),
    roomType: z.enum(['single', 'double', 'suite'])
  });
  
  const validated = schema.parse(req.body); // Throws if invalid
  db.insertBooking(validated);
});

4. Exhaustive logging with context

Every MCP call must be logged with:

• Exact timestamp
• Agent identity (or context using it)
• Tool called + full parameters
• Result (success, error, exception)
• Execution duration
• Source IP address (if relevant)

Store these logs in an immutable system (CloudWatch, Splunk, or a simple append-only encrypted file).

5. Real-time monitoring and alerts

Detect anomalies:

• Too many calls to a tool in short time -> DoS attempt
• Tool called with abnormal parameters -> fuzz attack
• Repeated errors -> reconnaissance or vuln scanning

Configure an alert if Claude calls "GetUserData" 100 times in 30s.

Case study: X and its MCP servers

X (formerly Twitter) launched MCP servers so Claude, Cursor, Grok Build, and other AI tools can access X directly. Same logic as Simple Booking and hotel reservations.

The difference: data on X is public by default. An agent can fetch tweets without harm. But if you had an X MCP server exposing private DMs or internal analytics, the scenario flips entirely.

Anthropic and X assumed developers integrating these servers would know to set barriers. Spoiler: not always the case.

Conclusion

Anthropic's new MCP specification is more flexible but less safe by default. Security is no longer baked in. It depends on you.

Three reflexes to adopt:

1. Strong authentication between Claude and MCP, HTTPS + tokens, mTLS if possible.
2. Granular authorization, each tool has an explicit list of who can call it and how.
3. Complete observability, every call is logged, auditable, alertable.

If you deploy MCP in production without these three pillars, you're playing Russian roulette. And spoiler: the bullet will eventually be in the chamber.

Need help securing your MCP implementation? Let's talk about your architecture at fstck.co—we have real cases in hospitality, e-commerce, and fintech.