Short answer: The key considerations for storing AI-generated images in cloud systems are keeping the original private, recording its provenance and digest, and issuing short-lived delivery access only after authorization.
A game that creates promotional images has two different storage problems hiding under one noun. The original image is an audit artifact; the link shown to a reviewer is a delivery mechanism. I would keep those lifetimes, permissions, and identifiers separate. The practical design is a private, immutable-by-policy object record for the original, plus a short-lived read capability issued only after the requester is authorized. These are the first considerations I apply to cloud storage because delivery convenience is not evidence of controlled access.
That choice matters more than image format or bucket layout. A public URL is easy to deliver and difficult to retract. A permanently shared private link is safer in theory but becomes operational debt when it leaks into tickets, chat, or a browser history. Store the evidence once, then mint access to it deliberately.
In this scenario, a receipt is not merely a PNG. It is the answer to a future question: which generated artifact was delivered, under which game or campaign, and can the original still be examined without trusting a thumbnail?
I would write a small manifest beside the original object. It should contain a stable receipt identifier, the object key, media type, byte length, creation timestamp, generator request identifier, and a digest computed over the original bytes. The manifest is application data; the image is the evidence. Do not make a filename carry all of that meaning. Names get copied, normalized, and occasionally overwritten by a well-meaning export job.
The digest does not make a file immutable by itself. It gives an auditor a comparison value, while retention policy, write permissions, versioning or equivalent object-history controls, and deletion authorization provide the surrounding control. Those are separate responsibilities, and collapsing them into “the storage layer is durable” is how a receipt system ends up unable to explain its own history.
Keep it boring.
For generated images, provenance also deserves a boundary. Keep the prompt and model metadata that the business is allowed to retain, but do not quietly put secrets, user tokens, or unrestricted personal data into a manifest that will later be exported. An audit record should be inspectable without becoming a second credential store.
The original needs a narrow writer path and a controlled reader path. A reviewer needs the opposite experience: click, inspect, and move on. Those requirements conflict if the URL is treated as the record.
A time-limited signed URL is a capability: possession of the URL can grant access until it expires, so the application must authorize the requester before issuing it and must keep its lifetime appropriate to the workflow. The storage service still evaluates the request represented by that capability; the application should not assume that hiding a URL is an access-control model. The relevant URL-based mechanism is documented in the storage provider’s presigned URL guidance, but the design principle is provider-independent.
Here is the shape I use at the application boundary. It intentionally returns a capability only after the receipt owner and requested operation have been checked.
from datetime import timedelta
def issue_receipt_download(receipt, actor, signer):
if not actor.can_review_game(receipt.game_id):
raise PermissionError("receipt is outside the actor's scope")
if receipt.deleted_at is not None:
raise LookupError("receipt is no longer available")
return signer.create_read_url(
object_key=receipt.object_key,
expires_in=timedelta(minutes=10),
response_content_type=receipt.media_type,
)
Ten minutes is an example policy value, not a universal setting. A long-running compliance review may need a re-issuance flow; a one-click moderation panel may need less. The important event to log is the authorization and issuance decision, not just the eventual download, because a client can abandon a URL without using it.
The limitation is deliberate: a private object adds an authorization dependency to delivery. A public object removes that dependency but weakens the ability to contain a copied link. This trade-off should be recorded as a policy decision, not hidden behind a storage setting.
| Failure mode | What it looks like | Design response |
|---|---|---|
| The thumbnail becomes the only copy | A later review cannot reproduce what was delivered | Preserve the original bytes and record their digest separately |
| A link escapes the intended audience | A ticket or chat message contains a still-valid capability | Keep objects private, issue short-lived links, and log issuance |
| A retry creates two receipts | The worker times out after upload and writes a second manifest | Use an idempotency key derived from the receipt request |
| Metadata drifts from the object | The manifest says PNG while the bytes or response headers disagree | Validate media type and byte length at ingestion, then treat the record as append-only |
| Deletion is ambiguous | A user removal request conflicts with an audit hold | Model legal or policy holds explicitly instead of letting a generic cleanup job decide |
The retry case deserves extra attention. Up an image and recording its manifest are separate operations unless the storage system and database share a transaction, which they generally do not. A worker should therefore make the receipt identifier deterministic, record an intermediate state, and reconcile abandoned work. “The upload returned success” is not proof that the database write completed; “the database row exists” is not proof that the bytes are readable.
I also prefer a state machine over a boolean called stored: pending, available, quarantined, and held say what operators need to know. A failed validation should not look like a missing image, and a policy hold should not look like a transient queue error.
There is no honest setting that maximizes both. A public object removes application work and expands the blast radius of one copied URL. A private object with per-request authorization preserves control and adds a dependency on the application during delivery. The right boundary depends on who reviews receipts, how long a review lasts, and what an exposed image would disclose.
| Choice | Delivery | Control | Operational cost |
|---|---|---|---|
| Public original | Very simple | Weak revocation and broad discovery surface | Low at request time, high when exposure must be investigated |
| Private original plus short-lived capability | Simple after authorization | Narrower audience and explicit issuance | Requires authorization, signing, and audit logs |
| Private original plus application-mediated streaming | Most controlled | Application can enforce every read | Highest bandwidth, timeout, and scaling responsibility |
For game receipts, the middle option is usually the least surprising boundary: the application decides who may inspect a receipt, while the storage service delivers the bytes. I would still test the expiry behavior, clock skew, range requests, and failed retries as part of the workflow rather than assuming the happy path is representative.
Monitoring should follow the states and decisions. Count pending-to-available latency, validation failures, missing-object reconciliations, capability issuance, and authorization denials. Avoid logging full URLs if they contain bearer material. Log a receipt ID, actor ID or service principal, decision, and timestamp instead.
Start with one receipt type and a deliberately small manifest. Upload a known fixture, calculate its digest, fetch it through the intended private path, and compare the returned bytes. Then exercise a timeout after the upload, a duplicate request, an expired link, an unauthorized reviewer, and a deletion request under a hold. These tests expose the boundaries that a unit test around the image encoder cannot.
Next, add reconciliation before adding lifecycle automation. A scheduled job can find manifests stuck in pending, objects without manifests, and manifests whose recorded metadata disagrees with a fresh inspection. Only after those classes are visible should retention and deletion workers act on them. Automation that deletes before it can explain what it found is an audit risk with a cron expression.
The decision rule is short: keep the original private, make its identity independent of its filename, preserve enough provenance to explain the receipt, and issue delivery access only after authorization. The storage provider is an implementation detail; the boundaries are the system.
References: