What to log from a Sume MCP agent: ids and status, never signed URLs

Log request ids, job ids where you need them, a high-level status and sanitized media metadata. Do not log API keys, signed URLs, raw private media URLs, or large amounts of user content such as transcripts. That is Sume's own safe-automation guidance, and it fits the way hosted MCP agents work, because their tool output lands in whatever log your client keeps.

Safe and unsafe

The list is on the Safe automation page. Sume's server instructions add a related rule for agents: do not echo signed URLs, secrets, prompts or private media URLs in agent reports.

What this means for an agent run

Some tools return short-lived links. The assets_download_url tool is one example, so treat its answer as a secret for as long as the link works. If you must show a result, show the durable media URL that a finished job gives you, or a job id the user can look up.

A key that does show up in a log or chat history should be rotated. The OAuth page says so directly. Your client's own debug or trace logging is the usual place for such leaks, so check what it records before you turn it on.

• Keep job ids and request ids in logs; they are enough to ask for support help.
• Strip query strings from media URLs before storing them.
• Keep a small allow-list of fields you write, rather than dumping whole tool answers.

The tradeoff

Thin logs make debugging harder, since you cannot replay a call from a log line alone. The balance Sume's guidance suggests is to keep identifiers and statuses, which let you find the call on Sume's side, and leave out the content and credentials, which create new risk wherever they are stored.

If you need to show a user what happened, link them to the job id or the durable result rather than pasting URLs from a tool answer into a chat. Sume's docs also note that results of finished jobs are durable, so a job id is enough to read the result again later, and you do not need to keep the media link in your own logs.