Vibe-coded apps need security beyond the application

AI-assisted development is changing a basic condition of enterprise security: software can now exist inside a business without passing through the processes that used to tell IT it was there. Finance analysts, sales operations managers, and support agents can use prompts to create working tools alongside their normal jobs. Some tools can be built “in an afternoon,” so creating an application no longer necessarily produces the organizational activity associated with a conventional software project. The security response is to move common controls toward shared platform and data layers while maintaining visibility into where employees build.

AI-assisted development is breaking the trail that used to make software visible

Traditional software procurement created visibility almost incidentally because buying an application usually generated a vendor contract, triggered a security review, or created a spending item that somebody had to approve. Those events gave IT and security teams opportunities to discover an application, evaluate it, assign responsibility, and decide what access it should receive. Procurement therefore worked as an application-discovery process as well as a way to acquire software.

AI-assisted development can remove much of that trail because an employee may create software internally and independently. Vibe coding, where a user directs an AI system through prompts to produce an application, reduces the conventional software-development work required of that user. The resulting tool can still handle business processes or company information even though its creator works in another role.

Once creation moves outside procurement, IT can lose a discovery point before questions about the quality of AI-generated code even arise. Acquiring software used to leave evidence elsewhere in the organization, while an employee can now generate a useful application directly. The immediate governance problem is that the organization may have working software whose existence, owner, access, and data use are unknown to the people responsible for securing it.

The visibility gap is already paired with a governance gap

That discovery problem appears in a survey of 307 CIOs, CTOs, and CISOs. Only 5% said they were “very confident” that they had full visibility into all internal tools across their organization. Visibility comes before conventional application governance because a security team must discover an application before it can review, monitor, or assign accountability for it.

The governance findings show a related condition. Just 4% of leaders said they had governance covering AI-generated code regardless of how it had been written, while another 4% said the issue had yet to come up. The visibility measure tracks knowledge of internal tools, while the governance measure tracks how far governance reaches across AI-generated code. The two matter together because limited discovery leaves fewer opportunities to apply rules that already have limited coverage.

The builder side helps explain how the visibility gap develops. Sixty percent of builders reportedly say they built something outside IT oversight “in the past year.” That behavior creates the condition measured from the executive side: people across a business can create software while bypassing the processes through which IT traditionally learns about it. More distributed creation can therefore expand the population that security teams are expected to govern.

That larger population also separates who creates a risk from who eventually has to answer for it. Builders and users can solve immediate business problems through self-service development, while CIOs, CTOs, CISOs, and IT teams retain responsibility for incidents involving company systems and information. Governance designed around a known population of applications and developers becomes less reliable once software creation spreads across the business.

A shadow app can go from enterprise data to public exposure before IT knows it exists

An illustrative scenario makes that discovery problem concrete. A sales manager exports customer data from Salesforce into a CSV file, registers for a vibe-coding platform through a personal account, and creates a visualization application. The manager then publishes the application at a public URL. Salesforce is the known system in this sequence; the security change occurs when the employee moves enterprise data into an independently created tool.

Once the application is public, Google indexes it “within days,” before IT discovers the tool exists. The timing is illustrative, and Google is the mechanism by which the public page becomes discoverable. The organizational sequence creates the exposure: enterprise information leaves a known system, enters a tool created through a personal service, and becomes publicly reachable without passing through the company’s usual software and security processes.

That sequence turns incomplete inventory into a security concern because an unknown application can create possible data-exposure, compliance, or outage risk. The people responsible for those areas may have had no opportunity to assess how the application stores information, who can reach it, or what it depends on. A single self-service workflow can consequently bypass procurement, IT oversight, and security review.

App-by-app security stops scaling when every employee can become a builder

The Salesforce scenario exposes a broader scaling problem with securing each application individually. That model assumes every builder knows which controls to configure and configures them correctly each time, which is difficult even when the builder develops software as a full-time job. The assumption becomes harder to sustain when employees throughout the company create applications to complete work in finance, sales operations, support, or another primary role.

An unnamed enterprise CISO described the change this way: “Tools get built in hours, sometimes minutes, and they don’t look like ‘systems’ to the people building them.” The quoted timing is an observation rather than a measured development benchmark, but it also describes how builders may classify what they make. An employee who sees a small tool as a quick way to solve a task may never classify it as a system needing an owner, security policy, review process, and ongoing accountability.

That classification matters when controls live inside each application because AI can increase the organization’s dependency on individual judgment. Under an app-level model, an AI that writes an application may also produce its security rules, so enforcement depends on what was generated and how the builder prompted, reviewed, and configured it. Every additional builder then creates another point where the organization needs the right security decisions to be made.

The scaling problem shifts the governance question from how to train every builder into where the enterprise can enforce policy consistently. Creation can remain distributed across the business while the teams accountable for access, data protection, compliance, and incidents retain centralized security responsibility. A governed environment can then reduce the security decisions each individual builder must reproduce.

Move the security checkpoint to the platform and data layer

That governed environment changes where security decisions are enforced by putting policy around the resources and enterprise data that applications use. When application-to-data interactions pass through shared enforcement points, common controls can apply before an application receives or changes information. The application remains part of the security model, but its configuration no longer has to carry every control by itself.

Central configuration lets those enforcement points cover a larger population of builders. Security teams can establish identity, authorization, data-access, and logging policies at shared layers, and applications operating there inherit the resulting restrictions. A hand-written application, an AI-generated application, and a fully vibe-coded application can then encounter the same controls when each requests the same governed resource.

Single sign-on, or SSO, provides one part of that shared identity boundary by connecting application access to the organization’s authentication system. SCIM, the System for Cross-domain Identity Management standard, supports centralized provisioning and deprovisioning of user identities. Together, those mechanisms let access follow centrally managed identity state when employees change roles or leave, reducing the identity state embedded independently in employee-created applications.

That central identity can feed group-based role-based access control, or RBAC, which assigns permissions according to organizational groups and roles. A company can define those groups and roles centrally and apply their permissions across applications using the governed environment. For a business with many occasional builders, authorization can then depend on whether a user belongs to an approved group, while security specialists maintain the company’s access model.

Data controls can narrow those authorization decisions further. Row-level controls determine which records a user can access, while column-level controls determine which fields are available. Resource-layer controls can govern access to shared resources, and data-layer controls can enforce policy close to the information itself. An application can consequently inherit restrictions on sensitive records or fields without requiring its creator to design every restriction from scratch.

Those data restrictions need a corresponding record of how governed information is used, which query-level audit logging can provide. Logging at the query level gives the organization a common place to observe requests across multiple tools, reducing its dependency on each application’s logging choices. As application counts rise, that shared record helps accountability survive differences in who built each tool and how sophisticated its internal implementation is.

Together, these controls explain operationally what “security as a property of the platform” means. The organization first needs enough visibility and accountability to bring applications and enterprise-data access onto a governed path. It can then apply common identity, authorization, data restrictions, and auditing at interactions shared across applications, shifting more security decisions toward platform and data enforcement points.

That shift matters more as software creation spreads because each new builder otherwise adds another independent set of security decisions. Requiring finance analysts, sales operations managers, support agents, and professional developers to reproduce those decisions inside every application creates a growing coordination problem. Inherited controls instead let the specialists responsible for enterprise security establish policy at shared enforcement points and apply it repeatedly inside the governed environment.

Retool provides one commercial implementation of this approach and describes its offering as a “secure vibe-coding solution.” In Retool’s model, access controls reside at the resource and data level, where applications can inherit them, while query-level audit logging operates across applications and row- and column-level controls govern which data users can access. Retool also says SSO, SCIM, and group-based RBAC apply consistently across hand-built, AI-generated, and fully vibe-coded applications.

Retool’s implementation matters here because the controls sit at shared points across different creation methods. Identity and data policy can therefore apply across applications instead of being reconstructed separately for each generated tool. Retool has a commercial stake in enterprises adopting that design, so these implementation claims describe how the company positions and provides its own platform; the broader architectural mechanism is centralized enforcement when applications access enterprise resources through common control points.

Central controls still need visibility and a governed path

Shared enforcement points also define the boundary of this model, which the sales-manager scenario exposes clearly. If an employee exports a CSV, opens a personal account on an outside service, and independently publishes an application to a public URL, the activity remains outside the corporate platform’s enforcement path. Central controls scale within the environment through which the organization can enforce them.

That boundary means the visibility problem remains after an enterprise adopts stronger platform and data-layer controls. Leaders need to know where employees are building and establish a governed path that people actually use; within that path, controls can apply whether the builder is an engineer or an employee creating a tool alongside another job. Platform adoption, visibility, and accountability determine how much activity reaches the shared enforcement points and can be governed there.

Key highlights

• Restore visibility into employee-built software: AI-assisted development lets employees create working applications without procurement, security review, or other processes that traditionally alerted IT. Security teams need discovery and accountability mechanisms that cover software created across the business.
• Close the governance gap around AI-generated code: Only 5% of surveyed technology leaders were very confident they could see all internal tools, while 4% reported governance covering AI-generated code regardless of how it was written. Enterprises need governance that follows software across creation methods.
• Keep enterprise data on governed paths: Employees can move company data into independently created apps and expose it publicly before IT discovers them. Organizations need controls that identify where sensitive data moves and which applications can access it.
• Scale security beyond individual application configuration: Vibe coding expands software creation to employees who may build tools in hours and never consider them enterprise systems. Security organizations can reduce dependence on each builder’s judgment by centralizing common security decisions.
• Enforce controls at shared platform and data layers: SSO, SCIM, RBAC, row- and column-level controls, and query-level audit logging can apply consistent policies across hand-built and AI-generated applications. Platform and security teams should place these controls at shared enforcement points applications use to access enterprise resources.
• Extend the governed path to where employees build: Centralized controls only protect activity that passes through the environment where they are enforced. IT and security teams need visibility into development outside approved platforms and a governed path employees will use.