- Book: Observability for LLM Applications
- Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
On November 5, AWS's Kiro team made bots generally available in Kiro Crew (InfoWorld). A bot is a named agent that owns one ongoing job, like triaging issues or watching CI, with its own memory, its own worker sessions and an optional schedule.
The launch post shows careful examples: a deployment bot that needs your approval before each change, and a review bot that "can leave comments and request changes, but it can't approve or merge." Those are bots you configure that way. A new bot doesn't start like that. Kiro's Manage bots page says "New bots start in Trust, except bots imported by an app, which start in Normal," and Trust "Acts without per-action approval, subject to security policy."
That security policy has its own default. Crew's sandbox ships in auto mode, which leaves .aws, .ssh and .kube visible to the shell commands the agent runs. Crew separately blocks direct file-tool reads of credential files, but a subprocess under auto can still reach those directories (Crew security). Read the defaults before you hand a bot your CI.
What shipped on November 5
Kiro Crew is Kiro's open-source agent workspace. Its docs describe it as running "locally or remotely on your hardware," with a desktop app, a web dashboard, a CLI and chat channels such as Slack, Discord and Telegram (Crew docs). Bots are the new layer on top.
Per the launch post, each bot gets a name, an avatar, one ongoing chat, a dashboard of its work and notes you can view, edit or delete. A bot can start worker sessions, redirect the ones that drift and collect their results. "You choose the model each bot runs on, and you can pick a different one for its worker agents," the post says. Its scheduling examples are to "check your CI pipeline every 30 minutes" and "prepare release notes every Friday."
SD Times reports that bots can run on a local machine, a Mac Mini or an EC2 instance. On price, Dataconomy reports that the launch "did not announce a separate per-bot charge." Bots run on Kiro credits. Kiro's pricing page lists Pro at $20 a month with 1,000 credits, and add-on credits at $0.04 each.
A bot in Kiro Crew is a supervisor: it starts worker sessions, watches them and reports back.
The defaults, from Kiro's own docs
Each row below is the documented default, linked to the page that states it.
| Setting | Default | What it means |
|---|---|---|
| Bot permission mode | Trust | Acts without per-action approval, subject to security policy |
| Worker permissions | Same as the bot | "Workers follow the same mode" |
| Crew approval level | Automatic | Calls that pass the deny, governance and sandbox gates run without a prompt |
| Sandbox | auto |
Hides .gnupg, .gcloud, .azure, .docker; leaves .aws, .ssh, .kube visible to agent subprocesses |
| Heartbeat on the goal card | Checked | Wakes the bot every hour once you approve a goal |
| Goal check-ins | Off | "All check-ins are disabled by default" |
The docs explain the auto default: it suits "Most users — allows git-over-SSH and AWS CLI" (Crew security). A bot that only labels issues needs neither.
Crew does a lot right here. Its security docs say "Denied commands and sensitive-path blocks are never bypassed — even in Autopilot mode," and the agent "cannot read .aws, .ssh, .gnupg, .env, and other credential files through tool calls." The sandbox is fail-closed when Crew can't apply it, and "Every tool call, approval, denial, and security event is recorded." A bot can ask for more tools, "but nothing changes until you approve the request" (Kiro blog).
Two lines in the docs are worth reading twice. The first is about memory: "Memory isolation is not a filesystem permission boundary" (How bots work). Each bot's notes stay separate, but that says nothing about which files it can open. The second is about Claude Code: "When you use the Claude Code harness, a tool already pre-approved in Claude's own settings bypasses Crew's approval flow. Crew's deny rules and audit log do not observe that call" (Crew security). If your Claude Code settings allow a tool, Crew won't ask about that call, and it won't block or log it either.
Heartbeat: the bot that wakes itself
Heartbeat is what makes a bot work while you're away. The How bots work page says "Heartbeat is off by default and requires a goal," with intervals of 30 minutes, 1 hour ("the default interval"), 2 hours or 4 hours. The quickstart fills in the rest: when you set that goal, "The goal card may also include a Heartbeat checkbox, selected by default."
So if the card shows that checkbox and you approve it unchanged, the bot wakes every hour. "Each wake consumes credits," the quickstart says. At the default interval that's 24 wakes a day, and 48 at the 30-minute setting. The docs don't give a per-wake credit figure, and it would vary anyway: "Agent runs consume credits, including worker activity and scheduled model calls" (How bots work).
Analysts in InfoWorld's coverage raised the same two worries. IDC's Dave McCarthy described a "coordination tax" from running workers through a supervisor bot, which InfoWorld ties to parallel retries and tool calls compounding token and compute costs. HFS Research's Ashish Chaturvedi warned of potential permission creep: developers getting used to approving a bot's requests for more tools without rechecking what they grant.
Heartbeat wakes a bot on a timer, hourly by default once it is on, and every wake spends credits.
What to change before you approve the first goal
These defaults suit a bot that does real work on day one. To start narrower, change these first.
- Drop the permission mode. New bots start in Trust. Set Normal ("Requests approval for actions except specified built-in operations") or Reads ("Allows reads without approval; asks before other changes except specified built-in operations") under Profile card → Settings → Permissions (Manage bots). Workers follow the bot's mode.
- Decide on Heartbeat before you approve the goal. Clear the checkbox on the goal card, or turn it off later in the first row of the bot's Schedules tab (Manage bots). If you want it on, a 4-hour interval wakes the bot 6 times a day instead of 24.
-
Use the strict sandbox where you can.
stricthides.aws,.sshand.kubetoo, and leaves only~/.ssh/known_hosts(Crew security). Since the docs pitchautoas the mode that allows git-over-SSH and the AWS CLI, expect the agent's SSH pushes and AWS CLI calls to need another route. - Check Claude Code's allow list. If you pick the Claude Code harness, review the tools pre-approved in Claude's own settings first, because Crew won't gate or log those calls (Crew security).
- Start with one job. Kiro's own advice: "Start with one responsibility that already makes you reconnect context across sessions" (Kiro blog).
- Read every permissions card. When a new-bot card shows a permissions warning, Crew makes you select "I understand this widens permissions" before the bot is created. Later permission changes arrive as cards with Apply change and Decline, and tool requests arrive as approval cards (Manage bots). Those later cards are where Chaturvedi's permission creep would come in.
The sandbox change is one command, using the form from the security docs:
# Hide ~/.aws, ~/.ssh and ~/.kube from agent commands
kirocrew config set agent.sandbox strict
I haven't run Kiro Crew or its bots myself. Everything above comes from Kiro's docs and the launch coverage.
If you'd rather approve each step yourself
I build Hermes IDE, so weigh this section with that in mind. Bots are Kiro's answer to a real problem: too many agent sessions to track by hand. Hermes takes the other route, where you stay the supervisor.
Kiro CLI is one of the agents Hermes runs in its own real terminal, next to Claude Code, Codex and the rest (Hermes README). Press ⌘N (Ctrl+Shift+N on Windows and Linux) and each task gets its own hermes/<name> branch and worktree. Every session shows a status such as "needs approval," and ⌘I jumps to the agent that has waited longest. Per the README, Hermes "never answers a permission prompt for you and never types into a terminal on its own."
The ⌘N agent picker in Hermes IDE 2.3.4, with Kiro CLI in the list next to Claude Code and Codex.
Hermes doesn't run Kiro bots or Crew, and it has no heartbeat or schedules, so it never starts work on its own. That's the trade. Hermes is free, source-available under BSL 1.1, and runs on macOS, Windows and Linux (download). It isn't affiliated with AWS, Kiro or any agent vendor.
Would you let a bot own your CI in Trust mode, or does it start in Normal until it earns more? Tell me in the comments.
If this was useful
A bot that wakes every hour and starts its own workers is an LLM feature running in production. You'll want to know what each wake did and what it cost. Observability for LLM Applications covers that side: tracing agent runs, watching cost, and catching quality regressions before your users do. If you run Kiro CLI next to other agents, Hermes IDE keeps each one on its own branch.
Top comments (1)
A trust-by-default lifecycle is backwards for persistent bots. The first-run posture should be least privilege, with an explicit capability review before the bot can access secrets, write to repositories, or run on a schedule. The review record needs to survive configuration changes; otherwise a later import or template update can silently recreate the original exposure.