n8n 2.42 turns Agents on by default: cap the Sume tool it calls

If n8n 2.42 switched Agents on for your team, decide before anyone builds one whether an agent may call Sume's paid tools, and if yes, make the spend ceiling part of the call, not part of the prompt. The 2.42.0 release (2026-09-29) lists "Agents enabled by default" among its notable changes, alongside a durable agent message queue foundation and MCP Client node changes (read 2026-10-03). An agent that can reach generate_video and loops on a bad plan spends until something stops it.

The n8n facts are from the 2.42.0 release notes. The Sume facts come from MCP tools and gates and MCP OAuth and API keys. For the transport detail of the MCP Client node in the same release, see the terminate-session post.

Three ways an agent can reach Sume

An n8n agent can get Sume capability as an MCP tool through the MCP Client node pointed at https://mcp.sume.com/mcp, as an HTTP Request tool against the REST API, or as a sub-workflow tool you wrote yourself. They differ in how much control you keep. The MCP route exposes the full hosted tool list for the credential, so the credential choice is the control. The HTTP route exposes only the endpoints you configure. The sub-workflow route lets you hard-code the guardrails.

Put the cap in the arguments

Sume's gates are per call. Every write or paid tool requires an idempotency_key, which dedupes a retry but is not approval; max_spend_usd is enforced only when provided; dry_run=true returns a preview without submitting. Because n8n agents build tool arguments from a model's output, the safest wrapper sets the cap itself and ignores whatever the model proposed.

A sub-workflow tool is the cleanest way: the agent supplies only a prompt, and a Code node adds the key and the ceiling before the HTTP call. Derive the key from the execution id and item index so a retried item reuses the same key and a new item gets a new one.

// n8n Code node (JavaScript), runs once per item
const out = [];
for (const [i, item] of $input.all().entries()) {
  out.push({
    json: {
      idempotency_key: `n8n-${$execution.id}-${i}`,
      max_spend_usd: 1,
      payload: { prompt: String(item.json.prompt || "").slice(0, 2000) },
    },
  });
}
return out;

Three guardrails for a team default

Since Agents are now a default feature, write the rules once and apply them to every workflow, not to each agent as it appears. These three cover most of the exposure.

• Credential: give workflows a dedicated Sume key, not a personal one, so you can revoke it alone; prefer OAuth read-only wherever the agent only needs to look things up.
• Ceiling: max_spend_usd on every paid call, set by a node, not by the prompt; a low number first, raised only after reading real job costs.
• Visibility: log the idempotency_key and the returned job id to a table, so a bad run is a query, not an investigation.

Then test the failure case on purpose. Point the agent at a goal that cannot succeed, such as an image of a prompt it cannot satisfy, and watch whether it retries. A retried call with the same key returns the original job; a call with a new key is a new job and a new charge. If your agent generates a fresh key on every attempt, it has defeated the dedupe, and the fix belongs in the wrapper, not the prompt.

After a paid create, wait with jobs_wait, which holds up to 55 seconds per call. On wait_slice_expired, call it again with the same job id. The agent should never respond to a slow job by creating another one, so say that in its system prompt and enforce it by exposing no create path from the wait step.