AI-Generated Media URL Privacy: Who Can Open the File?

ENTERPRISE MEDIA WORKFLOWS · BLOG 150

By Token360 · Editorial review: November 5, 2026

An AI-generated media URL does not, by itself, prove that the file is private. Determine whether access depends on possession of the link, a time-limited credential, an authenticated identity or a combination of controls. Then test the actual file path, including inputs and previews, against your intended audience.

A video can be generated inside an authenticated application and still be delivered through a URL with different access rules. For an unreleased product campaign or a private customer asset, the relevant question is not simply whether generation required an API key. It is what a person needs to retrieve the resulting bytes.

This article focuses on access to media files. It does not repeat the separate questions of how long a provider retains data, whether it trains on inputs, or how to recover a failed download. No live access-control experiment was performed for this article; the test matrix below is a proposed acceptance procedure.

Read first: the Token360 security and data-handling documentation describes the different processing and storage layers. File delivery needs its own review within that broader workflow.

Does an authenticated generation request make its output private?

No such conclusion follows from generation authentication alone. Permission to invoke a model and permission to read a stored file are separate checks. Establish what protects the returned media URL, whether it carries a credential, and whether the intended viewer must identify themselves. Review the file service rather than inferring its rules from the API call.

A useful acceptance statement is concrete: “Only members of the approved review group may view this draft before launch.” That requirement is stronger than “the video is not listed publicly.” If your application instead permits temporary sharing by link, document that choice explicitly, including who may create the link and how long it is usable.

Keep the source file, thumbnail, preview and exported copy in scope. Protecting a final video while leaving a revealing preview available to a different audience would not satisfy a requirement that the campaign remain limited to the review group.

How do public links, signed links and identity checks differ?

A public link generally needs no viewer identity; a signed link carries a limited access credential; an identity-gated file evaluates an authenticated viewer’s permission. Implementations can combine these patterns. The comparison below is conceptual: verify the actual policy, expiry and credential handling of the storage service used by your application.

Delivery pattern	What the viewer needs	What to verify before approval
Publicly readable URL	The address of the file.	Whether unrestricted retrieval is intentional for this asset.
Signed or tokenized link	A valid access-bearing URL, subject to its conditions.	Expiry, scope, forwarding behavior and available revocation controls.
Identity-gated access	An authenticated identity with permission.	Group membership, anonymous denial and cross-account isolation.
Application-mediated delivery	Whatever access policy your application enforces.	Whether the underlying file path can bypass the application check.

As a concrete storage example, Amazon S3 documents presigned URLs as bearer tokens that grant access to their holders, within the applicable permissions and expiry. It also says they can be used multiple times before expiration. Signing a URL therefore should not be equated with binding it to one named recipient or making it single-use. This example does not establish Token360’s URL implementation.

A private review page can be a good entry point, but its login screen is not enough evidence. Trace what the video player fetches after the page opens. If the player receives an access-bearing link, evaluate that link’s behavior too, rather than treating the page and file as one access boundary.

What does fal’s documentation reveal about input and output files?

Provider documentation can expose important differences between media objects that look like one workflow. An output rule may not cover the input upload, and a file permission rule may not govern an external storage service. Check the documented scope of each control before treating it as a workflow-wide privacy setting.

As checked November 5, 2026, fal’s File Access Controls documentation says its covered CDN URLs are accessible to anyone with the link by default, and ACLs can restrict access. It distinguishes output ACLs applied by an inference request from input uploads made before that request. Those inputs need their own applicable upload controls. The page also describes signed links for recipients without fal accounts.

The lesson is to inspect both sides of generation, not to conclude that a competitor lacks private delivery. The documented controls exist, but their scope matters. Nor should fal-specific headers be assumed to work on Token360: each service’s API and storage behavior needs its own documented confirmation.

What would a private campaign review workflow require?

For a private campaign, define who may access the source material and the generated result at each stage. Separate internal review from later public release. The hypothetical workflow below illustrates requirements to discuss with your engineering and platform teams; it is not a claim that Token360 automatically provisions these controls.

Suppose a brand is creating an unreleased product clip. A producer uploads a reference image, the model returns a video, and two agency reviewers need to approve it. A proposed design could keep the reference image in approved input storage, ingest the completed result into the organization’s controlled media store, and expose it through an authenticated review application.

That design still leaves questions. Can the model fetch the protected input through a supported mechanism? Is the initial output URL suitable for confidential content? Who can read the ingested copy? Does the review application issue a temporary link or relay the media itself? Resolve those details before calling the design private.

Moving a file into controlled storage does not change the original copy’s policy. Record the original output’s access and lifecycle separately. At release time, publishing a public copy should be an explicit step; a review link should not accidentally become the permanent public distribution path.

These are proposed design choices, not a recommendation to make sensitive inputs public to satisfy a URL field. If the approved model route cannot retrieve the input securely under your requirements, resolve that integration limitation before sending the asset.

What should you confirm for a Token360 media integration?

Confirm the behavior of the selected model route and the specific asset or download interface you use. Ask who can retrieve the media, what credentials the URL contains or requires, and which controls apply to inputs and outputs. Do not infer a platform-wide access guarantee from an example response containing a URL.

Token360’s security documentation, checked November 5, 2026, separates application, gateway, upstream and optional media-storage layers. It notes that signed URLs can expire without deleting their underlying resources. That establishes a useful distinction between access expiry and object lifecycle; it does not answer every question about file access for every route.

Bring the following scope to your Token360 enterprise discussion: the models and endpoints, whether assets are confidential before release, who needs to fetch them, whether temporary link sharing is acceptable, and the required access-removal behavior. Ask for the current documentation or account-specific confirmation for unresolved points.

The article does not assert that Token360 offers the same ACL API as fal, guarantees recipient-bound links, or provides universal instant URL revocation. Those would require evidence for the relevant service and configuration.

How should you test who can open a generated file?

Test a harmless asset against named access conditions, with the intended results written down beforehand. Include authorized, anonymous and unapproved viewers, plus copied links and permission changes where applicable. Separate an observed retrieval result from assumptions about caching, deletion or every other model route. A single successful private download is not a complete acceptance test.

Copy the worksheet below into a local CSV file. Blank fields are for your own review:

Test,Asset type/internal ID,Endpoint and storage scope,Declared policy,Viewer role,Credential type (not secret),Expected result,Observed result,UTC time,Evidence reference,Limits/caching considerations,Owner
Approved viewer,,,,,,,,,,,
Anonymous fresh session,,,,,,,,,,,
Unapproved test account,,,,,,,,,,,
Forwarded signed link,,,,,,,,,,,
Expired link fresh request,,,,,,,,,,,
Permission removal old link,,,,,,,,,,,
Permission removal new request,,,,,,,,,,,
Input asset,,,,,,,,,,,
Thumbnail/preview,,,,,,,,,,,
Exported copy,,,,,,,,,,,

. It provides a proposed test matrix and blank observation fields. It contains no real customer URLs, credentials or pre-filled claims that a provider passed.

Test	Question answered	Evidence to record
Approved viewer	Can the intended person retrieve the correct asset?	Viewer role, time and content actually returned.
Anonymous viewer	Does access require identity, or is the link sufficient?	A fresh session without account credentials.
Unapproved test account	Does identity enforcement distinguish allowed users?	The account role and observed allow/deny outcome.
Forwarded access-bearing link	Does possession enable retrieval by another holder?	Whether the result matches the declared sharing policy.
Expired link	What happens to a new retrieval after validity ends?	A fresh request, not previously cached playback.
Permission removal	What changes after the documented access-removal action?	Old-link and new-request behavior, including any stated delay.
Inputs and previews	Are related objects protected consistently?	Separate results for each in-scope file type.

Run only against assets and test accounts you control or are authorized to assess. For a confidential identity-gated design, anonymous retrieval would contradict the stated requirement. For an intentionally shareable temporary link, retrieval by its holder may be the designed behavior. Judge the outcome against the requirement, not against a universal assumption that every anonymous download is a defect.

When a request is denied, record that result without claiming deletion. When a request succeeds, verify the content rather than relying only on a status code or an already loaded player. Keep sensitive URLs out of screenshots and exported reports; use an internal test identifier to connect evidence to the asset.

What should happen if a review link is shared too widely?

Use the documented access-removal options for the actual delivery service, then verify a fresh retrieval. Record which link or identity was affected and which copies remain outside that control. Treat link expiry, permission removal and object deletion as different actions; none should be described as recalling files that recipients already downloaded.

A practical response plan identifies the owner who can change access, the control they can use, and the test that confirms its observable effect. If only expiry is supported, the plan should say so rather than promise immediate revocation. If the organization needs tighter control, change the delivery design before using it for sensitive material.

Also consider where the URL has been copied: review messages, issue trackers, logs and support attachments. Removing it from one message is not a technical access change. Review those copies as part of the operational response, without assuming they all caused a download.

Read next: the Token360 troubleshooting guidance explains useful request and resource evidence for support. Provide sanitized identifiers rather than secrets or private access-bearing URLs. For publisher context, see About Token360.

For the adjacent review, review retention and training use separately. Keep these questions distinct from this article’s scope.

Frequently asked questions

Is an unguessable URL the same as an identity check?

No. A difficult-to-guess address can still permit access to anyone who obtains it. Verify what the server requires from the requesting viewer.

Does HTTPS make a media URL private?

HTTPS protects the transport connection; it does not, by itself, decide which viewers are authorized. The file’s access rules remain a separate question.

Can I rely on the fact that the file is not indexed?

No. Search visibility and retrieval permission are different properties. A person with the link may still be able to access an unindexed file.

Are signed links always single-use?

No. Amazon S3’s documentation explicitly permits repeated use before expiration. Confirm the behavior of the service you actually use rather than assuming that signing means one-time access.

Has this article verified Token360 file access in production?

No. It reviews official documentation and supplies a proposed acceptance matrix. No production media access test or privacy certification is claimed.