11 questions a security review asks about a vibe-coded app

Getting a vibe-coded app into production safely comes down to a short, boring list of checks: where the secret lives, what the app can reach, what is recorded, what happens when it fails, and who is on the hook when it does. The list is not long. It is just rarely written down, so every app gets reviewed slightly differently and the answers never accumulate.

Here is the version worth writing down.

This picks up where 7 questions every vibe-coded app must answer stops. Those seven settle approval: who decides, who owns it, who gets paged. These eleven are the review that happens once someone has said maybe.

1. Should this app be in production at all?

Gartner sorts vibe-coded applications into four zones, from safe through to off-limits, and the sorting happens before any technical check. An app that reads data a team already has access to and shows it back to them is a different object from one that touches regulated data or moves money.

Most reviews open with the code and never settle the zone, which is how an app that should never have been built arrives at a security review with a sponsor already attached. Settle the zone first. It decides how much of this list applies and how hard each answer has to be.

2. Is anything customer-facing?

Gartner’s guidance on vibe coding platforms is to limit them to prototypes and personal applications. You may reasonably decide your internal tools are a different case. An app generated by an AI assistant and pointed at your customers is not a variation on that decision, it is a separate one, with a different risk owner and usually a different answer.

Ask it second, because the answer either ends the review or narrows what the remaining nine questions have to prove.

3. Where does the credential live?

This is the question that catches the most apps. A key pasted into a config file is the default outcome, because pasting is the fastest thing to do and nothing in the builder’s path stops it. Once it is in the repository it is in the history, and rotating it means finding every app that used it.

Thousands of vibe-coded applications are exposing corporate credentials and personal data on the open web, many with no authentication in front of them. Breaches involving compromised static machine credentials average $4.81 million and take 292 days to contain, the longest remediation timeline of any attack vector.

Ask to see where the secret is, not whether it is handled. If the answer is “in the repo”, the rest of the review is academic.

4. What exactly is in the audit log?

“We have logging” is not an answer. Ask which events are captured, at what retention, and whether the record covers administrative actions, request-level execution, or both. Those are usually two separate surfaces, and a team that has one often believes it has the other.

Gartner’s expectation for AI-built software runs wider than most teams realise: prompts, agent actions, generated code, system access and deployment events. Very little on the market captures all of that today. Find out which part you are getting, and whether the retention window covers the audit you will actually face rather than the one you are imagining.

5. Has the code been scanned, and who can block on the result?

Gartner forecasts that by 2027, “at least 30% of application security exposures will result from usage of vibe coding practices.”

Nobody wrote this code. Either something scans it or someone reads it, and in practice that means static analysis and dependency scanning in the pipeline, with a threshold that stops a deploy. Ask which you have, then ask who is permitted to use it. If the builder reviews their own assistant’s output and then ships, you have a process, not a control.

6. Where was it built, and was that isolated?

The running app and the environment it was generated in are two different risk questions, and reviews almost always ask only the first. While the assistant was building, it had access to something: a laptop, a set of credentials, a network. Gartner’s recommendation is sandboxed environments by default, with container or microVM isolation.

Ask where the assistant ran and what it could reach at the time. Hosted platforms generally leave this to the vendor, so if you are using one, the question goes to the vendor rather than the builder.

7. What does it spend, and what stops it?

An app that calls a model on every request has a cost curve rather than a cost. A loop that retries, a prompt that grows with the conversation, or a scheduled job firing more often than anyone intended will each produce a bill before they produce an alert.

Three questions, in order: can anyone see what this app spends, can anyone cap it, and who finds out if it triples. Platforms in this market differ widely here, and a yes to one of the three is not a yes to the others. Ask for each, because the honest answer tells you whether spend is a control or a monthly surprise.

8. What happens when the data contains an instruction?

If the app passes text it did not author into a model, that text can carry instructions. A support ticket, a PDF, a form field, a row in a table. The model has no reliable way to tell content from command.

The question that matters is what the app does with the output. Displaying it to a person is one risk. Acting on it, with a credential attached and a system of record on the other end, is a different one. Ask which, and ask what sits between the model’s output and the write.

9. Who reviews it, and inside what turnaround?

Gartner describes an actual service level for this, with technical reviews returned inside one or two days for the safest applications and three to five days for the tier above. The number is the point. A review with no clock is a queue, and a queue is what produced the app in the first place.

Name the reviewer and name the turnaround before the next app arrives. Builders route around review when it is slower than rebuilding, and they are not wrong to.

10. What happens when it is retired?

Gartner expects 60% of vibe-coded applications to be retired by 2028, on the grounds that they fail to deliver predictable business value. That is survivable. Most of them should be switched off.

It is only survivable if you can tell which ones are still being used, who depends on them, and what breaks when they stop. Ask the retirement question at approval, while someone still knows the answer, rather than in two years when the builder has left and the app is still holding a live credential.

11. Where does the data sit?

Region, residency, and who else processes it. Thin compared to the other ten, and the one most likely to be discovered late, by someone in legal, after the app already holds something regulated.

Where Tray Helix fits

Tray Helix is the governed runtime for vibe-coded apps: one command takes an app from an AI assistant to production, and governance attaches as it ships. Every deployed app runs behind login, with no public mode and no anonymous mode. The app never holds the credential, because a project refers to one by alias that resolves at runtime, so the assistant never sees the value and rotating it needs no redeploy. Access is set per app, and every project has a named owner, an activity trail and execution logs.

That answers several of the eleven at deploy, where the cost of answering them is close to zero. It does not answer all of them, and nothing in this market does yet. Run the list against whatever you use, including us.

Sources

1. Gartner, Govern Vibe Coding for Citizen Developers With Self-Service Platforms, Nitish Tyagi, 29 June 2026, G00858202.
2. Gartner, Market Guide for Enterprise Vibe Coding Platforms, Swan, Bhat, Blosen, 28 April 2026, G00844703.
3. IBM, Cost of a Data Breach Report 2026.
4. Wired, Thousands of Vibe-Coded Apps Expose Corporate and Personal Data on the Open Web, reported via Gartner, G00858202.

GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved. Gartner does not endorse any vendor, product or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.