ISGroup CyberSecurity Consulting

AWS Kiro and spec-driven development: structure, security, and pre-go-live checks

AWS Kiro e spec-driven development tra struttura e sicurezza

AWS Kiro and spec-driven development: more structure does not automatically mean more security

Kiro addresses a real need for teams that have tried “vibe coding”: less chaos, more context, more readable specifications, better-organized tasks, and documentation that stays closer to the code. Spec-driven development brings useful discipline to AI-assisted development, especially when the project is no longer just a demo but a feature, a service, an internal platform, or an app intended for real users.

🔴 Web Application Penetration Testing: identify hidden risks and strengthen your security with a focused assessment by ISGroup specialists.

The critical point is not to confuse structure with security. A well-written specification can describe a vulnerable architecture. A requirement in EARS can be formally clear while saying nothing about tenant isolation, privilege escalation, secret management, or API abuse. An implementation plan can be orderly and cover only the “happy path.” Before deploying, the useful question is not whether Kiro makes the code more organized, but whether the requirements, design, tasks, hooks, MCP, tests, and implementation contain sufficient security controls to connect real data, users, APIs, cloud, and enterprise systems.

What spec-driven development improves and what it doesn’t cover

Kiro moves the team from natural prompts to structured requirements, design, and executable tasks, reducing part of the risk typical of vibe coding: implicit decisions, outdated documentation, and features generated in an impromptu manner that are difficult to maintain. Structure, however, does not guarantee that the requirements are correct. If a specification does not include roles, sensitive data, object-level permissions, rate limits, logs, retention, trust boundaries, error handling, and abuse cases, the agent may consistently implement a product that is incomplete from a security perspective.

The same applies to tests. A well-generated plan may verify that the user can complete the intended flow, but this does not prove that a user from another tenant cannot read the same record, that an API does not accept arbitrary IDs, that an IAM policy is not too broad, or that a hook does not execute unreviewed commands.

The risk of the perfect but incomplete specification

Specifications help make intent explicit, but if that initial intent does not include security, privacy, and abuse, the output remains fragile. A sentence like “the user can view their own documents” must become verifiable: which documents, with what identity, with what roles, what happens if the ID changes, what happens with an expired token, what happens if a tenant admin tries to read another tenant’s data.

Kiro can help transform requirements into tasks, but the quality of the result depends on the quality of the requirements themselves. This is why every specification intended for an exposed function should include negative acceptance criteria: access denied, input rejected, unauthorized file, insufficient role, wrong tenant, expired token, non-allowlisted callback, unlogged secret. A specification that says nothing about what must be blocked leaves too much room for the agent’s implementation, with the risk of producing reassuring documentation that shows what the app must do, but not what it must not allow.

Threat modeling within the spec-driven process

Threat modeling should not become a heavy document separate from development. In a Kiro workflow, it can be integrated into the requirements and design phase, covering assets, actors, trust boundaries, sensitive data, external systems, privileges, flows, and failure modes. For every spec, the team should ask what data is processed, what roles exist, what actions are sensitive, what APIs are public, what external systems are called, what secrets are needed, and what cloud commands or resources will be touched. If the app is multi-tenant, tenant isolation must be a first-class requirement, not an implementation note.

The design generated or assisted by Kiro must also be read with an offensive mindset: how could it be abused? Can an invitation flow be reused? Can a password reset reveal users? Is an admin route truly protected server-side? Can an upload serve active content? Does an IaC task create resources accessible from the internet?

Agent Hooks: useful automation, a surface to govern

Agent Hooks are one of Kiro’s most specific elements. They can trigger on events such as prompt submission, agent stop, pre/post tool use, file creation or saving, file deletion, task execution, and manual triggers, with actions that include prompting the agent or running shell commands. This automation can be very useful for formatting code, updating documentation, generating tests, checking standards, blocking tools, or enriching context. However, it can become a critical surface if it executes commands, modifies files, installs dependencies, runs tests, interacts with cloud CLIs, or changes configurations without review.

Before adopting hooks in a team, it is advisable to take an inventory of .kiro/hooks files, the events that trigger them, the actions performed, and the permissions available in the repository. Shell commands should be treated as operational code: who approves them, what can they read, what can they write, what environment variables do they see, can they execute deploys, deletes, migrations, or cloud commands? A hook that runs on file save should not be able to apply Terraform, delete resources, install unapproved packages, or send sensitive data to external systems. High-impact automations must have thresholds, logs, and separate approval.

Steering files and project rules

Kiro allows you to guide agents with steering files and project rules, making conventions, standards, and preferences explicit. Here too, however, persistent instructions become part of the security perimeter. A rule that pushes the agent to “make tests pass,” “use mocks when services are missing,” “simplify authentication,” or “proceed even if the context is incomplete” can normalize risky shortcuts. Conversely, well-written rules can prevent auth modifications without negative tests, block secrets in the frontend, require reviews on IAM/IaC, and impose default deny on policies.

Steering files must be reviewed like code. They must separate style, architecture, and security, avoid secrets and unnecessary internal endpoints, and not contain ambiguous instructions. Every change to these files should go through a PR review because it influences all future tasks.

MCP, external tools, and specification context

Kiro supports MCP and can connect to documentation, databases, APIs, AWS tools, Terraform, or other systems, greatly increasing the quality of the context but also expanding the workflow’s trust boundaries. If an MCP server provides access to databases, tickets, repositories, cloud, internal documentation, or Terraform registries, the agent can incorporate that information into the specification and implementation decisions. The risk is not MCP itself, but the use of tools and credentials that are too broad: shared tokens, read-write permissions when read-only suffices, access to real data during design, or deploy tools available in uncontrolled phases.

MCP governance for Kiro should include server allowlists, dedicated tokens, minimal privileges, separation between project and global configurations, audit of tool calls, and disabling unnecessary tools on critical repositories. If AWS or Terraform tools are used, the resulting changes must pass IaC review and approval before application.

Terraform, IaC, and cloud: when the spec creates infrastructure

One of the most delicate scenarios is using Kiro to design or generate infrastructure: Terraform, CloudFormation, CDK, security groups, IAM, VPC, databases, storage, load balancers, pipelines. The specification can make the work orderly, but the cloud risk remains concrete. A spec that asks to “create an environment for the app” can lead to wide security groups, public buckets, generic IAM roles, reachable databases, outputs with secrets, poorly separated dev/prod environments, and a lack of encryption, logging, or backups. The result may be consistent with the request and yet unacceptable in production.

Before applying IaC generated or modified with Kiro, you need plan diffs, IaC scanners, manual review, least privilege checks, tagging, environment separation, rollback plans, and explicit approval on critical resources. The application of IaC should not be a side effect of an agentic task or a hook.

Generated tests: functional, not necessarily offensive

Kiro can help generate tests linked to requirements, but tests derived from the specification tend to verify that the system does what was requested. Security also requires demonstrating that the system rejects what it must not allow. For every exposed feature, negative tests are needed: unauthenticated user, insufficient role, wrong tenant, another user’s object, malicious input, invalid file, out-of-sequence request, expired token, rate limit, non-allowlisted callback, controlled error. If these cases do not enter the specification, the agent is unlikely to cover them robustly.

Automatic tests should then be accompanied by Code Reviews and, when apps or APIs are online, by manual WAPT. The most serious vulnerabilities are often not syntactic bugs, but inconsistencies between requirements, implementation, and actual behavior.

Drift between spec, implementation, and documentation

One of the advantages of spec-driven development is keeping intention, design, and implementation together. The risk is believing that this traceability is automatic and always correct. During development, the agent may discover that the spec is incomplete and modify the implementation; the developer may accept a workaround without updating requirements and design; a hook may update documentation that describes what should happen, not what the code actually applies. The spec can remain orderly and become false.

For security areas, traceability must be verified: every access control requirement must have an implementation, a positive test, a negative test, and an owner. Every trust boundary must have controls in the design and code. Every accepted exception must have a motivation and remediation.

Permission fatigue and approvals

Kiro can introduce many approval points: tasks, hooks, tool use, shell commands, MCP, file changes, tests, PRs, IaC. If everything requires the same level of attention, the team risks permission fatigue and ends up accepting things automatically. The solution is not to block everything, but to classify risk. Formatting, documentation, and local refactoring can have a light path, while auth, IAM, secrets, public APIs, databases, storage, migrations, deploys, deletes, Terraform, and cloud CLI must have stronger approvals and competent reviewers. This distinction must be decided before Kiro enters the production workflow, because if the rule is improvised during an urgent release, the team will tend to prioritize speed.

Kiro checklist before go-live

Specifications and design

  • Reread the EARS requirements and verify that they include security, roles, data, authorizations, tenant isolation, logging, error handling, retention, and abuse cases.
  • Add negative acceptance criteria for what must be rejected.
  • Link every critical requirement to design, tasks, code, and tests.

Hooks, steering, and MCP

  • Inventory .kiro/hooks, triggers, shell commands, prompt actions, and involved tools.
  • Review steering files as code.
  • Catalog MCP servers, tokens, privileges, accessible data, and available tools.
  • Disable what is not needed on critical repositories.

Code, API, and tests

  • Perform Code Review on auth, middleware, APIs, validation, business logic, error handling, secrets, and dependencies.
  • Integrate negative tests on roles, tenants, IDOR/BOLA, malicious inputs, sessions, uploads, and rate limits.
  • If the app is exposed, plan a WAPT on the real environment.

Cloud, IaC, and production

  • Review Terraform, CloudFormation, CDK, security groups, IAM, storage, databases, networking, pipelines, and secrets before applying.
  • Verify least privilege, environment separation, logging, backups, rollbacks, and approvals.
  • No deploy or destroy command should be an automatic effect of a hook or task without control.

When an internal review is enough and when an independent verification is needed

An internal review may be enough if Kiro is used for specifications or refactoring that are not exposed, without real data, without IaC, without public APIs, and without high-impact automations. Instead, an independent verification is needed when specifications guide functions with real data, roles, tenants, payments, integrations, public APIs, IaC, AWS, Terraform, MCP, or hooks that execute commands, or when the team wants to adopt Kiro continuously and must define policies, review thresholds, responsibilities, and repeatable controls.

The point is not to slow down Kiro, but to separate what can be accelerated from what must be validated: requirements, threat boundaries, automations, tools, cloud, code, and actual behavior.

How ISGroup can verify a project developed with Kiro

The control changes based on what Kiro has structured, generated, or automated. If the risk is in the requirements, the threat model, or architectural choices, the Secure Architecture Review helps validate design, trust boundaries, and data flows. If the risk concerns AWS, Terraform, IAM, security groups, storage, or pipelines, the Cloud Security Assessment verifies configurations and privileges. If the goal is to govern adoption, policies, and review thresholds, the Risk Assessment helps define priorities and responsibilities.

If Kiro has touched… Main risk Recommended control
Specifications, requirements, design, trust boundaries, data flows Weak architectural assumptions Secure Architecture Review
AWS, Terraform, IaC, IAM, storage, database, security groups, pipelines Cloud misconfiguration or excessive privileges Cloud Security Assessment
Internal policies, approval thresholds, agentic workflow governance Unclassified risk or non-repeatable controls Risk Assessment
Application code, APIs, middleware, validation, secrets, dependencies Vulnerabilities or regressions in the code Code Review
Web apps or public APIs generated from specs Behaviors exploitable from the outside Web Application Penetration Testing

The choice of control depends on what has actually changed: specification, architecture, automation, cloud, code, or exposed behavior. Before go-live, it is advisable to define that perimeter and verify the actual risk to the product. Have you used Kiro to transform requirements into design, tasks, code, or infrastructure? ISGroup can help you verify if the structure produced by the AI also contains the necessary security controls: threat models, authorizations, IaC, IAM, hooks, MCP, tests, and remediation.

Evidence to prepare before the review

Before involving an external team, it is advisable to collect specs, EARS requirements, design, tasks, repositories, diffs, tests, .kiro/hooks files, steering files, configured MCP servers, IaC templates, plan diffs, accounts or environments involved, roles, processed data, and decisions already made on accepted risks. This evidence allows us to understand if security is present in the specification, design, implementation, and tests, and to distinguish a methodological problem from an application vulnerability or a cloud misconfiguration.

The final question should not be “is the spec complete?” in the abstract, but: what security requirements does it contain, what threats does it cover, what automations does it enable, what resources does it create, what data does it expose, and what tests demonstrate that the controls work even against abuse. Kiro can bring order to AI-assisted development; security serves to prevent that order from making it easier to bring a well-documented vulnerability into production. Has the project developed with Kiro been verified as an exposed product, or only as a coherent specification?

FAQ

  • Does spec-driven development make code more secure?
  • It makes the process more explicit and traceable, but it does not guarantee security. If requirements do not include auth, authorizations, threat models, data, and negative tests, the agent can orderly implement a vulnerable system.
  • Are EARS specifications enough to cover security requirements?
  • No. EARS helps write clear requirements, but you must explicitly include security, abuse cases, access control, error handling, logging, privacy, and remediation.
  • Are Agent Hooks risky?
  • They are useful, but they become risky when they execute shell commands, modify files, install dependencies, run cloud CLIs, or interact with external tools without proper approval and logging.
  • When is a Secure Architecture Review needed?
  • When Kiro has contributed to specifications, design, trust boundaries, data flows, multi-tenant setups, integrations, or architectural choices that will go into production.
  • When is a Cloud Security Assessment needed?
  • When Kiro has generated or modified Terraform, CloudFormation, CDK, IAM, security groups, storage, databases, pipelines, or AWS resources.

Protect your organisation with Web Application Penetration Testing.

Choose ISGroup for a practical, tailored engagement:

  • A focused assessment of your environment and requirements
  • Clear findings with a prioritised, actionable roadmap
  • Direct support from experienced specialists through remediation and implementation
Talk to an expert

Useful sources and references

In

, , ,