SonarQube MCP Server — agentic threat model

The foundation model is highly vulnerable to indirect prompt injection (reprogramming) because the MCP server feeds raw code snippets, security hotspots, and project issues directly back into the model context.

Data operations rely on SonarQube Server or Cloud integrations. A compromised repository or malicious code snippet acts as poisoned data, which is retrieved and processed by the agent, potentially exfiltrating context via outbound tool calls.

The agent framework exposes tools to query SonarQube APIs. Insecure tool integration could allow an attacker to craft malicious code that, when analyzed, triggers tool misuse or unauthorized API queries to other projects.

Not certain from the listing — Deployment requires hosting the MCP server and managing sensitive SonarQube API tokens. If the hosting environment lacks sandboxing, a compromised token could lead to unauthorized access to private codebases.

Not certain from the listing — There is no mention of built-in guardrails, input sanitization, or anomaly detection to inspect the code snippets and analysis results before they are fed back to the LLM.

Security relies heavily on the underlying SonarQube instance's RBAC. If the MCP server uses a highly privileged service token, any user interacting with the agent inherits those broad read/write permissions across projects.

In a multi-agent ecosystem, other agents relying on this MCP server's output could be deceived if this agent is fed manipulated code analysis results, leading to cascading trust failures in automated CI/CD pipelines.