Where to keep a Sume API key in a Claude Code routine

Environment variables are readable by anyone using the environment. On Pro and Max an API credential hides the key from Claude. What changes on Team plans.

5 min readSume
All posts

On Pro and Max plans, store a Sume API key as an API credential on the routine's cloud environment, with api.sume.com as the host and an Authorization: Bearer header. Anthropic's agent proxy attaches the key after the request leaves the session, so the key never reaches Claude, its commands or its environment variables. On Team and Enterprise plans API credentials are not available yet, so the key stays in an environment variable that anyone using the environment can read, and you should limit what that key can do.

This is from Anthropic's cloud environments and routines pages, read on 2026-10-03, matched to Sume's Format call docs.

What is the difference between the two?

The routines page says environment variables are visible to anyone who uses the environment, so on Pro and Max you should store keys for APIs Claude calls as API credentials instead. The environments page defines an API credential as a key stored on the environment that sessions use without seeing it, added by the proxy to requests for the hosts you list. The edit dialog has a Custom headers row that starts with Authorization and a Bearer prefix; for a header such as X-Api-Key you change the name and clear the prefix.

The page also lists requests that never get a credential. Read that section before relying on it, because a request the proxy cannot attach to falls back to an environment variable.

Where a Sume key can live in a routine (read 2026-10-03)
PlanStorageWho can read it
Pro, MaxAPI credential on the environmentNot the session; the proxy adds it
Team, EnterpriseEnvironment variableAnyone who uses the environment
AnyPasted into the routine promptAnyone who can open the routine and its runs

What should the Sume key be allowed to do?

Sume keys carry scopes. A Format run needs formats:write to create or cancel and formats:read to read the receipt, and scopes cannot be added to an existing key, so create a new key for the routine. Keep it server-side, and name it for the routine so you can revoke it alone.

Then lean on the run-level ceiling. Each Format run takes generation_spend_cap_usd, and the effective cap comes back on every receipt as usage.generation_spend_cap_usd_micros. A leaked key is still a key, but a routine that always sends a low cap and an Idempotency-Key bounds what one fire can cost.

What do I put in the routine prompt?

  • Tell the routine to call https://api.sume.com/v1/formats/{handle}/{slug}/runs and, on a plan with environment variables only, to read $SUME_API_KEY for the Authorization header.
  • Derive the Idempotency-Key from the thing being made, such as the date and product id, so a retry returns the original receipt with idempotency_hit: true.
  • Never ask the routine to print the key, a signed URL or a token into its transcript; runs are readable sessions.
  • A host listed on an API credential stays reachable even when the network level would otherwise block it, so api.sume.com needs no separate allowlist entry once the credential names it.

What if the key leaks anyway?

Create a new key, replace the credential or variable on the environment, then revoke the old key from the Sume dashboard; Sume's authentication page gives that order for a key that appears in logs or chat history. Rerun one read-only call to confirm the new key works.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume