Otto Support – An MCP, Agentic-AI Security Challenge

TL;DR; Bishop Fox built a vulnerable MCP-based customer support system where your AI assistant interacts with tools, services, and local resources, then challenges you to escalate access, exfiltrate data, and execute code. 

This hands-on CTF simulates real-world AI agent attack surfaces, requiring a mix of tool abuse, prompt manipulation, and source code analysis to uncover how modern MCP architectures fail in practice.

We built a vulnerable Model Context Protocol (MCP) server and packaged it as a customer support tool. Your AI assistant, such as Claude Code, connects to it, discovers available tools, and starts helping you work tickets.

From there, the challenge begins.

The otto-support capture-the-flag (CTF) is a set of hands-on AI security challenges that simulate how modern AI agents interact with tools, internal services, and local environments. As you progress, you’ll move across multiple privilege levels, uncover new capabilities, and attempt to escalate access – ultimately aiming to exfiltrate sensitive data, access other users’ information, and execute code on the underlying system.

The CTF is a single Go binary that runs as an MCP server inside a container and uses your AI coding client for interaction. The CTF ships with a tiered authentication system, internal services, a ticket database, and 19 tools spread across four privilege levels. otto-support has attack surfaces that span MCP tool interactions at different trust levels mixed with web application vulnerabilities. The CTF will likely need to be completed with a combination of dynamic testing and reading source code, underscoring the importance of source code during the assessment of generative AI business solutions.

The challenge is designed for security engineers, red teamers, and developers working with AI agents, MCP-based systems, and AI coding assistants who want to understand how these architectures introduce new and often overlooked attack surfaces.

What MCP Is & Why It Changes the Attack Surface

The MCP allows AI agents to interact with external tools, services, and local system resources. Instead of only generating text, AI systems using MCP can:

• Call tools and APIs
• Access local files and environment variables
• Interact with internal services
• Take actions on behalf of the user

In traditional applications, risk is often limited to data exposure or input validation issues. With MCP-enabled systems, AI agents can execute actions inside real environments, often with inherited access to credentials, system data, and internal services.

This creates new security risks, including:

• Untrusted input influencing tool execution
• AI-generated decisions triggering real-world actions
• Local environments becoming part of the attack surface
• What These Challenges Simulate in the Real World

What These Challenges Simulate in the Real World

The otto-support CTF mirrors how AI systems are increasingly deployed in enterprise environments.

The MCP server functions like an internal copilot or service. Its tool ecosystem reflects how plugins and integrations extend AI capabilities, while the privilege tiers model real identity and access boundaries. Running inside a container simulates a developer workstation or agent runtime, where AI assistants often operate with access to local resources.

This setup is no longer hypothetical. Many organizations already run:

• AI coding assistants connected to internal systems
• Local agents with access to credentials and services
• Third-party tools operating with broad permissions

The result is an attack surface that blends application security, identity, local system exposure, and AI-driven decision-making.

What You’ll Learn from These Challenges

This CTF is designed to show how MCP-based systems fail in practice. By working through it, you will:

• Identify and exploit privilege escalation paths through tool discovery
• Exfiltrate data across trust boundaries using MCP tools
• Manipulate AI assistants into performing unsafe or unintended actions
• Combine source code review with runtime interaction to validate vulnerabilities
• Recognize how local environments expand the attack surface

Getting the CTF Ready

The repository is public on Github, and reading the source is encouraged; some paths may require it. Get otto-support: github.com/BishopFox/otto-support.

The challenge is designed so that interactive exploitation with generative AI and code review reinforce each other. Something that may look like a vulnerability in the source can be confirmed more easily once the runtime context is understood. Some paths may require convincing your AI assistant to do something it would rather not.

Setup Instructions

There are two ways to run the CTF environment depending on how you prefer to work:

• Option A (Recommended): Run in a container
• Option B: Run directly on your host

Both approaches launch Claude Code with an MCP server but how that server interacts with your environment matters more than it might seem.

Here are some brief instructions to download and run the CTF after obtaining a token with claude setup-token:

# download from GitHub 
git clone https://github.com/BishopFox/o... 
cd otto-support 
# use your containerization solution of choice to build the container 
podman build -t otto-support . 
# run claude setup-token to get the token used here and run the container with it 
podman run -it -e CLAUDE_CODE_OAUTH_TOKEN="$CLAUDE_CODE_OAUTH_TOKEN" otto-support

Figure 1 - Downloading and running the CTF

Claude Code launches inside the container with the MCP server already configured. You begin as a new user with limited tools.

Interacting with otto-support

Once the CTF environment is running, you’ll begin exploring the MCP server through your AI assistant.

First steps:

• Observe available tools
• Authenticate and gain access to additional capabilities
• Identify new tools as privileges expand

From there, the goal is to push beyond your assigned permissions, whether by abusing tools, manipulating the assistant, or identifying vulnerabilities in the underlying system. Choose your own adventure.

Further instructions are located in the repository, so you can jump in and start playing now, or continue reading for more context on real-world MCP vulnerabilities and how they shaped the design of this CTF.

Reasons to Isolate Local MCP Servers

We run this CTF inside a container to isolate it from the host’s environment. This allows a clean slate where we have to be intentional about what information we expose inside the container. Why is this?

stdio MCP servers inherit the parent process's full environment, which can include environment variables, the filesystem, local configurations, and other system data. The attack surface compounds when one considers what runs locally on a developer's machine, such as debugging proxies, AI agent frameworks, and other rogue software that bind to select network interfaces depending on their configuration.

Let’s look at a few case studies to see why running MCP servers outside of an intentionally configured environment can be a bad idea.

Case Studies: Real MCP-Like Failures

Drive-By Localhost Breach via MCP Inspector

Date: June 2025 (CVE-2025-49596, CVSS 9.4 Critical)

MCP Inspector, a popular debugging tool for monitoring AI agent communications with 78,000+ weekly downloads, exposed a proxy endpoint that accepted unauthenticated requests from any origin. Attackers could scan for predictable localhost ports and issue requests that executed MCP commands. This was a drive-by browser attack with no user interaction needed; it only required visiting a webpage to achieve remote code execution on the agent’s host. Attackers could steal sensitive data, install persistent backdoors, intercept and modify tool calls flowing through any connected AI agent, and move laterally across enterprise networks.

How this maps to the CTF:

otto-support includes internal services and tool interactions that rely on implicit trust and local access, mirroring how exposed local services can be abused.

OpenClaw AI: Unauthenticated Control Panels and Prompt Injection

Date: January 2026 (CVE-2026-22708)

OpenClaw is an open-source AI agent framework that gained popularity early in 2026 for its user-friendly interface and social integrations. Agents were configured to store plaintext API keys on the local filesystem and suffered from prompt injection through the framework's allowUnsafeExternalContent setting (CVE-2026-22708) that let attackers trick agents into running shell commands.

Another relevant security angle here is the ClawHub skill marketplace, where third-party skills operate as trusted extensions with full access to the agent's environment. Researchers identified malicious skills on ClawHub that collected sensitive data and phoned home to attacker-controlled infrastructure while returning normal results to the user. The framework's sandboxing was available but defaulted to off and third-party marketplace plugins bypassed it entirely.

OpenClaw is not an MCP server. But strip away the branding and the architecture is identical: a local process with ambient credential access, a plugin ecosystem with no review system or code signing, and a tool execution model that treats retrieved content as instructions.

How this maps to the CTF:

otto-support’s multi-level tool system and internal services reflect the same trust assumptions and attack paths, particularly around tool misuse and implicit trust in execution.

Mitigating Local MCP Server Risks

Limiting the presence of local MCP servers on a user's system is a difficult control to implement thoroughly. MCP servers can run on the host, in a container, or remotely which make servers difficult to detect. Instead, organizations should focus on controlling how they are used.

Educating users on how to use the technology properly, in a way that maintains the desired security posture, is the way forward. This could be a dedicated environment that these tools run in or specific system configurations that users must use. This includes enforcing a minimal processing environment where only the needed credentials and tools are present and using containerization approaches that prevent direct host interaction. Having approved, internal-only marketplaces with vetted plugins that users can trust can also help prevent malicious local MCP servers from being introduced to your environment.

Recommended approaches include:

• Isolated execution environments: Run AI agents and MCP servers in controlled, minimal environments
• Reduce ambient access: Limit available credentials, services, and filesystem exposure
• Harden tool ecosystems: Use vetted, internally approved plugins and integrations
• Enforce least privilege: Ensure tools and services only expose necessary functionality
• Educate users and developers: Make clear how these systems introduce new attack paths

The goal is not elimination; it’s containment and intentional exposure.