MCP prompt privacy myths: storage, logs, providers, and local execution

Replace the privacy slogan with a boundary map

Myth: “MCP prompts are private because MCP is only a protocol.” The protocol standardizes JSON-RPC messages among hosts, clients, and servers, but its own security section says privacy principles cannot be enforced at the protocol level. Consent, access controls, documentation, storage, and downstream sharing remain implementation responsibilities. A useful privacy review therefore starts with the actual host, server, transport, provider, and storage systems, not the MCP label.

Myth: “A local MCP process means the prompt never leaves the computer.” A client can launch an MCP server over local stdio while that server calls a remote service. OfflineCreator documents exactly that distinction: its local stdio package is an interface to cloud Studio, and MCP generations go to the disclosed cloud provider. Local transport describes one connection in the chain; it does not prove local model execution.

Use the page as a claim-checking worksheet. For every privacy statement, classify it as protocol, transport, execution, account storage, provider retention, analytics, or offline-product behavior. A statement is not supported merely because a neighboring layer has a strong control. This method is the page's unique purpose; the prompt-handling security page owns the exact Studio prompt trace.

Protocol boundary

MCP defines message exchange and capabilitiesIt does not impose one universal retention, provider, or logging policy on every implementation.

Transport boundary

stdio can connect a client to a local processThat process can still send generation inputs to a cloud API.

Execution boundary

The selected model may run elsewhereVerify the complete request path before calling a workflow local or offline.

Trace one Studio MCP prompt across every processor

For OfflineCreator Studio, a generation prompt crosses several distinct boundaries. The MCP client sends tool arguments to Studio; Studio processes MCP, CLI, API, and web generations through the same cloud workflow; and Studio sends the prompt, settings, and any source media to fal for the selected model. The provider disclosure adds that fal may operate the model or broker the underlying model. “Private media” at the Studio account layer therefore does not mean “never disclosed to a provider.”

The safe reading is narrower: Studio says generation media is private by default unless the account owner publishes it to Community, while cloud execution still requires provider processing. That is an access-control statement about Studio media, not a zero-transmission statement. Before submitting sensitive material, identify the client, Studio account, provider payload, provider media object, and any later export as separate disclosure decisions.

1. Tool call

Prompt and selected settings enter StudioThe MCP interface does not create a separate local generation engine.

2. Provider request

Prompt, settings, and applicable source media go to falThe provider serving or brokering the selected model processes those inputs.

3. Account delivery

Studio controls access to the resulting account mediaPublishing to Community is a separate, explicit visibility change.

Separate account history, security logs, and analytics

Myth: “If prompts are excluded from analytics, nothing is stored.” OfflineCreator’s policy describes several different records. Prompts are generation content, and generation history and media remain until the user deletes them or closes the account, subject to short backup windows. Sampled API request logs can retain route, status code, key identifier, and a truncated one-way network-address hash for up to 12 months. Consented Google Analytics measures listed usage events but excludes prompts, uploads, generated media, and email addresses.

Those statements should not be collapsed into a universal “no logs” claim. An analytics exclusion applies to the named analytics flow; a listed security-log schema applies to that sampled log; and account history has its own retention rule. The public policy does not prove that every infrastructure, support, provider, or model-operator log follows the same field list. A security review should ask which record is meant each time someone says “the logs.”

Generation history

Includes prompt-associated account contentPolicy retention lasts until deletion or account closure, with short backup windows.

Sampled API logs

Route and security metadataThe policy gives a field list and a retention ceiling of 12 months.

Consented analytics

Usage events without prompt or media bodiesThis exclusion is not evidence about every other operational system.

Treat provider retention as a second policy layer

Myth: “Deleting the Studio generation means every provider copy disappears immediately.” fal currently documents two different data classes. JSON request inputs and outputs are stored for 30 days by default. A caller can set `X-Fal-Store-IO: 0` to prevent JSON payload storage, but fal explicitly says that this does not remove CDN files generated or uploaded during processing. Provider media has a separate lifecycle control.

Across the four public pages inspected for this question—the Studio privacy policy, MCP and CLI page, cloud-provider disclosure, and fal retention documentation—none states which `X-Fal-Store-IO` or `X-Fal-Object-Lifecycle-Preference` value Studio sends on production MCP requests. This bounded document review therefore cannot determine the effective provider retention for a specific Studio request. It also cannot infer that deleting Studio history invokes fal’s deletion API. For sensitive work, request deployment-level confirmation rather than converting an available provider control into a claim that the application uses it.

fal JSON payload

30-day documented defaultThe provider offers a per-request header that disables JSON input and output storage.

fal CDN objects

Separate retention and access lifecycleThe JSON storage header alone does not make uploaded or generated files disappear.

Studio deployment

Production header values remain unverifiedAn available control is not evidence that a particular integration enables it.

Choose Studio or LocalForge by disclosure requirement

Use Studio when a disclosed cloud path is acceptable: the prompt and applicable source media can leave the device, reach Studio, and be processed through fal. Use LocalForge when the requirement is that generation stay on the machine. LocalForge’s first-party FAQ describes an on-device tool that works offline after download, does not upload prompts or creations, has no account requirement, and includes no analytics telemetry or background data collection.

This is a product distinction, not a general promise that every “local MCP” setup behaves like LocalForge. A local server may call the network, and a cloud service may keep account media private while still using external processors. Test the boundary that matters: disconnect the network for a genuinely offline workflow, or obtain processor and retention details for a cloud workflow. Do not use “private,” “local,” and “offline” as interchangeable words.

When the question is a concrete Studio prompt rather than a myth, follow the dedicated prompt-handling trace for moderation, account history, provider dispatch, and analytics exclusions. Use this page when the disputed claim collapses protocol, local transport, cloud execution, or LocalForge into one privacy promise.

Evidence boundary and unresolved questions

The supported conclusion is deliberately limited. MCP does not itself establish a zero-storage or on-device privacy guarantee. Studio documents cloud provider processing, account-history retention, sampled security metadata, and analytics exclusions. fal documents provider-side JSON retention and separate media controls. LocalForge documents a different, offline execution model. Together these sources disprove the shortcut that all MCP prompts share one privacy outcome.

Community material was screened but excluded from the factual synthesis because none of the retrieved items was used to substantiate an OfflineCreator, fal, or LocalForge privacy statement. Adjacent local-AI and third-party-provider privacy threads were treated as anecdotal only. The research record marks community evidence insufficient and recent-source coverage degraded. This paragraph discloses this draft’s evidence-selection method; it does not claim that any community was quiet, quantify discussion, or characterize the performance of an individual source.

This pass did not send a production prompt, inspect application or provider dashboards, examine deployed request headers, test account deletion, trace a Community publication, audit infrastructure logs, or verify LocalForge network behavior independently. The inspected public pages do not disclose the production fal storage or media-lifecycle header values, so the effective settings for Studio remain unresolved, as does any downstream model operator beyond fal. Keep the page as an unreviewed research draft until those gaps are acceptable for its intended use.