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.
- Aikido's Kiro Power makes security a precondition for completion, not a review after the fact.
- The repo is small because its leverage comes from MCP orchestration and agent instructions, not from a standalone scanner.
- The important engineering choice is the remediation loop, which forces scan, fix, and rescan to happen in sequence with a hard stop.
- In Kiro terms, Aikido is using a Power as policy, not just as context.
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.
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.
| Workflow | When it runs | Who reacts | Main trade-off |
|---|---|---|---|
| Manual security review | After code is finished | Security team or reviewer | Problems become backlog items |
| CI scanner | On commit or push | Pipeline | Feedback arrives after the agent has moved on |
| Aikido Kiro Power | On write, before task completion | The coding agent and Aikido MCP | Tighter 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.