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
- 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}.
- Scheduled run body: unknown fields are silently dropped, not a 400
A typo in a Sume scheduled run body is dropped without an error, unlike a Format run. Check names, then read the receipt to see what applied.
- Scheduled AI runs in Q4 2026: ceiling by cadence at $1 a run
At the $1.00 default cap, weekly runs top out at $13 for Q4, daily at $90 and hourly at $2,160. How the schedule cap works and what null changes.
- Scheduled run receipt shows less than the wallet debit: which number
usage.billable_amount_usd_micros on a run receipt is generation spend only. GET /v1/usage?run_id= debited_usd_micros also counts the Agent's own turns.
Written by Sume