Kiro IDE 1.2 asks before agent edits Hook files: where Sume key goes

Keep your Sume API key out of any file Kiro's agent can edit, and prefer the OAuth connector so there is no key to place. Kiro IDE 1.2 (2026-09-30) asks before the agent changes agent, Hook, or Power files, or the workflow recipes in .kiro/workflows/, and in untrusted workspaces it also asks before changing any other Kiro configuration and before each command runs (read 2026-10-03). A key written into one of those files would show up in an approval diff and in whatever the agent echoes about it.

The Kiro detail is on the changelog. The Sume guidance is in MCP OAuth and API keys: do not paste API keys into chat, prefer OAuth for interactive clients, and rotate any key that appears in logs or chat history.

Two ways to connect, two places for a secret

Sume's production endpoint is https://mcp.sume.com/mcp. Interactive clients should use OAuth: the client discovers metadata, you consent on the MCP host, and the token stays in the client. Nothing goes in a repo file. An API key is the path for automation that cannot do OAuth, and then the key must live somewhere a diff will never show it.

What the approval prompt will show

The changed behavior is an improvement for you: edits to agent configuration now go through a prompt, so a person sees them. Use that to review one thing every time, the MCP server entry. It should contain the URL and, at most, the name of a variable, never a value. If a prompt shows a long token-looking string, deny the edit and rotate that key.

It also gives a place to write a team rule. For example: the MCP entry may point at https://mcp.sume.com/mcp, nothing else, and a key may only arrive from the environment.

• Review the server URL character by character; a look-alike host is the real risk.
• Confirm the file holds no value that starts like a key.
• Check that no whitespace was pasted around a key; an invisible character breaks the header.

A pre-flight check

Before you hand a project to an agent, run this against the config files it may edit. It looks only for obvious literal keys and does not replace a real secret scanner.

#!/bin/sh
# usage: ./check-keys.sh <dir>
dir="${1:-.}"
if grep -rIn --exclude-dir=.git -E '(x-api-key|Authorization)[^\n]{0,40}(Bearer )?[A-Za-z0-9_-]{24,}' "$dir"; then
  echo "possible literal credential above; move it to an env var" >&2
  exit 1
fi
echo "no obvious literal credentials in $dir"

If the check trips, rotate the key before editing the file; Sume treats a key in a file or log as exposed. After the move, reconnect and call mcp_health once to confirm the auth source. Setup steps for the connection itself are in the Kiro MCP server post.

What to do when a key has already leaked

If the pre-flight check or a reviewer finds a key in a file, assume it is compromised, even if the repository is private. The order matters: create a replacement key in the dashboard, update the environment or secret manager where it lives, confirm the new one works with a read-only call, and only then revoke the old key. Revoking first leaves any running automation failing with auth errors while you hunt for the replacement.

Then clean the history if the file was committed; removing it from the latest commit does not remove it from earlier ones. After that, check recent activity with jobs_list and usage_get, both read tools, to see whether anything ran that you did not start. Sume's docs note that spend is wallet and admission based, so unexpected jobs are visible as jobs, not only as a balance change.

Finally, change the habit that put the key there. If it was pasted to get a quick connection working, switch that client to OAuth, which stores nothing in your files, or to an environment variable reference. A one-line team rule, never a literal key in an agent-editable file, is cheaper than the next rotation.