Cloud-provider retention in MCP generation workflows
Separate Studio account history from fal.ai payload and media retention terms.
An OfflineCreator MCP generation crosses more than one documented storage boundary. Studio's privacy policy says prompts, selected settings, and source media go to fal.ai for model processing. The same policy says Studio keeps generation history and media until the user deletes them or closes the account, subject to short backup windows. Those are Studio retention statements; they do not describe every record or file that fal may hold under its own controls.
fal's current documentation divides its provider layer again. JSON request inputs and outputs are stored for 30 days by default and can be excluded with `X-Fal-Store-IO: 0`. Generated media and files uploaded to the fal CDN use separate lifecycle controls. A reviewer should therefore track Studio history, fal JSON payloads, and fal-hosted media separately rather than treating one deletion or expiration setting as a universal result.
- Studio account layer
- History and privately stored mediaGoverned by Studio's account deletion, generation deletion, publication, and backup statements.
- fal payload layer
- JSON request inputs and outputsfal documents a 30-day default unless payload storage is disabled or the payload is deleted.
- fal media layer
- Provider-hosted input and output filesRetention and access use lifecycle and ACL controls separate from payload storage.
Continue the provider-boundary review
Continue with the broader security checklist for authentication, scopes, logging, output access, and revocation. Review analytics minimization as a separate checklist item, and require evidence specific to each system named in the review rather than carrying a conclusion from one system into another.
Read each fal control literally
`X-Fal-Store-IO: 0` addresses JSON payload persistence only. fal explicitly warns that files created or uploaded during processing can remain accessible under their own media lifecycle. Its delete operation can remove a request's payloads and CDN files found in that request's output, but not CDN files found in the input because those files may be shared by other requests. A payload-storage opt-out is therefore not a complete media-deletion control.
`X-Fal-Object-Lifecycle-Preference` controls output-file expiration and can also carry an initial ACL. fal's platform-header reference says the default is the account setting and, if that is not configured, files have no expiration and are publicly readable. Its access-control documentation says an inference request's ACL applies to files that request produces, while files uploaded before inference need controls on the upload itself. These are available provider controls, not evidence of the effective settings on a particular Studio request.
- Do not equate
- Payload opt-out with file deletionThe no-store header does not itself expire or restrict provider-hosted media.
- Do not equate
- Output lifecycle with input lifecyclePre-uploaded inputs may require their own lifecycle and ACL at upload time.
- Do not equate
- Studio-private media with provider-private mediaStudio access controls apply to Studio's copy, not automatically to an upstream provider URL.
Turn retention into a request-level review
Start with data classification, not with a generic promise that a cloud workflow is private. Decide whether the prompt, source media, generated media, or embedded metadata may be disclosed to fal at all. OfflineCreator's provider disclosure says the current Studio catalog is routed through fal and plainly distinguishes Studio from an offline service. If the material cannot leave the device, the documented decision is to use LocalForge rather than trying to repair the boundary with a shorter retention period.
For cloud-eligible work, record four decisions before approval: whether JSON payload storage is disabled; the provider-media expiration; the initial provider-file ACL; and how provider deletion will be verified. Then record Studio's separate retention and deletion path. Capture the actual request headers, applicable fal account settings, or a tested integration trace. The reviewed public Studio pages disclose provider use and Studio retention, while fal's pages describe available provider controls; they do not identify the effective header values or fal account defaults for a particular Studio generation.
After a deletion exercise, verify each layer independently. Confirm the expected Studio result, then obtain provider evidence appropriate to the request for payload and provider-file deletion. Do not infer provider deletion solely from a missing Studio history entry or link. fal documents JSON payloads and CDN files as separate stores with separate controls, while Studio's policy states its own history and media retention.
- Before submission
- Classify prompt, source, and expected outputUse an offline path when disclosure to a cloud provider is not authorized.
- At submission
- Capture effective headers and account defaultsCheck payload storage, expiration, and ACL as separate fields.
- At deletion
- Verify Studio and fal independentlyA successful action at one layer is not evidence about the other layer.
What this article covers
This article does not treat community or social retrieval as proof of OfflineCreator quality, pricing, or customer results. Product statements stay limited to documented Studio routing, quotes, and provider disclosure for mcp cloud provider retention.
Supported statements on Cloud-provider retention in MCP generation workflows stay limited to documented OfflineCreator Router behavior and the cited primary sources. This article does not invent unpublished routes, benchmarks, privacy promises, or customer outcomes.