Hosted Sume MCP token hygiene: 5 rules for agent credentials
Five Sume credential rules: an OAuth token is not an API key, stays out of CLI config and prompts, never goes to other providers; rotate exposed keys.
Sume's docs give five credential rules for agents that use the hosted MCP endpoint: an OAuth token is not a Sume API key, tokens stay out of CLI config, tokens never go into prompts, tokens are never forwarded to third-party providers, and exposed keys get rotated. Add a sixth habit for yourself: check which credential a session is actually using before it spends anything.
These rules matter more once an agent runs without you. A model that can read its own context can also repeat it, so the safe design is that the secret never enters the context in the first place.
The rules and where they come from
From the MCP OAuth and Safe automation pages, read 2026-10-09.
| Rule | Reason |
|---|---|
| An MCP OAuth token is not a Sume API key | They are separate credentials; one cannot stand in for the other |
| Do not store OAuth tokens in CLI config | Docs rule; sume login does not broker hosted MCP OAuth tokens |
| Do not paste tokens into prompts | Docs rule; prompts can end up in logs and chat history |
| Do not forward tokens to third-party providers | The token is audience-bound to https://mcp.sume.com/mcp |
| Rotate keys that appear in logs or chat history | Once exposed, assume it is public |
Do not mint keys as a workaround
If an OAuth session lacks mcp:write, the tempting shortcut is to create an API key so the paid tools appear. The docs tell you not to mint API keys for hosted OAuth clients as a workaround. If a task truly needs the paid tools, either re-consent with Write on, or run a separate key-based automation where you accept its wider reach on purpose.
Likewise, do not share one key across agents. A key's reach is the whole workspace, and the workspace comes from the key, never from something the agent supplies.
What a safe log looks like
Allow-list the fields rather than trying to scrub secrets later.
- Safe: request ids, job ids when needed, high-level status, sanitized media metadata.
- Unsafe: API keys, signed URLs, raw private media URLs, large amounts of user content or transcripts.
- Prefer Sume public ids and
media.sume.comURLs in agent reports.
A quick audit
Search your agent configs and shell history for the key prefix, check that MCP client config files contain only the server URL, and call mcp_health to see whether a session authenticated by OAuth or key. If a key turns up anywhere it should not be, rotate it in the dashboard before doing anything else.
Applying it to a team
Write the rules into the agent's setup document and into code review. A short checklist works: who consented, with Write on or off; which key, if any, the automation uses and where it is stored; who can rotate it; and where the agent's logs go. When someone leaves the team, remove their OAuth connections and rotate any key they could read. These steps take minutes and close the gaps that matter most with an agent that can spend.
Sources
Related posts
More in Developers
- HunyuanVideo 1.5 LoRA training: train.py and the Muon optimizer
HunyuanVideo 1.5 released training code on Dec 5 2025 and says to use the Muon optimizer for LoRA. The flags, the torchrun and FSDP setup, and the hosted gap.
- HunyuanVideo 1.5 cache inference: DeepCache, TeaCache, TaylorCache
HunyuanVideo 1.5 added DeepCache on Nov 24 2025 and TeaCache plus TaylorCache on Nov 27, switched with --enable_cache and --cache_type. What the README claims.
- Hy Image 3.5 multi-turn editing with assembled_history vs Sume edits
How Tencent's Hy Image 3.5 Preview chains edits with assembled_history, and what the same loop looks like on Sume's stateless images route.
- Idempotency key from the order id, not a fresh UUID per attempt
A random UUID generated inside the retry loop gives every attempt a new key and a new paid job. Derive the Sume Idempotency-Key from the order instead.
Written by Sume