The $100 Prompt Injection: What MCP Security Testing Looks Like in Practice

In January 2026, a developer posted on r/webdev about losing $100. Not to a phishing email. Not to a compromised credential. To a prompt injection hidden inside an image that was processed by an MCP-connected tool with access to their Stripe account. The post gathered attention quickly — 57 upvotes and a growing comment thread of developers realizing that AI tooling had quietly introduced an attack surface they had not accounted for.

This was not a theoretical vulnerability in an academic paper. It happened to a real person, building a real product, using mainstream AI development tools.

What Actually Happened

The attack chain is straightforward once you break it down, and that simplicity is exactly what makes it dangerous.

The developer was using an LLM-based development tool connected to several MCP servers. One of those MCP servers had Stripe integration — it could create charges, issue refunds, and manage subscriptions through tool calls. This is a common setup. MCP servers are designed to give LLMs the ability to take actions in the real world, and payment processing is a natural use case.

At some point during a workflow, the developer processed an image. That image contained a prompt injection — text instructions embedded in the image data that are invisible or nearly invisible to a human viewer but are extracted and interpreted by a multi-modal LLM. The embedded instructions told the model to initiate a Stripe payment.

Here is how the attack chain played out step by step:

1. Image ingestion. The user uploaded or referenced an image as part of their workflow. This could have been a screenshot, a design mockup, or any visual asset.
2. Multi-modal processing. The LLM processed the image using its vision capabilities. Along with the visible content, it also extracted the hidden text instructions embedded in the image.
3. Instruction following. The LLM treated the injected instructions as part of its context. Because the instructions were framed as a task — create a Stripe charge — the model generated the appropriate tool call.
4. MCP tool execution. The MCP server received the tool call request, validated that the function signature was correct, and executed the Stripe API call. There was no additional authorization gate between the model’s output and the tool’s execution.
5. Money moved. A $100 charge was created. By the time the developer noticed, the transaction had already been processed.

Each step in isolation is not surprising. Multi-modal models process images. LLMs follow instructions. MCP tools execute API calls. The vulnerability is in the composition — in the fact that an untrusted input (an image) could traverse the entire chain from ingestion to real-world financial action without a single authorization checkpoint.

Why MCP Makes This Worse

The Model Context Protocol is an open standard that lets LLMs interact with external systems through structured tool calls. Think of it as a standardized way for an AI model to call functions — read a database, send an email, query an API, create a payment, modify a file. MCP servers expose these capabilities, and MCP clients (the LLM-powered applications) consume them.

Before MCP and similar tool-use frameworks, prompt injection was primarily a text-output problem. If you could inject instructions into an LLM’s context, the worst case was usually that the model would generate misleading text, leak parts of its system prompt, or produce content that violated its safety guidelines. Concerning, but bounded.

MCP removes that boundary.

When an LLM has tool-use capabilities, a successful prompt injection does not just produce bad text. It produces bad actions. The model generates a structured tool call — a JSON object with a function name and parameters — and the MCP server executes it. The attack surface is no longer limited to what the model can say. It extends to everything the model can do.

Consider what a typical MCP-connected development environment might have access to: file system operations, database queries, HTTP requests, payment processing, email sending, cloud infrastructure management, CI/CD pipelines. Each of these is a potential target for an injected instruction.

And the injection vectors are expanding. It is not just adversarial text in a prompt. It is hidden text in images, malicious content in documents retrieved through RAG pipelines, poisoned data in third-party APIs, and compromised content in web pages that the model is asked to summarize. Every source of input that the LLM processes is a potential injection point, and every tool connected through MCP is a potential target.

How We Test MCP Implementations

At Appsecco, we have developed a structured methodology for testing MCP implementations. This is not a checklist you run once — it is a systematic assessment across five phases that maps the full attack surface and validates controls at each layer.

Phase 1: Direct Injection Testing

We start with the model itself. Direct injection testing targets the LLM’s instruction-following behavior through adversarial prompts delivered directly to the model’s input.

This includes jailbreak attempts to override safety guidelines, system prompt extraction to understand what instructions and constraints the model operates under, and guardrail bypass testing to identify where content filters and safety mechanisms can be circumvented. The goal is to establish a baseline: how resilient is the model to adversarial input when attacked directly?

Phase 2: Indirect Injection Testing

Indirect injection is where the real-world risk lives. Instead of injecting instructions through the primary input channel, we target secondary data sources that the model processes.

We test RAG pipeline poisoning — injecting adversarial content into the documents and data sources that feed the model’s retrieval-augmented generation system. We test multi-modal injection by embedding instructions in images, PDFs, spreadsheets, and other documents that the model processes. We test third-party content injection by manipulating data from external APIs, web pages, and other sources that the model consumes as context.

The $100 Stripe incident was an indirect injection through an image. This phase is designed to find exactly that class of vulnerability before an attacker does.

Phase 3: Tool and Function Call Injection

This phase targets the MCP layer directly. We attempt to trigger unauthorized tool calls through injected content — can we make the model call a tool it should not call, or pass parameters that bypass authorization?

We test parameter injection by manipulating the arguments passed to tool calls. Can an injected instruction modify a database query to exfiltrate data? Can it change a payment amount or recipient? We test authorization bypass by attempting to invoke tools that should require additional permissions or human approval. We test tool chaining by constructing multi-step attack sequences where the output of one tool call feeds into another.

Phase 4: Multi-Modal Attack Vectors

Building on Phase 2, this phase provides deep testing specifically for multi-modal injection. We use techniques including steganographic text embedding in images, instruction injection in document metadata, cross-modal attacks where visual content triggers tool actions in unexpected ways, and adversarial image generation designed to maximize injection success rates across different model architectures.

This is the exact attack class that cost the r/webdev developer $100. We test it systematically across every image format, document type, and media input that the MCP implementation accepts.

Phase 5: Production Monitoring Assessment

Security does not end at deployment. We assess the monitoring and detection capabilities around the MCP implementation.

Does the system have anomaly detection for unusual tool-call patterns? Are all tool invocations logged with sufficient detail for forensic analysis? Are there human-in-the-loop controls for high-risk actions like payments, data deletion, or infrastructure changes? Can the system detect and alert on prompt injection attempts in real time?

We evaluate these controls and provide specific recommendations for gaps.

What Security Teams Should Do Now

If your organization is deploying MCP-connected AI tools — or any LLM with tool-use capabilities — here are five things you should prioritize immediately.

Audit all MCP tool permissions. Apply least privilege rigorously. If an MCP server has access to Stripe, does it actually need the ability to create charges, or does it only need read access? Every tool permission is attack surface. Remove what is not strictly necessary.

Implement human-in-the-loop controls for high-risk actions. Payments, data deletion, infrastructure changes, email sending — any action with significant real-world consequences should require explicit human approval before execution. The model can propose the action; a human should confirm it.

Add tool-call authorization with explicit allow-lists. Do not rely on the model’s judgment about which tools to call. Implement server-side allow-lists that restrict which tool calls are permitted in which contexts. If a workflow involves image processing, it should not be able to invoke payment tools.

Monitor for anomalous tool usage. Establish baselines for normal tool-call patterns and alert on deviations. A development assistant that suddenly starts making Stripe API calls is exhibiting anomalous behavior that should trigger an immediate alert.

Test with real attack scenarios before production. Do not wait for an incident. Run adversarial testing against your MCP implementation using the same techniques that attackers will use. Image-based injection, RAG poisoning, parameter manipulation — test them all in a controlled environment.

Getting Started

We built the pentesting-mcp-servers-checklist as an open source resource for security teams evaluating MCP implementations. It covers the full scope of what to test and how to approach it. We also maintain the vulnerable-mcp-servers-lab, a deliberately vulnerable MCP environment for hands-on security training and testing.

If you need a thorough security assessment of your MCP implementation, that is exactly what our MCP pentesting service is designed for. The $100 incident was one developer and one tool. The stakes in production enterprise environments are considerably higher.