Which account pays: fal's Active MCP account vs a Sume key

fal's MCP page has an "Active MCP account" setting that decides where credits go. Sume works the other way round: the API key, or the OAuth session, selects the workspace, and the docs say tools must not accept a workspace id from the user. So with fal you switch the active account; with Sume you change which credential the client holds.

Side by side

What this means in practice

With a fal-style active-account switch, an agent can spend from whichever account was left active. Sume closes that door by construction: a tool call cannot name a different workspace, so the spend lands where the credential points. The paid tools also need idempotency_key, and spend is gated by wallet and admission, with optional max_spend_usd and dry_run.

For an agent that works for several clients, run one MCP server entry per workspace, each with its own credential and a name that shows the client. Do not share one key across clients.

Checks before an agent spends

• Call account_me to confirm the workspace account context, and mcp_health for the auth source.
• Keep OAuth at mcp:read for exploration. Grant mcp:write only on the entry that is meant to spend.
• Log request ids and job ids, never keys or signed URLs. The Sume docs list those as unsafe to log.
• On a 402 insufficient_credits, the balance of that workspace is the cause, not another account.

Scenario: an agency with three clients

An agency runs three client workspaces. With an account switch, the risk is a stale selection: the agent renders client B's clip while client A's account is active. With Sume you would hold three credentials, one per workspace, and register them as three named entries. A call through the entry named for client B can only bill client B.

Add two guard rails. Pass a max_spend_usd on each paid call from your prompts or wrappers, and run account_me at the start of each session so the agent states which workspace it is in before it generates anything.