Kiro Security: Guardrails for Amazon Kiro IDE and Kiro CLI Agents

If you are reading about Kiro security because a migration landed on your desk, here is the timeline with AWS's own wording. These dates drive the budget conversation more than any feature comparison.

Two things about this migration deserve more attention than they get. The first is that the threat model changes underneath a product that looks like a continuation. Amazon Q Developer, in its IDE form, mostly suggested code and answered questions. Kiro plans work, edits across a codebase, runs commands and fires hooks. If your security sign-off predates May 2026, it approved the former and is being used to justify the latter.

The second is specific to teams also running Amazon Q Business, and AWS states it outright: the guardrails do not come with you. In the migration guide's words, "Q Business guardrails (global controls and topic-level controls) and Actions are explicitly excluded from the BYOI capability", which means "content filtering rules, blocked topics, and custom action configurations from your Q Business application will not transfer". AWS repeats the point in its validation advice, noting that guardrails configured in Q Business "will not apply through BYOI" and telling customers to verify that the replacement platform's native governance meets their requirements.

There is a quieter access-control change in the same document. For organizations not using IAM Identity Center, AWS says that because all users on the destination platform automatically receive access to connected indexes, "you lose the per-user and per-group access distinctions" that Q Business enforced at the index level, and that restoring granular access requires segmenting content into separate knowledge bases and assigning permissions programmatically. A migration that silently widens who can see what is a security event, not a project task. If your assistants read internal documents, the retrieval boundary is the thing to re-verify after cutover, and agent access control is where the work lands.

In July 2025 someone shipped a wiper prompt inside an official AWS developer extension. It is the clearest published example of the risk model that applies to any agentic coding tool, Kiro included, and AWS documented it without spin.

The payload was not an exploit in the traditional sense. It was English. An instruction telling an agent with filesystem and shell access to reduce the system toward a factory state and delete cloud resources needs no memory corruption and no privilege escalation, because the agent already holds the privileges. That is the entire lesson, and it survives the specific product: when a tool is designed to run commands on your behalf, the distance between "attacker controls some text the tool reads" and "attacker runs commands as you" is close to zero.

Three consequences carry directly into a Kiro deployment. First, the trust boundary is the extension and its dependencies, not just the model. A compromised update, a malicious MCP server, or a poisoned file in a repository the agent reads are all the same class of problem. Second, the failure was caught by luck, a syntax error, rather than by a control, which is worth stating plainly because AWS did. Third, blast radius is the only variable you actually own. Nobody prevented that release from shipping, but the damage a wiper prompt can do is bounded entirely by what the agent's environment can reach.

That is the practical argument for sandboxing coding agents and for keeping developer credentials short-lived and narrowly scoped. It is also why an immutable record of what the agent ran matters more for coding agents than for chat assistants: when the question is "did anything execute on that machine between the 17th and the 23rd", a local editor history is not an answer you can defend. The same reasoning applies across coding agents generally.

The most common Kiro security question in procurement is whether AWS trains on proprietary code. The answer depends entirely on which tier you are on, and the difference is stark. Verified against Kiro documentation in August 2026.

The row that causes real incidents is the second one. On Free and individual paid tiers, the training opt-out is a checkbox inside each developer's own settings. That is a per-machine setting with no central enforcement and no report telling an administrator who has flipped it. If your compliance position is that proprietary source code is never used for model training, an individual subscription cannot evidence that position, no matter how carefully each engineer configures their editor. The enterprise tier is the only one where the commitment is contractual and default.

Worth noting for teams mid-migration: the documentation treats an existing Amazon Q Developer Pro subscription accessed through an AWS account as excluded from content sharing. So the safest sequencing during a Q Developer to Kiro transition is often to keep enterprise identity in the loop from day one rather than letting developers self-serve individual subscriptions during the gap, which is exactly what tends to happen when a deadline is public and the procurement process is slow.

Data handling is only half of a Kiro security review. The other half is what the agent is permitted to do, which is a tool permission question rather than a privacy question, and it is not addressed by any tier.

We would rather lose the evaluation than win it dishonestly, so here is the split as we see it. Several rows below tell you to buy nothing.

The first three rows are the reason many readers should close this page. If Kiro sits on a handful of laptops working on a product with no regulated data, its native controls plus an enterprise subscription are a proportionate answer, and adding a runtime gateway would be spend without a matching risk. That is the honest recommendation and it costs us nothing to say.

The last two rows are where an external control earns its place, and the trigger is plurality rather than paranoia. One team on Kiro is a configuration problem. Four teams on Kiro, Cursor, Claude Code and an internal agent calling production APIs is a governance problem, because the policy now lives in four different formats maintained by four different people, and nobody can answer what an agent is allowed to do without opening four repositories. That is the point at which AI agent hardening stops being per-tool configuration and starts needing a single place to see and constrain agent behavior. If the agents also reach shared infrastructure through MCP servers, that boundary is usually the first one worth centralizing.

If you are surveying the category rather than shopping for us specifically, our writeup of the AI agent security vendor landscape covers who does what, including vendors whose developer-endpoint coverage is stronger than ours.