Home/ Part VII — Multimodal & Long Context (Where AI Studio Gets Spicy)/21. Working With Images/21.5 Safety and privacy with user images

21.5 Safety and privacy with user images

Overview and links for this section of the guide.

On this page

What can go wrong with images

User images are high-risk because they can contain information that is:

  • Personally identifying: faces, addresses, phone numbers, IDs, license plates.
  • Confidential: internal dashboards, customer lists, incident screenshots, secrets in terminals.
  • Legally sensitive: medical info, financial info, minors, regulated data.

Even when the screenshot looks harmless, it may include hidden context (account names, environment URLs) or be linkable to a person. Treat images like logs: default to minimizing and redacting.

“It’s just a screenshot” is not a safe assumption

In production work, screenshots frequently contain auth tokens, emails, IDs, or sensitive business metrics. Don’t upload what you can’t justify.

Minimize and redact by default

Use these tactics to reduce risk before you upload or share an image:

  • Crop aggressively: include only the region you need.
  • Blur/cover PII: names, emails, IDs, addresses, order numbers.
  • Remove secrets: API keys, tokens, URLs with credentials, internal endpoints.
  • Use synthetic data: demo accounts, mock dashboards, fake user info.
  • Prefer text when possible: copy/paste errors instead of screenshotting terminals.

If you can’t redact safely, don’t upload it. Switch to a local/offline workflow or use internal tools that meet your compliance needs.

If you’re building a product that accepts user images:

  • Get explicit consent: tell users what you do with images and why.
  • Disclose retention: how long you store images, where, and who can access.
  • Provide deletion: allow users to delete images and derived data.
  • Document data classification: what is allowed/forbidden to upload.
The “safe default”

Design your system so the most common path stores the least data: process, extract structured fields, and discard the raw image unless there’s a clear reason to keep it.

Storage, retention, and access control

If images must be stored:

  • Encrypt at rest and in transit.
  • Limit access: least-privilege roles; audit access.
  • Separate environments: keep production images out of dev/test tools.
  • Set retention windows: short by default; longer only by policy.
  • Log safely: never log full image payloads; store references/ids only.

Copy-paste prompts (privacy-first)

Prompt: ask what to redact before analysis

Before analyzing this image, list any potentially sensitive information visible (PII, secrets, proprietary info).

Output:
1) A checklist of what I should redact or crop.
2) A "safe-to-proceed" decision: yes/no.

Do not repeat the sensitive data itself in your response.

Prompt: extraction with minimization

Extract ONLY the fields I list below. Do not include any other text from the image.

Fields to extract: [field list]

Rules:
- If a field is not clearly visible, return null.
- Do not include names/emails/IDs unless explicitly requested.
- Output valid JSON only.

Practical checklist

  • Do I need the whole image? Crop to the smallest useful region.
  • Could this identify a person? If yes, redact or use synthetic data.
  • Could this leak secrets? Check terminals, URLs, tokens, internal dashboards.
  • Do we have consent/policy? If not, don’t upload.
  • Can we avoid storing it? Prefer extraction + discard.
  • Do we have a deletion path? Users and operators should be able to remove it.

Where to go next