Reviewing Kiro — the steering-file CVE, and four more disclosures
AWS's agentic IDE keeps specs as the unit of work and reads persistent "steering files" on every interaction. The trust-boundary risk that raised was hypothetical when first flagged — CVE-2026-10591 confirmed it.
Kiro is AWS's agentic IDE, reaching general availability in May 2026 with a distinguishing bet: specs, not just code, are the unit of work. Before Kiro writes code, it produces requirements, a design document, and a task list, and those artifacts stay in the repository as the source of truth — a structural answer to the failure mode where an agent's intent lives only in an ephemeral chat history nobody reviews. Kiro's reasoning runs on Anthropic's Claude models served through Amazon Bedrock.
Kiro, briefly
Spec-driven development genuinely helps with one class of problem — “what was this agent even trying to do” — by leaving a reviewable artifact behind. It doesn't automatically solve a different class: what persistent context the agent trusts on every interaction, and what happens when that context is manipulated.
Steering files are the same surface as rules files
Same mechanism, different disclosure status
| AI rules files (Copilot / Cursor) | Kiro's steering files | |
|---|---|---|
| What it is | Persistent Markdown/config context read automatically on every interaction (GitHub Copilot, Cursor). | Persistent Markdown context — conventions, architecture, security requirements — read automatically on every interaction. |
| Disclosed vulnerability | Yes — the Rules File Backdoor (Pillar Security): hidden Unicode can silently steer generated code. | Yes, since this was first drafted — CVE-2026-10591 (Intezer/Kodem Security), disclosed against Kiro's config-write path, following the exact pattern predicted below. |
| Realistic entry point | A shared template or config repo pulled in for faster onboarding. | The same pattern would apply to a steering file adopted from an external template. |
| Review question | Audit any externally-sourced rules file for hidden Unicode or suspicious instructions. | The same audit, applied proactively — before a disclosure forces the question. |
That parallel is no longer hypothetical. The review question is the same either way: steering files pulled from a shared template or an external source deserve the same audit as any other rules/config file an agent trusts automatically.
The prediction became a disclosure — plus four more CVEs
Kiro has since accumulated a real CVE trail beyond this one: CVE-2026-0830, a command-injection flaw triggered by opening a workspace with a maliciously crafted folder name (fixed in 0.6.18); CVE-2026-4295, improper trust-boundary enforcement allowing code execution simply from opening a crafted project directory (fixed in 0.8.0); and CVE-2026-18656/CVE-2026-18657, a Windows-only uncontrolled search-path issue where a planted executable in a project directory resolves before the system PATH (fixed in IDE 1.0.228 / CLI 2.10.0). Separately, Mindgard disclosed a no-CVE-assigned data-exfiltration technique via “Kiro Powers” — bundles of MCP config, steering files, and hooks — where opening a malicious workspace file and sending any message triggered exfiltration without the user ever requesting data access; AWS had already patched it (v0.8.140) roughly seven months before the public writeup.
The pattern across all of these: opening a folder, a project, or a web page — none of them privileged actions — was consistently enough to trigger code execution or exfiltration. A review of Kiro can't treat “we only open trusted repositories” as a sufficient control, since several of these were exploitable through content the agent merely read, not a repository the developer chose to clone.
Event-driven hooks — automation with its own blast radius
Kiro's Hooks fire on file save, PR open, and other repo events to run tests, update docs, regenerate fixtures, or cascade spec changes without manual prompting. That's real productivity — and it's also an automation trigger surface: anything that can open a PR or modify a file in a repository where hooks are configured can potentially trigger agent action indirectly, the same category of concern as the comment-injection issue affecting several coding agents (see the Copilot post for that specific disclosure).
Governance specifics for regulated deployments
Kiro bundles IP indemnification for its output with its Pro/Pro+/Pro Max/Power tiers, and its enterprise offering adds IAM/SSO integration, spend controls, and (since March 2026) admin controls to allow-list which MCP integrations are permitted and restrict which models can be used organization-wide. Kiro is HIPAA-eligible and available on AWS GovCloud (US) with TLS 1.2+ cross-region encryption, and is pursuing FedRAMP High and DoD CC SRG authorization. None of that changes the CVE picture above — a regulated deployment still needs the same patch and file-write-access review as any other, on top of confirming the specific compliance posture actually matches the requirement in question rather than a general marketing claim.
Review checklist
For any team using Kiro, a design-time review should be able to answer:
- Is the installed Kiro IDE/CLI version past 0.11.130 (CVE-2026-10591), 1.0.228/2.10.0 (CVE-2026-18656/18657), and the other CVEs listed above?
- Have steering files been audited the same way a rules/config file from GitHub Copilot or Cursor would be — for hidden Unicode or suspicious instructions, especially any adopted from external templates?
- What events can trigger a Hook, and who can create those triggering events (open a PR, push a commit) in repositories where Hooks are active?
- Are Kiro's spec artifacts (requirements, design docs, task lists) actually reviewed as part of the PR process, or generated and merged without a human reading them?
- For regulated-industry or government use cases, has the governance/IP-indemnification posture been verified against the specific compliance requirement, not assumed from marketing material?
Sources
Blog
Get new posts in your inbox
AI security review, OWASP Agentic Top 10, ISO 42001 evidence, and what AI Committees actually need. No cadence promises — we publish when there's something worth reading.
Review a Kiro deployment before it ships
Steering-file provenance, Hook trigger surfaces, and spec-review practice — mapped to a disposition your AI Committee can act on.
A note on scope: Drel reviews assessed systems against documented architecture, configuration and intent. It does not ingest live telemetry from production environments. Dispositions reflect the assessed system at the time of review and the re-assessment triggers that govern when the disposition must be revisited.