How should IT handle vibe-coded apps employees already use?
Identify the business task, running URLs, data access and accountable owner before deciding what the app may keep doing. Address any current exposure, then move useful tools through a sanctioned deployment and review path. Record the source, release, audience and support route so another person can maintain or stop the app when circumstances change.
Keep discovery separate from a blanket verdict about the builder. An AI-built app may be a fictional-data experiment, a read-only internal dashboard or a tool that changes company records. Those cases need different decisions. Find what the application actually does and who depends on it before selecting the appropriate review and operating process.
Recognize the transition from experiment to dependency
A prototype often begins with a narrow request that existing systems do not meet. A builder creates a screen, sends a link and later adds real data to make the result more useful. The important transition is not the first generated line of code. It is the moment an unrecorded app starts handling company information or influencing work that another team expects to continue.
Ask whether the app has an owner beyond its creator, whether hosting is held by an appropriate account and whether users know how to report a problem. An app can be approved for a business purpose while still having an undocumented provider URL or excessive data grant. Treat those as concrete gaps to resolve rather than assuming that informal distribution is the entire risk.
Read exposure research in its actual scope
A 2026 research preprint, Understanding the (In)Security of Vibe-Coded Applications, reports an audit of 200 publicly deployed apps drawn from the authors' collected corpus. Its September revision reports that 91 percent of that audited sample contained at least one vulnerability. The authors describe access-control, injection and authentication failures among the findings. This is a result for that study's sample, not a measured rate for your organization or SpringRoll deployments.
Veracode's 2025 GenAI Code Security Report uses a different method: 80 code-completion tasks across four languages and selected vulnerability classes, tested with more than 100 models. It reports a known flaw in 45 percent of generation tasks. A code-task benchmark is not an audit of all deployed apps. Read the methodology before using either result to justify a local decision.
Reviewed 31 October 2026. These are third-party research findings, not SpringRoll customer results or a product benchmark. Use them to identify questions worth testing, then collect evidence for the actual application, identities and data path you are responsible for.
Start the conversation with the task
Ask the builder and a normal user to show one complete task with fictional or otherwise appropriate test data. What decision does the app help make? What happens after the user saves or approves something? Which existing process would stop or become harder if the app disappeared? This reveals why the tool exists and which parts deserve attention first.
Record what is still simulated. A browser-only queue may look like a multi-user review tool while storing every change locally. A dashboard may display a copied fixture rather than a fresh company dataset. Those limitations are useful facts for the handoff, not reasons to invent production capabilities that the demonstration has not established.
Inventory the running routes and backing services
List the current app URL, provider hostname, custom domains and relevant old deployments. Record source location, framework, build configuration and external services. Include where shared records or uploads are stored and which account administers each service. A folder of source code is not a complete inventory of the running system.
Look for the paths users actually keep, including an old chat link that predates the latest deployment. A new protected front door does not remove a former provider URL. Assign a person to review obsolete endpoints and confirm their final state. Keep this inventory alongside the app owner and intended purpose so it can be updated when the next release changes the architecture.
Address an exposed boundary before expanding use
If a review finds an exposed credential, unrestricted data endpoint or unprotected page containing company records, involve the responsible security and data owners. Preserve the facts needed for their response and restrict further use through the appropriate controls. Rotate exposed credentials where required; removing a visible value from the newest source does not revoke an older copy.
Use the linked origin-access review for each affected deployment URL, including a fresh session and a denied identity. Keep the response tied to the exposure you found and record the result. A repaired route needs verification of its actual requests, rather than an assumption based on a changed sign-in screen.
Name the owner who will maintain the outcome
Identify an accountable App Owner and a support contact who remains available after the builder's initial project. Have that owner confirm the business purpose, audience and acceptable failure behaviour. Preserve the source and the instructions needed to reproduce a release. A personal hosting account or private terminal session should not be the team's only way to diagnose a problem.
Plan the handoff when the creator changes role or leaves. Use the governed transfer process, review application identities and data grants, and ask the incoming owner to verify a task. Record unresolved maintenance work and the person who can decide to suspend or retire the app. Ownership is meaningful when someone can act on it.
Offer a sanctioned path that preserves useful work
Keep the application project where the maintainers can improve it, then bring its deployment and team handoff into a reviewed operating process. Start with runtime fit and a reproducible production build. Name the owner, review the workflow and follow the actual deployment result. A submitted job is not a working app until the returned deployment has been verified.
SpringRoll records the application and immutable release, manages eligible deployments and gives colleagues an App Portal launch path. The team still needs to maintain the code, protect the origin and verify application permissions. That division of responsibility gives builders a route to continue useful work while making the operating decisions visible to IT.
Review data access independently of the employee
List the company systems the tool can reach and the operations it performs. Distinguish an employee's own account access from a grant to the application environment. A tool that needs a small case summary should not receive the entire source account's reach merely because the builder can see it. Review the smallest field or endpoint scope that supports the task.
For SpringRoll data products, inspect fields, row restrictions, limits and expiry. Native endpoint grants are a separate route whose responses follow the source account's permissions. Keep credentials server-side and test revoked or denied access. Revisit the decision when the app adds exports, write operations or a wider audience, rather than carrying the prototype's access forward without review.
Separate a direct path from a staged review
Not every app needs the same release workflow. Choose the path from its actual task and required decisions. SpringRoll defaults to Direct to Production while retaining required checks. Configure Staged when a release needs Development, UAT and Production review, and keep the reviewer and tested immutable release identifiable.
Do not turn the absence of a separate release approval into permission for unrelated changes. New data access, broader scope and other governed actions have their own decision rules. An agent can prepare a request and show the next action; it cannot record a human approval. Give the builder a clear route to the person who can resolve a blocked request.
Retire obsolete routes and grants deliberately
An inventory review should end with decisions about tools that are no longer needed. Confirm who still uses an app before retiring it, then follow the appropriate suspension or retirement process. Review provider endpoints, application sessions, stored artifacts and data grants separately. Removing an entry from a list does not prove that an older URL or copied dataset has disappeared.
Keep the accountable person and verification result in the record. Where the app is replaced, give users the intended destination and a support route. Where a grant is revoked, check the affected application behaviour. This completes the operating handoff and prevents a forgotten prototype from remaining an unowned dependency after the team has moved on.
Turn discovery into a maintainable policy
Use the first set of app reviews to improve the instructions given to the next builder. Explain what must be registered, how ownership is assigned, which data requests need review and how colleagues receive a verified launch link. Include a working example and a contact for exceptions. Keep the process understandable to the people doing the work.
Review open ownership, access and runtime questions regularly rather than treating a one-time inventory as completion. The governance framework supplies a reusable policy; the discovery work supplies evidence about the apps already present. Keep those roles distinct and connect them through named decisions and current records.
Frequently asked questions
Does research prove that my app is vulnerable?
No. Research establishes findings under its own sample and method. Use it to choose concrete checks, then assess the actual application and preserve the observed results.
Should IT discard every employee-built prototype?
No. Identify the useful task, current exposure and operating requirements. Decide whether to secure, support, replace or retire it with the responsible owner.
Is moving the app to an approved host enough?
No. Verify application permissions, direct-origin protection, data grants, ownership and the user task alongside the hosting decision.