aikido-kiro-power: Aikido's Kiro Power turns security into a write-time gate

This tiny repo does not scan code itself. It teaches Kiro to stop, check, fix, and rescan before unsafe code can move forward.

8 min read · AikidoSec/aikido-kiro-power

A black ink editorial illustration of fresh pages moving through a narrow security gate at a drafting desk. It shows code being checked at the moment of creation, not after it has already left the editor.
The point of the integration is not more scanning. It is making security part of the act of writing.
Key Takeaways

The security gate moved inside the editor

Security tools usually arrive after the interesting part is over. Code exists, the pull request exists, and a human has to come back later with a ticket or a red build. Aikido's Kiro Power flips that sequence. It makes security a condition for finishing the task inside Kiro, which is a much stronger place to enforce it.

That matters because this repo is not a scanner engine. It is an integration layer for AikidoSec/aikido-kiro-power, built around Kiro's Power model and Aikido's MCP service. The actual scanning work lives in @aikidosec/mcp, while this repository tells Kiro when to call it and how to react when the result is not clean.

A small repo with a large job

The structure is almost aggressively simple: mcp.json launches the MCP server, POWER.md defines the behavior, and README.md explains setup. That simplicity is the clue. The repo is a control plane, not the plane itself.

The bridge uses environment variable injection, so Kiro can pass AIKIDO_API_KEY without hardcoding secrets. That is a classic sidecar pattern. The agent stays in charge of the editor loop, while the security service stays outside the main application boundary.

How the loop works

The core move in POWER.md is a reactive hook. Kiro writes a file, the hook fires, the agent asks Aikido to scan the changed code, and remediation guidance comes back into the same conversation. The main abstraction is aikido_full_scan, which can work on provided code files rather than waiting for a traditional commit-and-run cycle.

This is not a report-and-wait scanner. It is a closed loop that keeps the agent inside the fix process until the result clears or the retry limit is hit.

The loop is guarded on purpose. The instructions cap remediation at three attempts, which is practical, not timid. It keeps the agent from spiraling when a finding is noisy or when a fix creates a new issue. The repo also acknowledges a 50-file batching limit, which tells you this was designed for real diffs, not demo-sized changes.

What makes it different

Most security tooling is pull-based or pipeline-based. You run a scan, or CI runs a scan, and then someone decides what to do with the result. This Power is push-based. Kiro is not allowed to quietly move on until the scan says the file is acceptable.

That changes the unit of work. Instead of opening a security ticket after the fact, the agent gets the feedback while the context is still hot. If shift left means earlier feedback, this is closer to shift zero. The check happens before the developer has mentally left the task.

WorkflowWhen it runsWho reactsMain trade-off
Manual security reviewAfter code is finishedSecurity team or reviewerProblems become backlog items
CI scannerOn commit or pushPipelineFeedback arrives after the agent has moved on
Aikido Kiro PowerOn write, before task completionThe coding agent and Aikido MCPTighter control, less freedom

That is also why the project matters in the broader Kiro Power ecosystem. Kiro Powers are usually about loading the right capability only when needed, so the agent does not drown in irrelevant context. Aikido uses the same delivery model, but the purpose is stricter than convenience. It turns a Power into policy.

Seen next to Aikido Infinite and the wider security automation market, the direction is obvious. Security is moving from a separate review lane to an embedded constraint on agentic development. The interesting question is no longer whether a scanner can find a vulnerability. It is whether the assistant can be prevented from finishing until the vulnerability is gone.