Table of Contents
- Introduction
- MCP does not create entirely new risks. It operationalizes old risks in a new way..
- Why agent toolchains expand the attack surface
- The real risk is chained behavior, not isolated flaws
- Why teams need realistic MCP training environments
- What an MCP AppSec playbook should include
- Conclusion
Introduction
AI agents are no longer limited to answering questions. In 2026, they are being connected to business systems, internal APIs, files, workflows, and execution environments through protocols like MCP, the Model Context Protocol. That changes the security conversation in a fundamental way.
Traditional AppSec assumes a human or script is directly calling an application endpoint. MCP introduces a different operating model: an LLM can discover tools, inspect resources, maintain session state, and chain actions across multiple systems. The result is not just “another API.” It is an agent-facing control plane for application behavior.
That distinction matters. In Broken Crystals, the MCP endpoint at /api/mcp exposes a JSON-RPC interface for tool calling, supports separate MCP session initialization, and offers both public and role-restricted tools. Those tools do not just perform benign lookups. They proxy sensitive application capabilities such as SQL-backed queries, configuration access, XML processing, local file reads, server-side template rendering, user search, and even command execution. In other words, familiar vulnerabilities do not disappear in an AI workflow. They become easier for agents to discover, invoke, and combine.uest is not scanning GraphQL. It’s scanning the doorway and ignoring the building behind it.
MCP does not create entirely new risks. It operationalizes old risks in a new way.
This is the first thing decision makers need to understand. MCP is not dangerous because it invented SQL injection, XXE, server-side template injection, or command injection. It is dangerous because it packages business actions and backend capabilities into a structured, discoverable interface that an autonomous system can use at machine speed.
A traditional vulnerable endpoint may require an attacker to reverse engineer routes, parameters, and behavior. An MCP server often does the opposite. It tells the client which tools exist, what they are called, what arguments they take, and which resources can be read. That is a feature for usability, but it also lowers the cost of misuse.
In Broken Crystals, the exposed MCP surface includes public tools such as get_count, render, process_numbers, get_metadata, search_users, and update_user, plus admin-only tools like get_config and spawn_process. The attack surface is not hidden behind obscure routes. It is organized, named, and ready for invocation.
Why agent toolchains expand the attack surface
The biggest shift is not the protocol itself. It is the combination of protocol, autonomy, and backend reach.
First, MCP makes backend functionality composable. A tool is not just an endpoint; it is a capability the agent can plan around. A model that can list tools, choose one, inspect the result, and choose the next step behaves very differently from a browser user clicking through a UI. That creates a larger practical attack surface, even when the underlying bugs are old.
Second, MCP adds a new trust boundary. In Broken Crystals, MCP sessions are initialized separately from the regular application flow, use their own Mcp-Session-Id, and can exist in guest, authenticated-user, or admin contexts. That means security teams now have another session model to reason about. If agent sessions, tool permissions, and backend authorization do not line up exactly, gaps appear.
Third, agent toolchains create proxy risk. Several MCP tools in this project simply forward data into existing application functionality: SQL queries into a count endpoint, XML into metadata parsing, file paths into a raw file reader, and search terms into user lookup logic. This is a pattern security leaders should expect in real deployments. Teams often build agent features by wrapping legacy capabilities, not redesigning them. If the original function was unsafe, the MCP wrapper can turn it into an agent-ready exploit primitive.
Fourth, MCP changes observability requirements. Broken Crystals includes event-stream responses for tools like render and spawn_process, with progress notifications and partial output streamed back to the client. That means security telemetry can no longer focus only on simple request-response patterns. Long-running tool calls, streamed output, and multi-step session activity all need to be logged and reviewed as first-class security events.
The real risk is chained behavior, not isolated flaws
Security teams are used to cataloging vulnerabilities one by one. Agents do not operate that way.
An agent can start with tools/list, identify accessible tools, establish whether it has a guest or authenticated session, read from resources/list, and then move into more sensitive actions. A public file-read capability, a user-enumeration tool, a templating function, and an admin-only configuration tool may each look manageable in isolation. Together, they create a meaningful attack path.
That is why MCP needs its own AppSec playbook. The question is no longer only “Is this endpoint vulnerable?” It is also “What can an agent discover, call, chain, persist, and exfiltrate from this integration layer?”
A useful way to frame the difference is this:
| Traditional API risk | MCP risk |
| Endpoint-by-endpoint exposure | Capability-based exposure |
| Hidden or undocumented routes may slow attackers | Tool and resource discovery is built in |
| Mostly stateless request flow | Separate session lifecycle and identity context |
| One response per call | Streaming, notifications, and partial output |
| Human-crafted attack logic | Agent-driven multi-step planning |
Why teams need realistic MCP training environments
This is the operational takeaway. Most organizations are not ready to secure MCP by reading a checklist.
They need environments where developers, AppSec teams, and platform owners can see how these failures actually happen. A toy prompt injection demo is not enough. Real MCP risk appears when a model can initialize a session, enumerate tools, call backend proxies, switch between guest and authenticated contexts, interact with streamed responses, and reach vulnerable business logic through an agent-friendly interface.
Broken Crystals is useful precisely because it models that reality. It is not just a vulnerable API. It is a benchmark application with a dedicated MCP surface, public and restricted tools, resource access, session handling, and end-to-end security tests. The included MCP tests show how teams can validate session behavior, role checks, file reads, server-side execution paths, and even automated security scans directly against MCP workflows.
That is the kind of training ground teams need in 2026. Without it, they are likely to secure the chatbot UI while leaving the agent integration layer under-tested.
What an MCP AppSec playbook should include
MCP security does not require a brand-new security program, but it does require an expanded one.
- Treat every MCP server as a production application surface, not as middleware.
- Inventory every tool, resource, backend proxy, session flow, and permission boundary.
- Apply least privilege at the tool level, not just at the application level.
- Review any tool that wraps file access, templating, XML parsing, shell execution, search, or configuration retrieval as high risk by default.
- Monitor initialize, tools/list, resources/list, streamed responses, and unusual tool-chaining patterns.
- Test MCP directly in CI and in training labs, instead of assuming REST or GraphQL coverage is enough.
The main point is simple: if agents can use it, attackers can target it.
Conclusion
MCP is becoming an important integration layer for AI agents because it makes tools easier to expose and easier to use. That same convenience changes the security model. It turns familiar application weaknesses into discoverable, callable, chainable agent actions.
For decision makers, the mistake to avoid in 2026 is treating AI agent security as a prompt-layer problem only. Once an agent can access tools, resources, sessions, and backend workflows, the issue becomes application security again, just with a faster and more composable execution model.
Teams that build realistic MCP training environments now will be in a much stronger position to deploy agent features safely. Teams that do not will learn the hard way that agent integrations need more than model guardrails. They need their own AppSec playbook.
