What to log from a Sume agent run: request ids, never signed URLs
Safe logs for agents calling Sume: request ids, status, sanitized media metadata. Unsafe: API keys, signed URLs, private media URLs, transcripts.

When an agent or script calls Sume, log request ids, job ids when needed, high-level status and sanitized media metadata. Do not log API keys, signed URLs, raw private media URLs, or excessive user content and transcripts. The request id in the error envelope is the single most useful field to keep, because it is the fastest way to get a run investigated.
From Safe automation and MCP OAuth and API keys, plus the Sume MCP tool contracts, read on 2026-10-03.
Keep and drop
The safe-automation page splits logs into two lists. The reason for the second list is practical: logs are copied into tickets, chat and dashboards, and anything in them travels.
| Keep | Drop |
|---|---|
| Request ids | API keys |
| Job ids when needed | Signed URLs |
| High-level status | Raw private media URLs |
| Sanitized media metadata | Excessive user content or transcripts |
Where signed URLs come from
Several MCP tools can return sensitive short-lived URLs: jobs_get may return signed or private media URLs, and assets_download_url returns a short-lived GET URL by design. The tool guidance is to keep them out of user-visible text and to use them only for the download the user asked for. An agent that summarizes a job by pasting its full response has just leaked a link.
Instruct the agent to report the status, the stage and the request id, and to hand the user a file only through the channel they asked for.
Credentials in logs
Sume's guidance is that an MCP OAuth token is not an API key, that you should not store OAuth tokens in config or paste them into prompts, and that you should rotate a key that has appeared in logs or chat history. Treat that as a trigger: if you find a key in a log, rotate it, then fix the log call.
For the key itself, read it from an environment variable at start-up and never echo it. A request-logging middleware should redact the Authorization and x-api-key headers before writing anything.
Workspace isolation in logs
API keys and app sessions determine the workspace, and tools should not accept user-supplied workspace ids. Do not add a workspace id field to your own tool wrappers, and do not log one as if it were a user input. If a tool needs to know the workspace, account_me reports it from the credential.
A small logging helper
Wrap every Sume call in one function that records the method, path, HTTP status and request_id, and nothing from the body. Make it the only place that touches the response before the log line. When someone later adds a debug print of the whole response, that is the line a review should catch.
For job results, log the job id and the status, and store media in your own storage if you need it later. A signed URL that was valid when you logged it is a stale and sensitive string by the time anyone reads it.
Sources
Related posts
More in Agents
- Dry-run an H3 Max Recast from MCP: dry_run and max_spend_usd
Before a paid person swap, Sume's hosted MCP can preview cost with dry_run and cap spend with max_spend_usd. The calls, their order, and idempotency_key.
- Reference remix take kinds: which model renders each shot
A remake in Sume is planned as takes, and each take kind names its model: talking, performed, voice, still, recast, genjutsu, product swap. The map, and why.
- Remake a viral clip with my product: edit it or rebuild it?
Sume has two remake routes: models that keep the source footage, and reference remix that rebuilds shot by shot. How the agent decides and when to override.
- Scheduled run missing from /v1/jobs? Read /v1/action-runs instead
A Sume scheduled agent run is not a generation job. It never appears in /v1/jobs and has its own statuses, so poll /v1/action-runs/{run_id}.
Written by Sume