What not to log from an AI API: keys, signed URLs, private media

Safe to log: request ids, job ids, status and sanitized media metadata. Unsafe: API keys, signed URLs, raw private media URLs and excess user content.

4 min readSume
All posts

Log request ids, job ids, status and sanitized media metadata; do not log API keys, signed URLs, raw private media URLs or more user content than you need. That split is Sume's own guidance for safe automation, and it matches what support asks for in a bug report.

Everything here is from Errors, Security and Media inputs, read 2026-09-30.

What is safe to log?

Errors carry a request id in both the body and the response headers, so you can log it without touching the payload. Job ids and status values are the other stable handles.

Logging split from the docs above, read 2026-09-30
Log itDo not log it
Request idSUME_API_KEY
Job id, run idLocal ~/.sume-com/config.json
Status and error codeSigned URLs
Media counts and file typesFull private media URLs, raw provider payloads
Local filenamesEmails, workspace or user ids

Why are media URLs a problem?

Job results can include first-party media URLs. The docs call them public URLs that are still user data, so summarize them as counts and types instead. Inputs that are signed or private URLs are also rejected by the API, so a signed URL in a log is a leaked temporary secret with no upside.

How do I redact by default?

Redact query strings and private identifiers, and avoid dumping large raw result payloads. In the CLI use --agent --json, which redacts URL-like and sensitive fields where supported. Never print keys; keep them in environment variables or a secret manager.

What goes in a support report?

Sanitized command names, error codes, request ids and job ids. Leave out keys, signed URLs, full private media URLs, raw provider payloads and emails unless engineering asks.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume