Should an agent tool take a workspace_id argument for Sume calls?

Do not add a workspace_id parameter to a tool that calls Sume. The Sume safe-automation guidance states that the API key or the app session selects the workspace, and that tools must not accept a workspace id from the user. The only stated exception is a product that explicitly supports a change between workspaces. For a custom agent tool, the workspace is whichever one the credential belongs to.

Why the rule exists

If a model can name a workspace, then a prompt that says "use workspace X" becomes an attempt to cross a boundary, and your code has to defend against it on every call. If the credential alone decides, the question never arises: a key for workspace A cannot spend or read in workspace B.

It also keeps billing clear. Generation and analysis creation can spend credits, so the guidance asks that agent tools make those actions explicit and keep read-only operations separate.

What this means in a tool definition

If one agent really must serve several workspaces, make the choice of workspace a deployment decision outside the model, for example a separate configuration per customer, rather than a parameter the model fills in.

• Give the tool inputs for the creative parameters only, such as prompt, duration and model.
• Read the Sume key from the server environment, never from model-visible arguments.
• Use one key per workspace, and run separate tool instances if an agent serves two workspaces.
• Return job ids and statuses to the model, not signed media URLs, unless it needs them to continue.

Checking the boundary

After wiring a new tool, call a read-only endpoint such as the account or balance route with each key and confirm that each returns its own workspace. Do that before the tool is allowed to submit paid work, so a mixed-up key shows up as a harmless read.

Where this shows up in practice

Teams often build a helper such as create_video(workspace, prompt) because a model asked for it in a demo. Replace it with create_video(prompt, duration) and a client constructed once per workspace. The change is small, and it removes a whole class of prompt-injection attempts that try to redirect work to a different workspace.

Hosted MCP follows the same shape: the OAuth session or API key you connect with fixes the workspace, and mcp_health reports the credential in use. There is no argument to switch.