Vibe Coding Security: Risks of AI Built Apps and How Dual7 Handles Them

Vibe coding can turn a prompt into a working app quickly. That speed helps a team test an idea. A working screen still does not prove that the app is safe for customer data or production traffic.

Vibe coding means building software by describing what you want to an AI coding tool and accepting much of the code it generates. The team still owns every security decision in that code. It also owns the dependencies and the systems used to release the app.

Before release, a team must check access at the server and database. The team must review how the server handles user input and stores secrets. It also needs a safe process for database changes and a record that links each change to an approved requirement.

As described in Dual7's public product facts, Dual7 gives teams two modes in one project. Vibe Mode is for fast building and iteration. Governed Mode adds a staged review for the features selected for release. Teams can move the same feature and codebase between the modes without a rebuild.

This process reduces the risk of shipping unreviewed AI generated code. It does not remove the team's duty to test and secure the app. Dual7's own terms say that AI output may contain errors and that Governed Mode does not guarantee software without defects.

The main security risks in vibe coded apps

The main vibe coding security risks come from shipping code before checking the parts that a prototype does not show. The latest OWASP Top Ten covers common web application risks. The list includes broken access control. It also covers injection and security misconfiguration. AI generated code can contain the same vibe coding security vulnerabilities as code written by a person.

Risk	What can go wrong	What to verify before release	How Dual7 addresses it
Weak access control	A user can call an API directly and read or change data that the interface hides.	Test every protected server route with a user who has limited access.	Governed Mode checks authorization. Dual7 also supports role based access control.
Missing tenant boundaries	One customer can read another customer's records.	Test requests across two tenant accounts and inspect the database rules.	Dual7 uses separate Postgres schemas for tenants, row level security, and role based access control.
Unsafe input handling	An attacker can send input that changes a query, exposes data, or breaks the service.	Check all public server inputs and reject values that do not match the expected form.	The Build stage checks validation and exposure before a certified change can ship.
Secrets in code or logs	An API key or database password can enter the repository, browser code, or logs.	Scan the code and commit history. Confirm that the app receives secrets only when it runs.	Dual7 says it stores and adds credentials without hard coding them in the app or logs.
Unverified packages	An AI tool can add a package with a known flaw or name a package that does not exist. An attacker may publish code under the invented name.	Confirm that every package exists and comes from the expected publisher. Scan the dependency tree and lockfile for known flaws.	Customers can export the full repository for review. The customer remains responsible for reviewing and patching dependencies.
Weak authentication and sessions	Generated login code may leave sessions open too long or handle password resets badly.	Test login, logout, password reset, session expiry, and any required multi factor authentication.	Governed Mode checks authorization. The customer remains responsible for its identity setup and authentication tests.
Unsafe API exposure	Broad CORS rules can let an untrusted site call the API. Missing rate limits can allow abuse.	Limit CORS to expected origins. Add rate limits to public and sensitive routes, then test abusive requests.	The Build stage checks validation and exposure. The customer remains responsible for runtime and cloud controls.
Unreviewed database changes	A generated migration can remove data, weaken access rules, or fail during release.	Review the data model and every migration. Test rollback and recovery before release.	The Schema stage creates the data model, and a person must approve migrations before the next stage opens.
No change record	The team cannot explain why code changed or who approved it.	Pick a released change and trace it to a requirement, review, and approval.	Dual7 records changes and approvals and links code back to requirements.
Vendor controlled runtime	The team cannot inspect or move every part of the system. This can slow a security review or an urgent fix.	Confirm that the team can export the full repository and run it without the builder.	Dual7 lets customers export the React, Node, and Postgres repository and run it on their own infrastructure.

This table combines the security controls we build into Dual7 with the checks your team should complete before release. Governed Mode provides tenant isolation, authorization and validation checks, approval gates, audit logs, traceability, secret handling, and encryption. You can export the full codebase and run it on your own infrastructure. Your team remains responsible for reviewing dependencies, testing authentication and sessions, configuring CORS and rate limits, testing recovery, and assessing risks specific to your app and data.

Separate app risks from coding agent risks

The generated app and the AI coding agent create different risks. The app may contain weak access checks, unsafe queries, or flawed packages. The coding agent may have access to source files, credentials, a terminal, or deployment tools.

Give the coding agent only the access it needs for the current task. Review changes before the agent can merge code or release it. Do not place production credentials in prompts, chat history, or files the agent can read.

An app that includes an AI assistant needs another review. An attacker may use prompt injection to make the assistant ignore its rules or misuse a connected tool. The team should limit tool permissions and check model output before another system acts on it. The OWASP Top 10 for Large Language Model Applications lists risks that apply to these features.

Why a working AI built app can fail a security review

A demo proves that the expected path works. A security review also tests what should fail.

For example, the interface may hide an admin button from a standard user. An attacker does not need the button. The attacker can send a request to the same server route. If the server does not check the user's role, the hidden button provides no protection.

An app may also add a customer ID to each database query. One missing filter can expose another customer's data. A reviewer needs to inspect and test the database rules. The reviewer cannot assume that every generated query includes the right filter.

A reviewer may also need to know which requirement led to a change. The reviewer may ask who approved a database change and which version reached production. A chat transcript and a working preview do not answer those questions.

The NIST Secure Software Development Framework recommends adding security practices to each software development process. Dual7's guide to AI generated code in production covers a broader release checklist. For a security review, the team needs evidence from its review of server access and tenant data. It also needs proof of its input checks. The team should scan the source code and its dependencies. It should also test the running app. The change record must cover secret handling and approval before release.

How Dual7 moves a vibe coded feature toward production

Dual7 keeps Vibe Mode and Governed Mode in the same project. Teams can keep changing early features in Vibe Mode while they certify stable features in Governed Mode. Dual7 says that moving a feature between modes does not require a second codebase or a rebuild.

Governed Mode has seven stages:

1. Requirements turns the request into a written specification for approval.
2. Plan sets the technical approach.
3. UX defines the user flow and interface.
4. Schema defines the tenant isolated data model.
5. Stories breaks the approved work into build tasks.
6. Build generates and checks the code, including security checks.
7. Publish sends the approved code through the customer's Git repository to the customer's cloud.

Each stage has an approval point. A team member must approve the work before the next stage opens. Only certified features reach production. The full process is described on How Dual7 Works.

Dual7 places several checks before release. The team reviews the data model before the build is complete. The Build stage checks authorization and validation. It also checks exposure. A person then approves the result. Dual7 records the requirement and each approval, so the team can trace why the code exists and who allowed it to ship.

The security controls Dual7 publishes

Dual7 lists the following controls for Governed Mode:

Tenant isolation uses separate Postgres schemas, row level security, and role based access control.
Every certified change is checked for authorization, validation, and exposure.
A person must approve scope, database changes, security, and release.
Dual7 records who changed and approved each item.
Credentials are stored and added to the app without being placed in source code or logs.
Data is encrypted over TLS and at rest.
Customers can export the full codebase and run their own security review.
Customers can run the app on their own cloud, private network, or on premises infrastructure.

The Dual7 security page and Enterprise page list the controls and their current status.

Dual7 states that SOC 2 Type II and ISO 27001 work is in progress. Buyers should not treat either one as a completed certification. A team with a firm certification requirement should confirm the current status with Dual7 before procurement.

Limits and customer responsibilities

Governed Mode adds a process and a set of checks. It cannot prove that every app is secure.

The customer must define the right roles and review the approved requirements. The customer must test the app and manage its cloud account. Its team must monitor production. The team must also patch dependencies and respond to incidents. A role based access system only works when the team gives each role the right permissions.

Dual7 is in early access. Its terms say that features may change or break. The terms place responsibility on customers to review, test, and secure generated code before production.

Dual7 provides a governed route from a fast build to a release. The team remains responsible for the release decision and the system it operates.

When Dual7 is a good fit

Dual7 is a good fit when a team has a useful AI built prototype and wants to keep the same code while adding a controlled release process.

It also fits teams that need one or more of the following:

A multi tenant app that holds customer data.
A written record of requirements and approvals.
Human approval before production.
Code that internal engineers or outside reviewers can inspect.
Deployment to infrastructure that the customer controls.

A basic Vibe Mode project may be enough for a disposable mockup. It may also suit an internal experiment with no sensitive data or a feature that changes each hour. The two modes let a team decide when each feature needs the governed process.

Dual7 may not fit a team that wants a builder to own and run every part of the production system. Exported code and customer controlled infrastructure give the customer more control. They also give the customer more operating work. A team that requires a completed SOC 2 Type II or ISO 27001 certification should wait for confirmation or choose a provider that already has the required report.

A vibe coding security checklist for AI built apps

Before an AI built feature reaches production, the owner should be able to answer yes to each question:

Does the server check every protected action, even when a user calls the API without the interface?
Can one tenant ever read or change another tenant's data?
Does the server check every public input?
Are passwords, keys, and tokens absent from the code, browser, logs, and commit history?
Has the team verified every dependency and scanned it for known flaws?
Has the team tested login, logout, password reset, and session expiry?
Are CORS rules limited to expected origins, and do public APIs have rate limits?
Has the team scanned the source code and tested the running app?
If the app uses an AI assistant, are its tool permissions limited and its output checked before another system acts on it?
Has a person reviewed every database migration and tested recovery?
Can the team trace the released code to an approved requirement?
Can the team identify who approved the production release?
Can the team export and inspect the full codebase?
Does the team have a plan for monitoring, updates, backups, and incident response?

If the answer to any question is no, the feature needs more work before release. A clean demo does not change that decision.

Review Dual7 for your production path

Dual7 is for teams that want fast AI building and a controlled path to production in one codebase. Review the published security controls and governed process. If those controls match your review needs, contact Dual7 to discuss the app and its data. The team can also confirm the deployment model and procurement requirements.

Share this article

Article Authors

Vinoth Kumar R