This image is licenced by iStockPhoto
This is guidance for security teams whose developers use AI coding agents -- specifically Kiro IDE (Amazon/AWS, currently in Public Preview). The aim: help developers write secure code from requirements through implementation, using Kiro's spec-driven workflow, steering files, agent hooks, and third-party integrations.
1. Spec-driven development: security starts at the spec
Kiro has a structured development pipeline built in: Requirements, Design, Tasks, Implementation. No plugins or extra configuration needed.
Why should security teams care? Because this creates natural checkpoints where someone can raise security concerns before any code gets generated. That's the whole shift-left idea, but here it actually has teeth -- the workflow won't let you skip straight to coding without going through requirements and design first.
Here's how the spec flow works:
In the requirements phase, Kiro generates structured requirements using EARS (Easy Approach to Requirements Syntax) notation. Each requirement follows "WHEN [condition] THE SYSTEM SHALL [expected behavior]" and includes testable acceptance criteria.
In the design phase, Kiro analyzes the existing codebase and produces a design document covering technical architecture, data flow, API definitions, and integration points.
In the tasks phase, the design gets broken into sequenced implementation tasks with dependencies mapped and acceptance criteria defined per task.
During implementation, the agent executes tasks in order, generating code that traces back to the spec artifacts.
Use specs over "vibe coding"
We'd push developers toward the spec workflow rather than ad-hoc prompting. Without specs, AI agents tend to produce code that works but skips input validation, error handling, auth checks, or other security controls. Thinking through requirements and design first is good practice for any developer -- it's even more important when an AI is writing the implementation.
2. Manual security review prompts (no configuration required)
The simplest approach -- zero setup -- is to prompt the agent for a security review after each spec document is generated. It works, but it depends on the developer remembering to do it.
Recommended prompts by phase
After requirements generation:
"I need to consider security requirements. Review these requirements and identify what security considerations are missing -- including authentication, authorization, input validation, data protection, rate limiting, audit logging, and error handling."
After design generation:
"You are a security architect. Review this design document and suggest changes to improve security. Consider the OWASP Top 10, data flow trust boundaries, encryption at rest and in transit, least-privilege access, and secure defaults."
After task generation:
"Review these implementation tasks. Are the instructions explicit enough to ensure the security requirements carry through? Flag any tasks that could produce insecure code if the security context gets lost during implementation."
After implementation (pre-PR):
"Perform a security-focused code review. Check for hardcoded secrets, SQL injection, XSS, insecure deserialization, missing auth checks, error handling that leaks information, and any deviations from the security requirements and design."
Each prompt maps to a stage in the development lifecycle, catching different issues where they're cheapest to fix.
3. Steering files: persistent, automated security guidance
Asking developers to remember security prompts at each phase is fragile. Steering files fix this by embedding security guidance into the project so Kiro's agent follows it automatically.
What are steering files?
Steering files are markdown documents in .kiro/steering/ that give Kiro persistent instructions. They capture conventions, patterns, and policies that should guide agent behavior across all interactions -- so you don't repeat yourself in every conversation.
They support three inclusion modes, configured via YAML frontmatter:
Always (default) -- loaded in every interaction. Good for universal security policies.
---
title: "Security Standards"
---
FileMatch -- loaded only when working with files matching a glob pattern. Good for domain-specific rules.
---
title: "API Security Standards"
inclusion: fileMatch
fileMatchPattern: "src/api/**/*.ts"
---
Manual -- loaded on-demand when referenced as #file-name in chat. Good for review checklists.
---
title: "Pre-PR Security Checklist"
inclusion: manual
---
Recommended steering file structure
Create these in your project's .kiro/steering/ directory:
security-standards.md (always loaded) -- Your organization's baseline security requirements for all code. Include required auth patterns, input validation rules, approved crypto libraries and configuration, secrets management approach (env vars, secrets manager -- never hardcoded), error handling standards, and dependency management policies.
security-requirements-review.md (always loaded) -- Tells the agent that when generating or reviewing requirements, it must check for: auth requirements, input validation, data protection (encryption at rest and in transit), rate limiting, audit logging, error handling and information disclosure prevention, and relevant compliance requirements (PCI-DSS, HIPAA, SOC 2, etc.).
secure-api-patterns.md (FileMatch on API files) -- Target your API file patterns (e.g., src/api/**/*.ts, src/routes/**/*.py). Include required auth middleware patterns, input validation schemas (Zod, Joi, Pydantic), parameterized query patterns, CORS configuration standards, rate limiting, and response sanitization rules.
secure-code-review.md (manual, referenced as #secure-code-review) -- A checklist the developer or agent invokes before creating a PR. Cover OWASP Top 10, secrets scanning, dependency vulnerability checks, auth coverage, input validation completeness, error handling, and logging adequacy.
How this changes the workflow
With steering files in place, the developer doesn't need to remember anything. When they start a spec, the agent already has security standards loaded. When they work on API files, the API-specific patterns activate automatically. Before a PR, they reference #secure-code-review for a full review.
4. Agent hooks: event-driven security automation
Hooks trigger automated agent actions when specific IDE events occur. Think of them as "when X happens, do Y" -- but the Y is powered by AI that understands code context.
Hook trigger types: fileEdit (file saved), fileCreate (new file created), fileDelete (file deleted), userTriggered (manual invocation).
Security-relevant hook examples
Credential scanning on save -- Hook on fileEdit for all source files. The agent scans for hardcoded secrets, API keys, tokens, passwords, and connection strings. If it finds any, it flags them and suggests using env vars or a secrets manager.
Security pattern validation on new API files -- Hook on fileCreate matching API route patterns. The agent verifies the new file includes auth middleware, input validation, and error handling consistent with the project's security standards.
Dependency security check -- Hook on fileEdit matching package.json, requirements.txt, or equivalent. The agent checks newly added dependencies for known vulnerabilities.
Test coverage verification -- Hook on fileEdit matching source files. The agent verifies that security-relevant test coverage exists (auth tests, authorization tests, input validation tests).
Creating hooks
Hooks live in .kiro/hooks/ as .kiro.hook files. You can create them by describing what you want in natural language -- Kiro generates the configuration. You can also configure them manually using the hook form in the IDE, specifying event type, file patterns, and instructions.
5. Powers: packaging security tooling and practices
For teams that want a reusable security package, Kiro's Powers system bundles tools, steering files, and workflows into a single installable unit that activates based on context.
What are powers?
A Power is a directory containing a POWER.md file (metadata and instructions), optional MCP server configurations (mcp.json), and optional steering files (steering/ directory). Powers activate dynamically based on keyword triggers -- when a developer mentions relevant terms, the power loads its context and tools.
Creating a security power
A security-focused power could include: steering files for your org's security standards, MCP server integrations with scanners like Snyk or Checkmarx, keyword triggers on terms like "security", "authentication", "vulnerability", and "encryption", and onboarding instructions for security tooling setup.
Example POWER.md structure:
---
name: "secure-development"
displayName: "Secure Development Standards"
description: "Organization security standards, vulnerability scanning, and secure coding patterns"
keywords: ["security", "auth", "authentication", "authorization", "vulnerability", "encryption", "owasp", "injection", "xss", "csrf"]
---
The instructions section would reference steering files for different security domains and provide onboarding steps.
Third-party security powers and integrations
Kiro has partnerships with security vendors for IDE-native integration:
Snyk Studio for Kiro -- Real-time vulnerability scanning in the development workflow. Snyk analyzes code as it's generated and suggests fixes before submission. You can configure it to always run snyk_code_scan on new first-party code.
Checkmarx Developer Assist -- Analyzes code and dependencies against existing Checkmarx One policies, bringing policy-driven checks into the IDE while maintaining centralized visibility for AppSec teams.
These are worth paying attention to because they bring organizational security policies into the AI development loop, rather than only catching issues in CI/CD. That's a real improvement over the status quo.
6. Layered security strategy: putting it all together
These approaches aren't mutually exclusive. Layer them for defense in depth:
Layer 1: Spec-driven development (baseline) -- Get all developers using the spec workflow instead of ad-hoc prompting. This alone creates review checkpoints at requirements, design, and task phases.
Layer 2: Steering files (automated guidance) -- Deploy steering files in .kiro/steering/ across all repos. This applies security standards consistently without relying on anyone's memory. At minimum, include an always-loaded security standards file and fileMatch-scoped files for sensitive code areas (APIs, auth, data access).
Layer 3: Agent hooks (event-driven checks) -- Configure hooks for high-risk events: credential scanning on save, security pattern validation on new file creation, dependency vulnerability checks. These catch issues the moment they're introduced.
Layer 4: Security powers and integrations (tooling) -- If you already use Snyk or Checkmarx, integrate them as Powers so scanning happens in the IDE during development, not just in CI/CD. Developers see and fix issues while they're still in context.
Layer 5: Manual review prompts (supplement) -- Even with automation, encourage developers to prompt for security reviews before creating PRs. The manual prompts are a final check and help build security awareness over time.
7. Important considerations and limitations
Kiro is in Public Preview. Features, pricing, and capabilities may change. The Powers and Hooks ecosystems are still young, and integrations will expand.
Specs don't auto-update. If implementation diverges from the spec, documentation drifts. Push developers to update specs when requirements change rather than just modifying code.
Steering files depend on inclusion mode configuration. If you scope a steering file wrong, it won't load when expected. Test steering file activation when you roll out security tooling.
Hook reliability depends on file pattern matching. Complex project structures may need careful pattern configuration to fire hooks on the right files.
AI-generated security is not a substitute for human review. AI agents can spot common vulnerability patterns and enforce known-good practices, but they'll miss novel attack vectors, business logic flaws, and context-specific requirements. Keep human security review for sensitive features and continue using traditional security testing (SAST, DAST, pen testing) alongside AI-assisted development. I'd honestly worry about teams that treat AI security checks as sufficient on their own.
Usage limits and cost. Kiro uses credits with two request types: vibe requests (chat) and spec requests (task executions from specs). The free tier includes 50 credits/month (vibe requests only -- no spec requests). Paid tiers: Pro ($20/month, 1,000 credits), Pro+ ($40/month, 2,000 credits), Power ($200/month, 10,000 credits). Overage runs $0.04 per vibe request and $0.20 per spec request. Since this guidance recommends spec-driven development, note that spec requests cost more and aren't available on the free tier. Heavy use of hooks and automated reviews will also burn credits. Plan capacity for team rollouts.
8. Quick reference
Approach | Setup effort | Reliability | Best for
Manual prompts | None | Depends on the developer | Quick start, small teams
Steering files | Low (create markdown files) | High (automatic loading) | Consistent standards across repos
Agent hooks | Medium (configure triggers) | High (event-driven) | Catching issues at introduction
Security powers | Medium-high (package + MCP) | High (integrated tooling) | Organizations with security tooling
References:
Kiro IDE: https://kiro.dev
Specs documentation: https://kiro.dev/docs/specs/
Steering documentation: https://kiro.dev/docs/steering/
Hooks documentation: https://kiro.dev/docs/hooks/
Powers documentation: https://kiro.dev/docs/powers/
Privacy and security: https://kiro.dev/docs/privacy-and-security/
Snyk Studio for Kiro: https://snyk.io/blog/snyk-kiro-partner-integration/
Kiro Powers repository: https://github.com/kirodotdev/powers
About The Author
Brian Glas has over 21 years of experience in various roles in IT, with the majority in application development and security. In his "day job," he serves as department chair of computer science and cybersecurity at Union University in Jackson, Tenn. He helped build FedEx's Application Security team, worked on the Trustworthy Computing team at Microsoft, consulted on software security for years, and served as a project lead and active contributor for SAMM v1.1-2.0+ and OWASP Top 10 2017, 2021, and beyond.
Brian is a contributor to the RABET-V Program for assessing non-voting election technology. He holds several cybersecurity and IT certifications and is working on his Doctor of Computer Science degree in cybersecurity and information assurance.
Stay in the loop.
Subscribe for the latest in AI, Security, Cloud, and more—straight to your inbox.
