Your AI Coding Agent Has Requirements. But Who Is Steering It?

AI coding agents are becoming implementation actors. They can plan work, modify multiple files, run commands, create tests and implement substantial features rather than only completing the next line of code.

That changes the security question.

It is no longer enough to ask whether the developer received the security requirements. We also need to ask:

What security context did the agent have while making implementation decisions?

Requirements are necessary

iSecureByDesign already generates structured requirements documentation from an application's architecture and security context. Those requirements can be supplied to an AI coding workflow such as Kiro.

Requirements are well suited to statements such as:

authentication must use the organisation's approved identity provider
sensitive data must be encrypted
an API must require authorization
secrets must not be stored in source code

These statements describe properties the resulting system needs to satisfy. They can be reviewed, implemented and evaluated.

But an agent makes hundreds of smaller decisions while implementing a feature. Requirements may state the desired outcome without remaining present as context during every design and coding choice.

Steering addresses a different layer

Kiro steering files provide persistent project-level instructions and context that can influence how the agent works. They can describe architecture decisions, technology constraints, coding patterns, testing expectations and security boundaries.

This creates a useful separation:

Architecture -> Requirements -> What must be true

Architecture -> Steering -> How the agent should reason and operate while implementing it

Requirements and steering should complement each other. Steering does not replace acceptance criteria, and requirements do not necessarily replace the persistent context an agent needs while navigating a repository.

Architecture is a valuable source of steering context

Suppose an architecture model establishes that:

the frontend is untrusted
authentication is performed through a specific identity service
personally identifiable information exists in one datastore
services communicate through defined interfaces
internet-facing components sit behind an API gateway

A generic coding agent may not understand the security implications of those relationships. Architecture-derived steering could express them as persistent instructions:

Treat all client-supplied identity information as untrusted.

Do not introduce direct browser-to-database communication.

New externally accessible endpoints must use the existing API gateway and authentication mechanism.

Do not persist personally identifiable information outside the designated datastore.

These are not generic “write secure code” instructions. They are constraints derived from this particular architecture.

Requirements versus steering

Requirements	Steering
Describe required outcomes	Influences implementation behaviour
Often feature or task focused	Provides persistent project context
Can be tested for completion	Applies throughout agent activity
Tell the agent what must exist	Tell the agent which boundaries to respect
Already generated by iSecureByDesign	A potential additional output

The distinction is not absolute. A steering instruction may refer to a requirement, and an evaluation can check both. The useful point is to avoid treating one artifact as if it solves every problem.

Steering also should not become an enormous security policy copied into the agent's context. The useful steering set is the subset of architectural knowledge that should influence implementation decisions repeatedly.

Architecture as Executable Knowledge

Traditional architecture often follows this path:

Architecture -> diagram -> document -> human interpretation

An emerging model is:

Architecture -> structured model -> security requirements + implementation constraints + agent steering

This is the broader idea behind Architecture as Executable Knowledge. The architecture stops being merely descriptive and begins actively influencing how software is created.

Executable Context describes the task-relevant part of that knowledge: the context an agent needs now, for the component and decision currently being worked on.

Where this could go next

iSecureByDesign already generates Kiro requirements documentation. The downloadable AWS Kiro Steering File environment demonstrates an architecture-derived, project-specific steering-file workflow. The AWS Kiro Steering File recipe explains how to use it; it complements rather than replaces an organisation-wide steering baseline.

The current experimental environment generates a file such as:

/.kiro/steering/security-architecture.md

containing only the persistent architectural constraints relevant to AI-assisted development. It could sit alongside the requirements documents already produced by the requirements workflow.

The same architecture-derived knowledge could potentially support:

Kiro steering files
agent skills
coding-agent instructions
policy-as-code
CI/CD controls
security tests
runtime agent policies
evaluation criteria

That suggests a broader lifecycle:

Design -> constrain -> implement -> evaluate

The value is not that one file governs everything. The value is that the same architectural knowledge can remain connected across multiple stages instead of being recreated separately for each tool.

The larger implication

Security requirements tell an AI agent what the system must do. Architecture-derived steering tells it what it must never forget while building it.

As AI agents take on more responsibility for implementation, architecture may become more important rather than less important. But architecture needs to change form.

A diagram that an AI agent never sees cannot influence its decisions. The opportunity is to turn architectural intent into machine-consumable requirements, constraints and steering that remain connected to the software-development process.

That is what it means for architecture to become executable knowledge.

How iSecureByDesign fits

iSecureByDesign is not another AI coding assistant. Coding agents generate software; iSecureByDesign provides architecture-derived knowledge that can help constrain how that software should be built.

Users can model the architecture, apply policy and security context, generate requirements, and evaluate implementation outputs. A future steering-file workflow could extend that chain by turning the relevant architectural constraints into persistent agent context.

See AI Coding Tool Policy Management and the Specification stage help for the current model-to-requirements workflow.

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.