AWS Kiro Steering Files: From Architecture Models to Agent Guidance
AWS Kiro steering files can carry architecture-specific implementation guidance into an AI-assisted development workspace. This Agentic Thought explores how architecture models and policy controls could provide that guidance without replacing requirements, testing or organisational governance.
For a technical example using the downloadable environment, see the AWS Kiro Steering File Recipe.
The idea in brief
AWS Kiro steering files can carry persistent project context into an AI coding workspace. An architecture model can provide the source for that context by identifying components, boundaries, security objectives and implementation constraints that the agent should remember while working.
This is different from generating requirements. Requirements describe what the system must satisfy; steering guidance helps keep the agent oriented while implementing those requirements.
AWS Kiro uses persistent Markdown steering files to give its agent knowledge about a workspace. The files can describe product context, technology choices, project structure, coding standards, testing practices and architecture decisions.
Kiro supports workspace steering files under .kiro/steering/, including foundational files such as product.md, tech.md and structure.md. It also supports focused guidance that is always included, loaded for matching files, requested manually, or selected automatically from a description. See the Kiro steering documentation for the current file conventions.
The useful question for iSecureByDesign users is: which parts of the architecture should become Kiro guidance for this project?
The answer is not the entire architecture document. It is the small set of boundaries, approved patterns and security expectations that should remain visible while the agent works.
What are AWS Kiro steering files?
AWS Kiro steering files are persistent Markdown files that provide workspace or project context to Kiro while it works. They can describe architecture decisions, technology choices, coding patterns, testing expectations and security boundaries.
The useful content is not a generic instruction to “write secure code”. It is project-specific guidance such as:
- which service owns a particular data access path
- which boundaries must not be bypassed
- which identity and authorization patterns are approved
- which controls apply to a component or connection
- which tests or evidence should accompany an implementation
A model-driven workflow
An environment configured for steering-file output can use the following workflow:
1. Model the components, connections and boundaries.
2. Add specification blocks for product, technology, structure, security and testing guidance.
3. Apply the controls that are relevant to the selected components.
4. Generate the requirements specification.
5. Use an output prompt configured for Kiro Markdown and inclusion modes.
6. Export focused files into .kiro/steering/.
For example, a database component might produce a focused Kiro file requiring the approved data-access layer, encryption, authorization checks and tests for denied access. An API component might produce file-matched guidance for route handlers and integration tests.
The important distinction is between the source and the format. The architecture and policy choices determine what guidance applies; the output prompt formats that guidance for Kiro.
Requirements versus steering guidance
Requirements and steering guidance complement one another, but they are not interchangeable.
| Requirements | Steering guidance |
|---|---|
| Describe what the system must satisfy | Provides persistent context while the agent works |
| Can become acceptance criteria and evaluation checks | Helps shape repeated implementation decisions |
| Are often feature or component focused | Is often project, repository or workspace focused |
| Should be traceable to architecture and policy | Should preserve the relevant architecture context |
Architecture-derived steering is not a replacement for requirements, testing or review. It is persistent implementation context that helps an AI coding agent apply the requirements within the intended architecture.
The architecture model remains the source of project context. Policy and control selections determine which requirements and constraints apply. The Kiro steering file is one delivery format for carrying that guidance into the repository.
How this idea can be implemented
iSecureByDesign now provides a downloadable Kiro Steering File environment that demonstrates this approach. It is configured to generate a project overlay at .kiro/steering/steering.md rather than an organisation-wide baseline.
The environment preserves project-specific components, boundaries, connections, contract values, selected controls and constraints in the generated output. The resulting steering file uses stable rule identifiers and source traceability so that a team can inspect why a rule was included.
The AWS Kiro Steering File Recipe provides the technical walkthrough, including the project setup, control selections and an example of the generated output.
Keep Kiro steering focused
Do not put every organisational policy into every steering file. Use always-included files for core project context, file-matched files for technology or directory-specific rules, and manual or automatic guidance for specialist workflows.
This is a practical form of Executable Context: the agent receives the architecture and policy context relevant to the work rather than an undifferentiated policy library.
iSecureByDesign users can explore this with a diagram environment configured for Kiro-specific specification blocks and an output prompt. For a technical sample using the downloadable environment, see the AWS Kiro Steering File Recipe.
Are steering files enough to govern AI-generated code?
No. Steering files are useful guidance, but they do not guarantee that an AI coding agent will comply or that the resulting implementation is secure. Teams still need requirements review, code review, testing, evaluation and appropriate runtime controls.
The value of architecture-derived steering is that it makes the intended context available during implementation and gives reviewers a clearer connection between the model, the policy decisions and the guidance supplied to the agent.
Frequently asked questions
Does iSecureByDesign replace AWS Kiro?
No. Kiro remains the AI coding environment. iSecureByDesign provides architecture-derived requirements and project-specific guidance that can be carried into Kiro.
Are Kiro steering files the same as requirements?
No. Requirements describe what the system must satisfy. Steering files provide persistent project context that helps guide the agent while it implements those requirements.
Does a steering file guarantee secure code?
No. Steering files are guidance. Teams still need code review, testing, evaluation and appropriate runtime controls.
Related Reading
- AI Coding Assistant Governance
- Specification stage help
- Kiro first project guidance
- GitLab Duo Agent Configuration YAML
- AI Coding Rules vs Steering Files
- AWS Kiro Steering File Recipe
About Agentic Thoughts: This Agentic Thought was generated with AI. Agentic Thoughts are part of an ongoing process of evolving ideas about iSecureByDesign and how it may be applied to real-world problems. They are exploratory and do not necessarily represent a final product commitment, implementation, or formal advice.