Kiro Crew: AWS Shipped the Right Guardrails - and Moved the Governance Problem

Kiro Crew is AWS's agent orchestration platform, and the pitch is concrete: hand it a ticket queue and it triages and dispatches, identifies owners, and flags what needs your attention. It runs multi-step engineering workflows spanning repos, tools and time. You can run several conversations concurrently, each with isolated context, or delegate independent research and implementation to subagents. It runs locally or on a remote machine you control, through a desktop app, a web dashboard, or a TUI.

It also ships with a security posture that deserves to be named, because it is the posture this field has been asking for and rarely gets: denied-by-default commands, suspicious-pattern blocking, input validation, sensitive-path blocking, credential redaction, OS-level sandboxing, and signed audit logs - described as defense in depth from day one. This guide credits that properly, then examines what it does and does not solve, because the honest answer is that AWS solved the in-product problem well and relocated the fleet problem rather than closing it.

What AWS got right

Four things, and none of them are cosmetic.

1. Denied-by-default commands. This is the correct default and almost nobody ships it, because allow-by-default demos better. It inverts the usual failure mode where a destructive command is possible until someone thinks to forbid it - the exact dynamic behind agents dropping databases.
2. Sensitive-path blocking. The direct descendant of their own CVE-2026-10591 fix, where mcp.json, .vscode/tasks.json and .git moved onto a protected-paths list. Blocking config and VCS paths closes the agent self-modification class at the file layer.
3. Credential redaction. Secrets do not transit where they do not need to. Given that MCP servers and agent shells inherit environment variables, redaction at the boundary is meaningful rather than decorative.
4. Signed audit logs. The genuinely notable one. Most agent logging is a local text file that the agent itself could rewrite - which makes it a diary, not evidence. Signing makes the record tamper-evident, which is what you need for an incident timeline that survives scrutiny. See AI agent audit trail and logging.

Read alongside the CVE, this is a vendor that took a real finding and generalised from it instead of patching narrowly. That is worth saying plainly, and it also validates where enforcement belongs: below the model, in the harness, where a prompt cannot negotiate with it. Nothing here relies on the model choosing to behave.

What the autonomy model changes

The most consequential line in the announcement is not a security feature. It is that Crew runs recurring jobs on schedules without requiring real-time human oversight. That is the product working as designed - unattended execution is the value - and it means approval-at-execution is deliberately not in the path.

So the whole weight of safety shifts onto the policy configured beforehand. That is a reasonable trade and it is how CI has worked for twenty years. But CI jobs are deterministic, and an agent deciding what to do next from content it reads at 03:00 is not. Every question that a human would have caught by glancing at a diff now has to be pre-answered in policy, and the ones nobody anticipated resolve however the model resolves them, unobserved, on a schedule.

The ticket-queue row deserves emphasis because it is easy to miss. If an agent triages a queue, then the queue is an input channel, and in most organisations filing a ticket is open to a wide population - sometimes including customers. Ticket text reaching an agent that can act on repos and CI is the same structural problem as a poisoned web page reaching Kiro in CVE-2026-10591, with a lower barrier to entry. Treat ticket bodies as untrusted content, and be careful about what an agent is permitted to do purely on their instruction.

Why good in-product controls are not fleet governance

Here is the structural limit, and it is not a criticism of the implementation. Crew's guardrails govern Crew. They are configured in Crew, enforced by Crew, and recorded in Crew's audit log. Meanwhile the same engineers are running Claude Code, Cursor, Copilot CLI and a set of MCP servers. Each has its own permission model, its own defaults, its own log format, and its own idea of what a sensitive path is.

That produces two concrete problems. Policy does not compose: *no writes to CI configuration* has to be expressed separately in each product's vocabulary, and drift between them is invisible until something slips through the weakest one. And evidence does not reconcile: answering *what did our agents do to this repository last week* means correlating several formats by hand, and only some of them are signed. This is the same gap as Entra Agent ID governing registered agents but not installed ones - excellent coverage of one region, with the seams between regions ungoverned.

There is also an inventory precondition, which Crew's own flexibility makes sharper: it runs locally or on a remote machine you control, through a desktop app, web dashboard or TUI. Those are different footprints. Knowing which endpoints and which remote hosts are running orchestration - and what each is scheduled to do unattended - is a discovery problem before it is a policy problem, and orchestrators arrive the way AI agents became the new shadow IT: adopted by a team that found them useful.

How Anomity fits

Anomity operates at the layer between products. The unprivileged Endpoint Sensor runs on Windows, macOS and Linux and inventories eight AI artifact types per endpoint - AI agents, MCP servers, extensions, plugins, skills, secrets, hooks and CLIs - so an orchestrator on a laptop or a self-managed host is an inventoried artifact with a first-seen timestamp rather than a team's private tooling choice.

Where an agent exposes a control point - for example the PreToolUse event in Claude Code - Anomity evaluates each call against policy and returns allow, deny, or log before it runs, and decisions land in one queryable 90-day audit trail routed to SIEM, Slack, email, or Jira. The point is not to replace Crew's guardrails, which are better than most and should stay on. It is that runtime governance expressed once, applied across every agent your fleet runs, is what makes *no writes to CI configuration* a fleet property instead of six product settings. Anomity collects metadata only, with on-endpoint secret redaction, is SOC 2 Type II, and complements existing tooling. See how it works.

You can't govern what you can't see.The Anomity principle

If you are adopting Kiro Crew

• Turn on and keep the shipped controls - denied-by-default commands, sensitive-path blocking, credential redaction, sandboxing. They are the good defaults; the failure mode is a team loosening them for one urgent job and never restoring them.
• Inventory where it runs. Local installs, remote hosts you manage, desktop app, web dashboard and TUI are different footprints, and unattended jobs on an unlisted host are the ones nobody reviews.
• Enumerate every scheduled job and treat the schedule as a standing grant of authority. Ask what each one is allowed to do at 03:00 with nobody watching, and whether that is still true six months from now.
• Treat ticket text as untrusted input. If the agent triages a queue, anyone who can file a ticket can address the agent - constrain what it may do on ticket instruction alone.
• Scope credentials per job rather than per platform. Fan-out means a broad credential is exercised by many agents in parallel, which is how one over-grant becomes a fleet-wide blast radius.
• Decide how you attribute actions across concurrent agents and subagents before you need to. Isolated context is good for correctness and bad for reconstruction, so verify the audit log distinguishes which subagent did what.
• Export the signed audit log into the same place your other agent evidence lands, so one query spans Crew, Claude Code, Cursor and MCP activity - see how to audit AI agent activity.
• Express your destructive-action policy once, outside any single product, and verify it holds in each - see least privilege for AI agents, Claude Code permissions and hooks hardening, and the destructive database guardrails guide.
• Extend your AI agent incident response playbook to unattended multi-agent runs: who pauses a schedule, how you establish which subagent acted, and how quickly you can revoke a job's credentials.

Kiro Crew is the most security-literate agent orchestrator to ship so far, and the shipped controls are the ones we would ask for - denied-by-default, sensitive paths, redaction, sandboxing, and a tamper-evident log. Credit where it is due, and it is also evidence that enforcement belongs below the model rather than in a prompt. What it does not do - what no single product can - is govern the seams. Scheduled, unattended, fanned-out execution across repos and CI raises the stakes on visibility precisely because approval is no longer in the path, and a fleet running several agent platforms has several control planes and several logs. Adopt Crew's guardrails, then make sure the same policy holds everywhere else your agents run. For the wider picture see securing AI coding agents and CLIs, ADLC for lifecycle placement, and Entra Agent ID for the identity half. To see which endpoints and hosts run agent orchestration today, request early access.