Skip to main content

​
What is MCP?

The Model Context Protocol (MCP) is an open standard that lets AI agents communicate with external tools and data sources through a client-server architecture. An MCP client (the AI agent or its host) connects to one or more MCP servers, each of which exposes tools (callable functions), resources (readable data), and prompts (reusable templates). Because MCP servers execute real actions — running commands, querying databases, writing files — they are a direct attack surface for agent infrastructure.

​
OWASP MCP Top 10

The OWASP MCP Top 10 is a vulnerability taxonomy for MCP-based systems, maintained by the OWASP Foundation. q-ai maps all audit findings to these categories.
IDVulnerability
MCP01Token Mismanagement & Secret Exposure
MCP02Privilege Escalation via Scope Creep
MCP03Tool Poisoning
MCP04Software Supply Chain Attacks
MCP05Command Injection & Execution
MCP06Prompt Injection via Contextual Payloads
MCP07Insufficient Authentication & Authorization
MCP08Lack of Audit & Telemetry
MCP09Shadow MCP Servers
MCP10Context Injection & Over-Sharing

​
Transport types

MCP defines three transport mechanisms for client-server communication.
TransportDescriptionUse case
stdioServer spawned as a child process, communication over stdin/stdoutLocal development, CI pipelines, testing servers you can run directly
SSEServer-Sent Events over HTTP (legacy transport)Remote servers using the older SSE-based MCP protocol
Streamable HTTPBidirectional HTTP transport (current standard)Remote servers using the current MCP transport specification
See Transport Types for configuration details per module.

​
Threat model

q-ai tests agent infrastructure — the servers, tools, and trust boundaries that AI agents interact with — not just model outputs. The assumption is that MCP servers are untrusted components: they may leak secrets, execute injected commands, poison tool descriptions, or over-share context across sessions.

​
Module methodologies

​
Audit, Proxy, Inject, Chain — MCP infrastructure testing

The audit module scans MCP servers by enumerating exposed tools, resources, and prompts, then running security checks mapped to the OWASP MCP Top 10. Proxy intercepts live MCP traffic between client and server for inspection and replay. Inject tests whether AI agents comply with poisoned tool descriptions. Chain composes multi-step attack sequences across modules.

​
IPI — Generate, Deploy, Track

IPI has an active attack chain with callback-based proof of execution:
  1. Generate — Create documents with hidden payloads, registered as campaigns with unique tokens
  2. Deploy — Place payloads where the target AI will ingest them
  3. Track — The callback listener captures HTTP requests from agents that execute the instruction
Unlike output-analysis approaches that inspect what an AI says, IPI proves what an AI does by detecting out-of-band callbacks triggered by hidden instructions.

​
CXP — Build, Test, Record

CXP is a research harness where the researcher drives the test:
  1. Build — Assemble a context file from clean base templates + researcher-selected insecure coding rules via the interactive TUI
  2. Test — Open the generated repo in a coding assistant, issue a trigger prompt, capture the output
  3. Record — Store results in the evidence pipeline with validation against detection rules

​
RXP — Embed, Query, Score

RXP measures retrieval behavior without connecting to live systems:
  1. Embed — Encode corpus and poison documents into vectors using an embedding model
  2. Query — Run target queries and retrieve top-k results from an ephemeral collection
  3. Score — Measure poison document retrieval rate and rank across models
RXP validates the retrieval prerequisite for content injection — if a poisoned document can’t win the vector similarity battle, it never reaches the LLM context window.

​
Callback-based verification

Each IPI campaign generates a unique callback URL containing a cryptographic token: 
http://<listener>:8080/c/<campaign-uuid>/<token>
When an AI agent executes the hidden instruction, it fires an HTTP request to this URL. The listener records the hit and assigns a confidence level:
ConfidenceCriteriaInterpretation
HIGHValid campaign token presentStrong proof of agent execution — the token could only have come from the specific payload
MEDIUMNo/invalid token, but programmatic User-Agent (python-requests, httpx, curl, etc.)Likely agent execution, but without token proof
LOWNo/invalid token and browser/scanner User-AgentNoise — likely a human click, web crawler, or port scanner
The listener returns a fake 404 response to avoid alerting the target system that the payload was successfully executed.

​
Payload styles vs payload types

q-ai separates how a payload is hidden from what it instructs the agent to do. Payload styles control how the injection instruction blends into the document content. Styles range from obvious (direct injection markers for baseline testing) to subtle social-engineering approaches like citation, reviewer, academic, compliance, and datasource that disguise the instruction as legitimate document content. Payload types define the action the agent is instructed to perform:
  • callback — Fire an HTTP request to the listener (proof of execution)
  • exfil_summary, exfil_context — Exfiltrate data to the listener
  • ssrf_internal — Server-side request forgery to internal endpoints
  • instruction_override — Override the agent’s system instructions
  • tool_abuse — Misuse agent tools and capabilities
  • persistence — Persist instructions across sessions

​
Dangerous payload gating

Payload types are divided into two safety tiers:
  • Always available: callback — benign proof-of-execution that only fires an HTTP GET
  • Requires --dangerous flag: All other payload types (exfil, SSRF, instruction override, tool abuse, persistence)
# Safe — callback only
qai ipi generate --callback http://localhost:8080

# Dangerous — requires explicit flag
qai ipi generate --callback http://localhost:8080 \
  --payload-type exfil_summary --dangerous

​
q-ai modules

ModuleAttack SurfaceWhat It TestsHow It Proves Results
auditMCP server capabilitiesWhether servers expose vulnerabilities mapped to the OWASP MCP Top 10Structured findings with severity, evidence, and remediation
proxyMCP client-server trafficWhat data flows between agents and serversRecorded sessions with message-level detail
injectMCP tool descriptionsWhether AI agents comply with poisoned tool descriptionsModel response analysis with compliance scoring
chainMulti-module attack pathsWhether vulnerabilities can be composed into attack chainsStep-by-step execution trace with success/failure
ipiDocument ingestionWhether AI agents execute hidden instructions in uploaded documentsOut-of-band HTTP callback from the agent
cxpProject instruction filesWhether poisoned instruction files influence coding assistant code generationDetection rule validation against captured assistant output
rxpRAG retrieval layerWhether adversarial documents win vector similarity battles and enter the LLM context windowRetrieval rate and poison rank scoring across embedding models

​
Interpret prompts

Every report and export output includes a prompt field containing an AI-evaluation prompt. This prompt summarizes the structured findings in natural language and can be fed directly to an LLM for automated analysis, triage recommendations, or follow-on testing priorities.
ModuleWhat the prompt summarizes
auditTarget server, tools scanned, findings by severity, OWASP categories
injectTarget model, techniques used, compliance outcomes
chainStep count, modules used, trust boundaries crossed, success/failure path
ipiCampaign count, formats, techniques, callback hit rate
cxpTechniques, objectives, assistants tested, outcome distribution
rxpEmbedding model, query count, retrieval rate, mean poison rank
The prompt appears as "prompt" in JSON output, "interpretPrompt" in SARIF, and as an expandable analyst context section in HTML reports.