Recipe: Generate a Project-Specific AWS Kiro Steering File

The AWS Kiro Steering Files Agentic Thought describes the idea of carrying architecture-specific context into an AI coding workspace. This Recipe shows one technical way to put that idea into practice with the downloadable Kiro Steering File environment.

The environment is already configured with its component vocabulary, controls, policies, specification rules and output prompt. You do not need to author that configuration. You download or import the environment, model the project, select the project-specific controls and generate the output.

The result is one project overlay at:

.kiro/steering/steering.md

It supplements an organisation-wide Kiro steering baseline. It should not replace universal organisational rules or silently turn project-specific guidance into a global policy.

Recipe

1. Download or import the Kiro Steering File environment.

2. Select it for the project in iSecureByDesign.

3. Add an Application / Repository boundary to define the project scope.

4. Model the project components, connections and any Production Environment, Non-Production Environment or Trust Boundary elements.

5. Complete project-specific contract values such as technology, role description, purpose and implementation constraints.

6. Select the controls that apply to each component, including explicit false or none values when those are intentional scope decisions.

7. Generate the expanded specification.

8. Run the environment's Create report.

9. Review the generated .kiro/steering/steering.md and commit it to the project repository alongside the organisation-wide baseline.

The generated file is implementation guidance. It is not proof that the implementation satisfies the requirements. Review the output and evaluate the resulting code, configuration and infrastructure separately.

Example model

Use a small application scope containing:

• a client that calls an api
• an api that calls a service
• a service that accesses a data-store
• a production-environment boundary around the deployed components
• a trust-boundary around the external client boundary

The API could select:

• callerAuthentication: true
• authorizationModel: roleBased
• inputValidation: true
• networkExposure: controlled

The service could select leastPrivilegeExecution: true and auditLogging: true. The data store could select encryptionAtRest: true, authorizationModel: iamPolicy and changeIntegrity: true.

The production boundary makes leastPrivilegeExecution, auditLogging, changeIntegrity and resilienceAndRecovery applicable to contained components. The trust boundary makes caller authentication, authorization, input validation and network exposure applicable where relevant.

These policies add applicable controls; they do not silently set those controls to true. The project configuration must still make each control state explicit. If a control is false or authorizationModel is none, the generated steering file preserves that as a scope decision instead of inventing a substitute requirement.

Generated output

The Kiro environment generates one steering.md file with sections for scope, architecture rules, security controls, boundary rules, exceptions or conflicts and traceability. Normative rules receive stable KSR-... identifiers and cite the exact source identifiers that produced them.

A simplified example might look like this:

# Scope

This steering file is a project-specific overlay. It supplements the organisation's reusable steering baseline.

## Architecture Rules

- **Rule ID: KSR-api-input-validation**
  **Sources:** api.control.inputValidation, api.policy.NON_PRODUCTION_COMPONENT_BASELINE.inputValidation
  Validate and constrain untrusted inputs before processing or side effects.

## Security Controls

- **Rule ID: KSR-data-store-encryption**
  **Sources:** data-store.control.encryptionAtRest
  Encrypt sensitive persisted data, backups and relevant copies at rest.

## Boundary Rules

- **Rule ID: KSR-production-privileges**
  **Sources:** production-environment, service.policy.PRODUCTION_COMPONENT_CONTROLS.leastPrivilegeExecution
  Restrict production execution permissions to the minimum required by the component role.

## Exceptions or Conflicts

- Explicit false controls and `authorizationModel: none` are recorded as `false/scope-limited` rather than replaced with invented controls.

## Traceability

| Source ID | Source Type | Rule ID | Status |
| --- | --- | --- | --- |
| api.control.inputValidation | control | KSR-api-input-validation | applied |
| data-store.control.encryptionAtRest | control | KSR-data-store-encryption | applied |
| production-environment | boundary | KSR-production-privileges | applied |
| service.policy.PRODUCTION_COMPONENT_CONTROLS.leastPrivilegeExecution | policy | KSR-production-privileges | applied |
| api.control.authorizationModel | control | KSR-api-authorization | false/scope-limited |

The actual file contains traceability for every declared component, boundary, connection, contract value, control state and constraint. Connection source, target and contract values are retained so that the steering file reflects the modeled architecture rather than only a list of component-level recommendations.

Review the overlay

Before committing the file:

• Confirm that the scope is the intended application or repository.
• Check that each normative rule has a KSR-... rule ID and exact Sources.
• Review the traceability table for missing or unexpectedly out-of-scope items.
• Check the Exceptions or Conflicts section for false controls and incompatible settings.
• Confirm that the file supplements, rather than replaces, the organisation-wide steering baseline.
• Regenerate and review the file when the project diagram or policy selections change.

The Diagram Environments help explains how environments are selected, while the Outputs stage help describes how generated output is used.

Related Reading

• AWS Kiro Steering Files: How to Generate Architecture-Aware Guidance
• How to Generate Steering Files for AI Coding Tools
• AWS Kiro steering documentation

About Recipes: This Recipe contains a mixture of AI-assisted and human-written content. It began as an Agentic Thought and was developed through human editorial review, practical examples and implementation detail.