From MCP Configuration to Server-Side Execution: A Trust-Boundary Case Study

This case study comes from a real client's self-hosted agent environment. The initial question was straightforward: where did the application keep the credentials it used to call external models? The API did not return them, inspected artifacts contained no runtime configuration, and the database could not be reached from the external test location. Continuing to focus on those entry points offered little value.

The turning point was MCP configuration. A web administrator could configure a local tool process, and the backend would start that process when testing its connection. An application-level management privilege had become process-execution capability inside the application's runtime environment.

This article reconstructs the reasoning from existing test notes. Unexplored branches are not presented as experiments. Client and product names, accounts, passwords, addresses, endpoint paths, table names, and deployment identifiers have been omitted. Implementation snippets are illustrative, not target-specific exploit payloads. The issue concerns this integration's permission model; it does not establish that every MCP application has the same weakness.

1. Start With How the Application Uses Credentials

An application that can call a model has access to some usable identity along the call chain. That does not prove its local database contains a plaintext API key. Workload identity, an external secret service, and a model gateway holding credentials are all possible designs.

In these notes, configuration handling and database-access code narrowed the question to provider credentials stored by the application. That evidence matters: it turns “model calls require an identity” into “this environment has a particular storage location to examine.” Without it, jumping straight to the database would be guesswork.

Omitting a sensitive field from an API response demonstrates output control for that read interface. The server still needs a path to obtain usable credentials when making a call. The next questions concern that path and the execution identity it relies on.

2. Why Other Candidate Paths Were Set Aside

Eliminating a path requires explaining what was ruled out and where the evidence stops.

Candidate path	Decision at the time	Supporting evidence and limits
Retrieve credentials through application read APIs	Stop investing in this path	Inspected query and response logic omitted the secret field; this conclusion covers only those interfaces
Find runtime configuration in object-storage artifacts	Set aside provisionally	Inspected artifacts produced no match, and packaging rules excluded the configuration; this does not cover every historical artifact
Connect directly to the database from outside	Not a viable route from that location	Connections timed out from the specified test position; timeout alone does not establish the database's full network exposure
Search skills or documents for credentials	Not pursued	More direct storage evidence already existed; this was prioritization, not proof that content could never leak a secret
Read configuration through host-management channels	No direct entry point	The current identity lacked usable remote-management access; that does not rule out application-level execution capabilities
Obtain an application-side execution point through MCP process configuration	Selected	Notes showed insufficient command restrictions, process startup during connection tests, and explicit inheritance of the full application environment

After those exclusions, the problem became specific: the database was unreachable from the current external location, while the functioning application needed database access. The investigation therefore focused on an execution point with the application's access conditions.

3. Why MCP stdio Involves Process Execution

MCP exchanges JSON-RPC messages. With stdio, the client launches a tool-server subprocess and communicates over its standard input and output. Streamable HTTP connects to an independently running HTTP service; launching a local subprocess is not a prerequisite of that transport. See the [MCP transport specification](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports).

In this deployment, the agent backend acted as the host, with an MCP client connecting to tool servers. Command configuration saved through the web application eventually reached the backend's local process-launching code.

One timing detail is easy to get wrong: constructing a StdioClientTransport generally stores parameters; the subprocess starts when the connection flow calls the transport's start() method. Initialization, tool discovery, and tool calls follow. The order is visible in the [TypeScript SDK stdio implementation](https://github.com/modelcontextprotocol/typescript-sdk/blob/v1.x/src/client/stdio.ts); an individual project must still be checked against its pinned version.

Save tool configuration
  → Backend loads configuration
  → Connection flow starts the stdio subprocess
  → Initialization handshake
  → Tool discovery
  → Model selects a tool
  → Tool call and result

A handshake error therefore does not prove that the command never ran. The process may have started and simply failed to respond with valid protocol messages. Approval at the tool-call stage does not automatically cover the earlier process-launch decision.

4. Which Permission Boundary Was Crossed?

The recorded entry point was an initialization administrator credential that still worked. It provided web-administration rights, not operating-system administrator rights. The subsequent design made the difference: a web administrator could choose which tool program the backend would launch, without a separate machine-execution permission boundary.

A length limit cannot replace restrictions on executables and arguments. Even when process creation does not enable a shell, allowing the caller to select a dangerous interpreter or arbitrary executable may grant more capability than “configure a tool” suggests. Whether shell metacharacters can be injected is a separate implementation question.

Nor does this automatically grant root on the physical host. The initial capability exists inside the application's execution environment; if the application runs in a container, that container is the first boundary. Reaching the physical host requires additional evidence. Using the word “host” in a description does not establish a container escape.

5. Environment and Network Position Enable the Next Step

The recorded application explicitly passed its own environment to the tool subprocess. The example retains only the shape of that risky decision:

// Illustrative implementation pattern, not the client's source code
const toolEnvironment = { ...process.env };

Full inheritance was this application's integration choice, not a requirement of MCP. The SDK's default environment policy and an application explicitly supplying its entire environment are different things.

This broadens the information visible to the subprocess. If database connection settings, signing secrets, or other service credentials exist in the parent environment, the child receives them too. Which values actually exist and what privileges they grant still require individual verification. A list of plausible environment variables is not evidence that all of them were exposed.

Network position matters as well. A subprocess normally uses the application's network environment; it does not magically bypass cloud routing. When the application already reaches the database and the child can use its identity, failed external connectivity does not block that internal route. The data it can read depends on the database account's actual privileges and the storage design.

6. Connecting the Entire Chain

The recorded chain can be reduced to five prerequisites. Each step depends on the capability established before it; those intermediate conditions should remain explicit.

Initialization administrator credentials remain valid, granting application-management access.
Management configuration controls parameters used to start a backend process.
Testing the connection starts that process without waiting for a model-driven tool call.
The subprocess receives application-side environment information and network access conditions.
Within the database identity's privileges, it can access provider credentials stored by the application.

The notes also describe an output risk: an application-writable location was served publicly as static content. Together, these capabilities could move server-side information into a publicly readable location. Actual directories, filenames, and output contents are omitted here. Separating static-file serving from writable application storage is an independent remediation point.

In this chain, MCP supplied the execution point; environment and database privileges determined what it could do; public static storage determined whether its output could become externally readable. Keeping those roles separate makes the required fixes easier to identify.

7. The Observed Path Versus Related Risks

The actual path involved four boundary types: identity to management configuration, configuration to process execution, subprocess to application secrets and data privileges, and server-side writes to public reads.

Three related risks deserve separate treatment rather than being presented as tested findings: tool names and descriptions can influence model decisions; tool results can carry prompt injection; workspace-wide configuration can extend an administrator's choices to other members' sessions. The first two concern model-input trust. The third concerns configuration scope and execution triggers.

The chosen path did not depend on persuading a model to act. Its decisive action occurred while connecting a tool server. Stronger prompts or tool-call approval alone would not cover that existing process-launch path.

8. Which Attack Techniques Describe This Chain?

The mapping below follows the actions in the case. ATT&CK describes adversary behavior; CWE describes implementation weaknesses. The mapping is based on the existing notes. External references explain the categories, not independently prove what occurred in the client's environment.

Position in the chain	Technique and reference	Connection to this case
Login with initialization credentials	Default-account abuse: [ATT&CK T1078.001](https://attack.mitre.org/techniques/T1078/001/)	A still-valid preset administrator identity provided application access; this did not require password cracking or bypassing authentication
MCP configuration triggers server-side execution	Attacker-controlled program selection leading to arbitrary command execution: [CWE-78](https://cwe.mitre.org/data/definitions/78.html)	Web configuration selected the program launched by the backend. CWE-78 also discusses control over the entire program selection, not only shell-metacharacter injection; the underlying failure was configuration authority crossing the execution-authorization boundary
Subprocess receives application secrets	Unsecured credentials: [ATT&CK T1552](https://attack.mitre.org/techniques/T1552/)	Passing a credential-bearing runtime environment to a controllable child broadens access to secrets. The mapping stays at the parent technique; environment inheritance is not described as reading a configuration file
Querying the database with the application identity	Data from databases: [ATT&CK T1213.006](https://attack.mitre.org/techniques/T1213/006/)	Existing network position and database credentials allow access to application data. The targeted provider credentials also serve a credential-access objective. The notes do not establish SQL injection
Writing output to a publicly readable location	Related local-staging pattern: [ATT&CK T1074.001](https://attack.mitre.org/techniques/T1074/001/)	If data is written locally before external retrieval, that write can be understood as local staging. This article retains an output risk; a writable, readable directory alone does not prove completed exfiltration

Several other labels need care:

Searching artifacts for runtime configuration follows the investigation direction of [Credentials in Files (T1552.001)](https://attack.mitre.org/techniques/T1552/001/), but produced no match here. It should not be listed as a successful credential-access step.
Map execution to [Command and Scripting Interpreter (T1059)](https://attack.mitre.org/techniques/T1059/) only when a shell or scripting interpreter is established. A call to spawn alone does not identify an interpreter or justify a particular sub-technique.
Tool-description poisoning and indirect prompt injection in tool results follow a separate model-input path, described by [OWASP LLM01:2025 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/). Process execution here preceded model tool selection and did not use that path.
Reaching the database from inside the application does not by itself establish lateral movement, routing bypass, or container escape. Each requires evidence of the identity, network, or isolation boundary actually crossed.

The observed chain is concise: a default identity grants configuration authority; configuration triggers server-side execution; the process inherits application access conditions; and the database identity's privileges determine which data is accessible. MCP stdio supplies the process-start mechanism. The protocol does not require web-administration rights to become backend execution authority.

9. Put Controls Before Process Startup

A local tool process inherently executes code. In a desktop application, the machine's user typically chooses which tools to install and run. Moving this capability into a multi-user web service requires a new definition of who may grant it. Web-administration rights cannot simply stand in for ownership of the backend machine.

Invalidate initialization credentials or require their rotation so a default identity cannot become the management entry point.
Separate tool installation and execution authorization from ordinary business administration, and record configuration provenance and changes.
Prefer a controlled tool catalog for multi-user services. Where local processes are necessary, constrain executables and arguments and isolate execution identity, filesystem, network, and resources.
Pass only the environment variables each tool needs, rather than copying the entire application environment.
Give database accounts the minimum privileges needed and examine credential storage, decryption, and use as separate paths.
Place approval before process launch. Connection tests need the same controls and must not be treated as side-effect-free operations.
Separate application-writable storage from publicly served directories, and audit tool-process launches, unusual file writes, and sensitive data access.

The reasoning was straightforward: when an API omits credentials, inspect how the application stores and uses them; when an external connection fails, examine the application's internal access conditions; when configuration can launch a process, follow that process's identity, environment, and data privileges. A tool-integration setting had acquired backend execution authority without being managed as an equivalent privilege.