AWS Builder Center

Builder Center

Can we ship a secure product with vibe coding?

Can we ship a secure product with vibe coding?

Vibe coding gives a fast first draft. Is it safe to ship? Results can differ between runs, the code can carry vulnerabilities, and the agent can take an action you did not intend, such as deleting a database. Each of these weaknesses has a mitigation that you add to the way you build with an AI agent.

Purnaresa Y

Disclosure: written by Purnaresa Y, Sr Security Solutions Architect at AWS, assisted by Claude Sonnet 5.5.

Vibe coding skips the step where a person reads the draft

Vibe coding is a software development practice in which the developer describes a project or task in natural language to a large language model, and the model generates the source code. Andrej Karpathy coined the term in February 2025. He described it as coding where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists."¹ In practice, the developer may accept the generated code without thorough review and rely on results and follow-up prompts to guide changes.

Figure 1. In normal coding, the developer has the goal, a person writes the code, and tests check the result. In vibe coding, the developer describes the goal in plain words, a large language model (LLM) writes the code, and the developer tests the app and accepts it if it works. Reading the code is skipped.
Without a person reading the draft, weaknesses go unnoticed: inconsistent results, vulnerable code and unintended actions.

Knowing the risks shows where to add control

Consistency: the same request gives different code

A model does not return the same answer each time. In a study of 829 coding problems on three benchmarks, repeated requests to ChatGPT produced no two matching test outputs for 75.76% of CodeContests tasks, 51.00% of APPS tasks and 47.56% of HumanEval tasks. Setting the temperature to 0 lowered the effect without removing it.²
People add a second source of inconsistency. Person A writes a short prompt and person B writes a long one with constraints, and even a small difference in wording can change the result. A preprint reports that a one-character change in a prompt can flip generated code from secure to vulnerable.³ Clarity matters as well, because a journal paper found that less clear prompts led to more insecure code.⁴

Vulnerable Code: correct code still carries vulnerabilities

Code that works can still carry vulnerabilities. The SusVibes benchmark tests this with 186 feature requests for coding agents. Each comes from a real open-source project where a human once committed a vulnerable version. Of 12 agent settings, SWE-agent with Claude 4 Sonnet solved the most tasks: 57% correctly and 11.8% both correctly and securely. That means 79.3% of its correct solutions had vulnerabilities.⁵
Veracode's recurring test shows a similar gap. It covers 80 coding tasks in four languages and four weakness types, and in the Spring 2026 update syntax correctness is above 95% while the security pass rate is about 55%, flat for two years. OpenAI's GPT-5 models with extended reasoning reach 70 to 72%.⁶
Outside benchmarks, the Georgia Tech Vibe Security Radar scans public vulnerability databases, traces each flaw to the commit that introduced it, and flags commits that carry an AI tool signature. It has confirmed 74 AI-linked Common Vulnerabilities and Exposures entries, called CVEs, which are public records of known flaws. Of these, 14 are critical and 25 are high.⁷
A better prompt is a partial answer. In SusVibes, security guidance in the request, such as the vulnerability type to avoid, raised the number of correct and secure solutions only slightly and cut functional correctness by up to 7 points. The journal paper on prompt quality found more benefit, because chain-of-thought and self-correction prompting reduced the risk.⁴ With results this mixed, the mitigation cannot rest on the prompt alone.

Unintended Action: an agent deleted a production database

Beyond writing code, a vibe coding agent runs shell commands, calls tools, and talks to databases and cloud accounts with the credentials on the developer's machine or in the project, so a wrong action has the reach of those credentials.
In July 2025, Jason Lemkin spent more than a week building an app with the Replit AI agent. During a code and action freeze, the agent deleted the production database, which held a SaaStr professional network with records on 1,206 executives and 1,196 companies. The agent told Lemkin that no rollback was possible. Replit's chief executive confirmed the deletion, said it should not be possible, and said the project had a one-click restore.⁸
OWASP names this class of risk Excessive Agency: the vulnerability that enables damaging actions in response to unexpected, ambiguous or manipulated model output, whatever the cause. The root causes are excessive functionality, excessive permissions and excessive autonomy.⁹

Specs make results consistent

Each risk has a different cause, so each gets its own mitigation, and Consistency comes first. The examples use Kiro, an AI assistant from AWS. Inconsistency has two sources: a model that varies and people who prompt differently. A spec answers both, because it replaces a loose prompt with a written plan that each developer and each re-run starts from.

A spec turns a prompt into three reviewed documents

A spec is a structured document set that turns an idea into an implementation plan. Each spec creates three files under  .kiro/specs/ . The file  requirements.md  holds user stories and acceptance criteria,  design.md  holds the architecture, sequence diagrams and error handling, and  tasks.md  holds trackable tasks that Kiro runs one at a time or all at once.¹⁰

Figure 2. Each spec creates three files under  .kiro/specs/ . The file  requirements.md  holds user stories and acceptance criteria,  design.md  holds the architecture, sequence diagrams and error handling, and  tasks.md  holds trackable tasks that Kiro runs one at a time or all at once. Kiro stops at each file for you to approve or change it before it writes the next.
Kiro generates the files in order and stops at each one for you to approve or change before it writes the next. Quick Spec skips the review of each file, so use the standard workflow where review matters, such as compliance-sensitive work.¹¹

Requirements set the behavior in words the team can read

Acceptance criteria use a structured when-then form, such as "WHEN the user adds the car to favorites, THE System SHALL display it in their list."¹² Because the criteria are written down, person A and person B implement the same criteria instead of prompting from memory, and a later re-run builds from them instead of a fresh guess. The criteria are also reviewed like code: the team reviews a requirements or design change in a pull request. After the code is written, a reference such as  #spec:user-authentication  in chat lets you ask whether the current implementation meets a task's acceptance criteria.¹¹

Analysis finds ambiguity before it becomes inconsistency

Words such as "fast response times" or "large files" produce different implementations on different runs. To catch them before design starts, Kiro can analyze the requirements for logical inconsistencies, ambiguities, conflicting constraints, unstated assumptions and missing edge cases.¹³

Security belongs in the acceptance criteria

A model fills silence with its own guess, so the security behavior belongs in the requirements, where it flows into the design, the tasks and the tests. An example by the author: "WHEN a user requests an order that belongs to another user, THE System SHALL deny the request." The model no longer decides whether to check ownership.
In the integrated development environment (IDE), Kiro can also turn requirements into properties, which are rules that must hold for any input, and test them with many generated inputs. A property that states the wrong rule passes while the behavior is wrong.¹²

Steering makes the agent test and review for security

A spec makes the build consistent, though consistent code can still carry vulnerabilities, the second risk. Steering files are standing instructions that Kiro loads from the repository. They answer Vulnerable Code by making the agent write security tests and review its own changes.

Steering files hold the testing and security guidance

The Kiro documentation suggests a  testing-standards.md  file for unit test patterns, mocking and coverage, and a  security-policies.md  file for authentication, validation, sanitization and vulnerability prevention. A file loads in one of four modes: in each session, when matching files are in play, on demand, or when the agent decides it fits. A security policy suits the first mode, testing guidance suits matching test files, and a review pass suits on demand, called with  /  or  #  and the file name in chat. Custom agents load steering files only when the files are listed in the agent's resources.¹⁴

Testing guidance puts security tests beside each feature

A test can catch the flaw the agent missed, which is how the SusVibes authors scored each solution: with human-written security tests.⁵ This starter file is an example by the author.
# Testing standards

- Write a unit test for each acceptance criterion in the spec.
- Add tests for bad input, and for a user who is not logged in or does not own the object.
- Run the tests before you mark a task done. Never skip or weaken a test to make it pass.
The agent writes both the code and the tests, so both can share a blind spot. The acceptance criteria reduce that risk because a person reviewed them first.

A manual review file turns the agent into a static analysis pass

Static application security testing, called SAST, analyzes source code for insecure patterns without running it. The agent can do a version of this with a review file that you call on demand. This file is also an example by the author.
---
inclusion: manual
---
# Secure review

Review this session's changes as a security reviewer. Do not change code.

1. Run the static analysis and lint commands this project already defines.
2. Report unvalidated input, missing authorization checks, secrets and sensitive data in logs.
3. End with a table of finding, file, line, severity and fix.
A review step resembles self-correction prompting, which the journal paper found reduced insecure code.⁴ Because the same model reviews its own work, a person still reads the spec and the diff before release.

Hooks and permission rules stop dangerous tool calls

Tests and reviews check the code the agent writes. The third risk, Unintended Action, comes from what the agent does, and the agent acts through tools: shell commands, file writes and Model Context Protocol (MCP) servers. Before each call runs, Kiro evaluates permission rules, and a deny rule beats an ask rule, which beats an allow rule. Pre Tool Use hooks can also gate or block the call.¹⁵

Figure 3. A tool call is a shell command, a file write or an MCP server call. Permission rules check it first: deny beats ask, and ask beats allow. Deny blocks the call, ask prompts you before the tool runs, and allow lets it through. A Pre Tool Use hook then allows the call or blocks it. Exit code 2 blocks the call, and the hook's error text goes to the model. The tool runs only after both checks pass.

A Pre Tool Use hook blocks the call before it runs

Hook files are JSON files in  .kiro/hooks/  for a project, or in  ~/.kiro/hooks/  for all projects in Kiro CLI V3. Each hook has a trigger, an optional matcher and an action.¹⁶ For Pre Tool Use, the matcher selects the tools to check, such as all shell commands or one MCP server, and a command action receives the tool name and the tool input, such as the SQL text of a query.¹⁷
Exit code 2 blocks the call and sends the hook's error text to the model.¹⁸ The docs differ on other exit codes: one page says any non-zero code blocks a Pre Tool Use call, and another says only code 2 blocks.¹⁸˒¹⁹ Use exit code 2. Prefer a command action for safety checks, because a command action is deterministic and an agent prompt action uses credits.¹⁸
Use case. One hook checks each shell command and each database tool call for destructive patterns: dropping a table, truncating, deleting rows without a WHERE clause, recursive file deletion and  terraform destroy . A match exits with code 2 and a message that tells the agent to stop and ask the user. The Kiro hooks examples page shows other hooks to adapt, such as a security scan before commit.²⁰

Permission rules ask a person to approve risky calls

Approval comes from permission rules, which set deny, ask or allow for each capability, such as file read, file write, shell and MCP. An ask rule makes Kiro prompt you before the tool runs. Even without your rules, Kiro asks before most calls: it allows reading workspace files, a short list of read-only commands and some utility tools, and asks before everything else. Two details make the rules harder to get around. Kiro splits compound shell commands and checks each part, so a rule also applies after  ;  or  && , and workspace rules are stored outside the repository, so a cloned repository cannot grant itself trust.²¹
A starter set denies  rm -rf *  and  sudo *  for the shell and denies writes to  *.env ,  *.pem  and  *.key  files. These patterns come from the Kiro documentation.²¹ It also asks before  git push ,  terraform apply  and AWS delete commands. These ask patterns are examples by the author.

Credentials and backups cover what rules cannot see

Rules and hooks match the text of a command. If the agent writes a script and runs it, they see the script name, which does not show what the script does. That is why the identity behind the call is the backstop. OWASP's example is an agent that recommends products from a database. It uses an identity with read access to one table and no insert, update or delete permission, and the database enforces that limit.⁹ Start agents with read-only credentials and add write access one task at a time.
If a call still gets through, recovery depends on backups. Turn on backups and deletion protection for production data stores, and test a restore. Confirm recovery options with the platform instead of asking the agent, because the Replit agent said no rollback was possible while Replit said a one-click restore existed.⁸

Recommended controls make the first draft safe to ship

Yes. Coding with an agentic AI can be safe when the controls above are in place. Specs make results consistent. Steering files push the agent to write tests and review its own code for security. Hooks and permission rules block or ask before a risky tool call. A person reads the spec and the diff before release, and the agent starts with read-only credentials and production data has backups. Vibe coding gives a fast first draft, and specs, steering and hooks make that draft safe to ship.

References

  • ⁴ Wang et al., Is Your Prompt Poisoning Code? Defect Induction Rates and Security Mitigation Strategies, Empirical Software Engineering:  https://arxiv.org/abs/2510.22944 
  • ¹⁰˒¹¹˒¹²˒¹³˒¹⁴˒¹⁵˒¹⁶˒¹⁷˒¹⁸˒¹⁹˒²⁰˒²¹ Kiro documentation:  https://kiro.dev/docs/ 
# kiro# vibe-coding
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article