Kiro CLI 2.26 asks more in untrusted workspaces: Sume dry_run first

Kiro CLI 2.26.0, released 2026-09-30, tightens approval checks for Hook and Language Server Protocol file writes, and for MCP tools and shell commands in untrusted workspaces (read 2026-10-03). If you call Sume's hosted MCP from Kiro in a folder it does not trust, expect an approval prompt per tool call, and use that prompt as a spend checkpoint: have the agent run a dry_run=true preview first so the number you approve is the real estimate.

The Kiro facts are on the Kiro changelog. Sume's gates are in MCP tools and gates. If you have not added Sume to Kiro yet, start with the Kiro MCP server post.

What changed and what did not

The changelog entry also says Workflows are opt-in in CLI 2.26 (enabled in /settings, then /workflow run), and that classic sessions show deprecation notices with migration guidance. For Sume, the relevant line is the approval change: in an untrusted workspace, MCP tools no longer pass without the checks Kiro now applies.

It does not change what Sume does. The server still decides what a session may call based on its credential, whether OAuth mcp:read, OAuth with mcp:write, or an API key.

Make the prompt carry the number

An approval prompt that says only generate_video is a weak checkpoint. A prompt whose arguments include dry_run: true is a strong one: the approver is agreeing to a preview, not to a charge, and the follow-up call can carry a max_spend_usd from the preview. generation_admission_preview is the read tool built for this, and Sume says ordinary single creates do not need admission theater, so keep the preview for expensive bursts.

In practice, tell the agent how to behave in the project instructions: preview first, report the estimate, then wait for approval, then submit with a fresh idempotency_key.

• Preview: call the paid tool with dry_run: true or call generation_admission_preview.
• Approve: the person reads the estimate in the prompt.
• Submit: same call with dry_run omitted, a new idempotency_key, and max_spend_usd set.
• Wait: jobs_wait holds up to 55 seconds; on wait_slice_expired retry the wait, never the create.

An instruction block to paste

Put this in the project's agent instructions. It is plain text, so it works wherever Kiro reads steering files.

When using the Sume MCP server:
1. Call tools_schema for a tool before its first use.
2. For any paid tool, call it first with dry_run=true and report the estimate.
3. Only submit after the user approves, with a new idempotency_key and max_spend_usd.
4. Wait with jobs_wait. If it returns wait_slice_expired, call jobs_wait again with the same ids. Never resubmit a paid create.

Keep the rule short, because long steering text gets ignored. In a trusted workspace the same text still applies, so you do not need two sets of instructions.

When a prompt per call becomes noise

Approval prompts have a failure mode: a person who clicks yes forty times stops reading. If your agent fans out a batch, forty prompts is a worse control than one. Use script_run so the batch is a single call with max_calls and max_paid_calls set, and the approver reads one prompt that names the ceiling. Each paid create inside still needs its own idempotency_key, and the response carries a calls[] journal you can read afterwards.

The other way to reduce noise is to remove the calls that never needed approval. Reads such as jobs_status, catalog_list, and balance_get are not spend events. If Kiro lets you mark tools as trusted for a workspace you do trust, mark the read tools and leave the paid ones prompting. In an untrusted workspace, accept the extra prompts; that is the situation the 2.26 change is aimed at, such as a repository you just cloned and have not reviewed.

A practical test: ask the agent to generate one image in an untrusted folder, count the prompts, and check that the second one carries dry_run. If it does not, tighten the instruction text.