How OfflineCreator protects MCP-generated media

Private does not mean immediately deleted

Privacy and retention answer different questions. Studio says generation history and media remain until the owner deletes them or closes the account, subject to short backup windows. It separately says temporary uploads and failed-job artifacts are deleted promptly, typically within seven days. A private MCP output can therefore remain stored even when nobody else can browse it.

Plan deletion according to the sensitivity of the project rather than assuming that an expired download URL deleted the object. Link expiry ends that delivery capability; it is not a retention control. For a review, record whether the asset should stay in generation history, be deleted after export, or be intentionally published.

Use a simple retention decision for each completed generation: keep it private in account history, export and then delete it, or publish it after a disclosure review. That decision is about the lifecycle promised to the account owner. Detailed signer behavior, cross-account remint attempts, and route-level authorization tests belong to the output access-control review rather than this media-privacy explanation.

R2 privacy and database RLS protect different layers

Cloudflare states that R2 buckets are not publicly accessible by default and require an explicit public-access configuration. OfflineCreator says it uses Cloudflare for private media storage, while Supabase holds authentication and database records. Storage privacy controls whether an object can be fetched directly; database row-level security controls which records a database role may read or modify.

Supabase's primary documentation explains that RLS policies can compare auth.uid() with a row's user_id for owner-only access, while a policy granted to anon can intentionally expose qualifying rows. OfflineCreator's public policy states the product outcome: database access is governed by RLS, private media is not publicly listable, and only explicitly published Community generations are publicly readable. This research did not independently inspect production policies, so those implementation statements remain first-party claims rather than an audit finding.

Separate account authorization from the download link

A completed MCP generation can return a short-lived signed output URL. OfflineCreator's current privacy policy says account authorization is required to mint that short-lived signed media link. Separately, the published MCP package documents get_generation, wait_generation, and download_output tools for completed outputs. The minted link is delivery capability for one output, not evidence that the R2 bucket or the user's library is public.

Once minted, handle the URL like a secret. Cloudflare documents presigned URLs as bearer tokens: anyone who obtains one can perform the signed operation against the named object until expiry. Do not paste an output URL into an issue, prompt transcript, analytics event, or shared chat. If a link expires, request a new one through the authenticated MCP flow instead of weakening storage visibility.

Use the authorize, mint, expire sequence

For a private output, first authenticate the Studio account or scoped MCP connection. Next, request the generation by its ID through an authenticated MCP tool such as get_generation, wait_generation, or download_output. Only after account authorization should the service mint a signed output URL, as the privacy policy describes. Download within the stated lifetime, then discard the URL.

This sequence limits accidental disclosure but does not make a copied link harmless. Expiration narrows the time window; it does not stop another person from using a still-valid bearer URL. The safe failure path is to let an expired link fail and mint another after authorization. Community publication is a different path because it intentionally changes who may read the selected generation.

Private delivery

Authorize → mint → expireUse the signed URL only for the intended download and do not retain it in prompts or logs.

Public delivery

Explicitly publish → Community can readPublish only after reviewing the media, prompt, and settings that become visible.

MCP-generated media stays private until you publish it

OfflineCreator Studio applies the same media rules to generations started through the web app, public API, MCP server, or CLI. Source media and generated outputs stay behind account access by default. The public policy says the underlying media storage is not publicly listable, so receiving an MCP result does not turn its object into a public gallery asset.

The boundary changes only when the owner explicitly publishes a completed generation to the Community gallery. Publication makes that generation's media, prompt, and settings publicly visible; unpublishing removes that public access. Treat Share to Community as a disclosure decision, not as a routine download step.

For an asset owner, the practical privacy decision happens before publication: review the output, prompt, and settings together, because the policy says all three become visible when the generation is published. Downloading through MCP is not publication. Keeping an asset in account history is not publication. Only the explicit Community action changes the audience described by the policy.

Choose the next review by the boundary you need

Use the MCP security directory for the wider authentication and scope review. Read the prompt-handling page when the question is what reaches the cloud generation provider, or the API-key page when the immediate risk is credential storage and revocation. Those pages own their respective boundaries; this page stays focused on private media delivery and deliberate Community publication.

Editorial ownership boundary

This page owns the query “mcp generated media privacy” by explaining private storage, authorized delivery, signed-link handling, retention, and opt-in Community visibility together. The parent security directory owns the broad security overview. If current evidence can no longer establish both storage behavior and Community access behavior, consolidate this page into /security/mcp-security rather than repeating generic security advice.