How enterprises can enable AI-built apps without creating shadow IT

Someone on your ops team described a dashboard to an AI coding tool on Thursday. By Friday it worked. It reads from a production database using a connection string pasted directly into the source, it runs on a personal cloud account paid for with a personal card, and it sits behind a public URL with no authentication. Nobody in IT knows it exists.

Shadow IT in the context of AI-built apps is any application generated with an AI coding tool and then deployed to infrastructure your organization does not govern. That dashboard is dangerous because nobody can see it, so nobody can review, revoke, or contain it. Restricting the tools rarely helps, because most of the people building this way are not trying to break a rule. They are trying to finish something, and the sanctioned path is slower than the unsanctioned one.

This article covers where the security risk sits with AI-built apps, why restricting AI coding tools tends to backfire, what makes a sanctioned deployment path win, and the infrastructure controls that hold it together on Northflank.

Shadow IT from AI-built apps looks like a working application running on infrastructure that appears in no inventory you maintain. Not a rogue server under a desk. A live URL, connected to production data, often built by someone with limited security training and no malicious intent.

The generated code may carry flaws of its own, and code review and scanning reduce those. But an app nobody knows about rarely reaches code review, which is why invisibility rather than code quality is what defines shadow IT.

That invisibility starts with a gap in provisioning. Someone generates an app, needs compute and a database and a URL, finds no obvious internal place to get them, and improvises. The results are consistent:

• Credentials get hardcoded into the source, because many builders have never encountered a secrets manager
• The database connection uses whatever string was to hand, which is often an admin account
• The URL ends up public, because nothing in the workflow required authentication in front of it
• Anything the app executes at runtime, whether an agentic feature or a code interpreter, runs with the application's own privileges

Now multiply that across departments. IBM's research is worth reading with its scope in mind: it studies 600 organizations that experienced a breach, so the figures describe breached organizations rather than all enterprises. Within that population, breaches involving shadow AI added as much as USD 670,000 to the average breach cost and exposed customer PII more often than breaches overall.

Restricting AI coding tools backfires at scale because a restriction changes what people are allowed to do without changing what they need to get done. A ban is enforceable across twenty people. Across two thousand, spread over departments with their own budgets and their own deadlines, it becomes a policy nobody has the means to check. A ban does suppress some activity. What it costs you is visibility into the activity that continues.

The second cost is one platform teams feel later. As IT becomes an obstacle rather than a service, it gets consulted less, and you lose sight of what people are building. Lose that and you are governing an estate you can no longer describe.

None of this is an argument for permissiveness. Some environments warrant hard restriction, and if yours handles classified data you already know it does. It is an argument that in most enterprises, a policy without a supported alternative behaves more like a statement of preference than a control. The alternative has to exist first, and it has to be somewhere people would choose to go.

A sanctioned deployment path is the route your organization officially provides for getting an application from code to a running URL: a place to deploy, with identity, secrets, isolation, and audit already attached. It wins when it is easier to use than the shortcut. Four conditions determine that:

1. Speed: If provisioning a governed environment takes two weeks and a personal deployment takes ninety seconds, the policy is under pressure from the first Monday morning. The sanctioned route does not need to be faster than the shortcut. It needs to be fast enough that the shortcut stops being worth the trouble.
2. Self-service: Speed is not enough if a human sits in the path. Controls that require a platform engineer to approve, provision, or configure become bottlenecks, and the bottleneck becomes the reason to go around. AI coding tools raise deployment volume, which makes every remaining manual step more expensive.
3. Security by default: Most non-engineer builders will not configure secrets injection, because they have not encountered the concept. When the platform applies the control, coverage is consistent. When the platform expects the builder to apply it, coverage depends on who is building.
4. Visibility: Builders get autonomy inside a project boundary. Security gets a named identity on every deployment and a record of every change. Neither has to ask the other for permission to do their job.

Platform engineering calls this a paved road. What differs here is the population using it: colleagues who may never open a terminal, and who need the road to be the obvious route rather than the documented one.

Most enterprise AI governance covers which models are approved and how prompts are logged. The controls that make an AI-built app safe sit lower, below the application and above the cloud, which is a layer those frameworks rarely reach. Seven of them matter:

• Identity: Every deployment tied to a named person through RBAC and SSO backed by your identity provider, so that removing someone from your directory can remove their access to what they built.
• Isolation: Per-team boundaries, so that a misconfiguration in one department is unlikely to reach data owned by another.
• Credentials: Secrets stored centrally and injected at build and runtime rather than typed into source, with scoped database users instead of shared admin accounts.
• Execution: Sandbox isolation for anything that runs AI-generated or user-submitted code at runtime. Standard containers share the host kernel, which is a weaker boundary than many teams assume when the code is untrusted.
• Validation: An isolated, production-like environment for every change before it reaches production. This is also where code scanning and review earn their keep.
• Evidence: Audit logs recording who deployed what, when, and what changed, tied to a named identity rather than a service account.
• Location: For regulated data, workloads that run inside your own cloud boundary rather than a vendor's.

For the fuller governance model behind these, see how enterprises should govern AI-built applications at scale.

The shadow path is whatever the builder improvised: their own account, their own credentials, no one watching. The paved road is the sanctioned deployment path from earlier, with identity, secrets, isolation, and audit already attached. The columns below describe the same AI-generated application on each. What differs is not the code. It is everything around it.

Northflank is a full-stack cloud platform that gives AI-built apps somewhere to land, with the controls configured at the platform layer rather than by the person deploying. A builder connects a repository and gets a running URL. The identity, secrets, isolation, and audit came with it.

• Projects as the isolation unit: Each team gets its own project containing services, databases, volumes, and secret groups.
• RBAC at organization, team, and project level: Roles can be restricted to specific projects, or excluded from them. Permissions that grant access to secrets are flagged as sensitive before you assign them.
• SSO and directory sync: SAML and OpenID Connect against your existing identity provider. Roles can be mapped to directory groups, so removing someone from a group removes the role. Organization admins can enforce MFA, cap session length, and clear every member session at once.
• Secret groups with two access tiers: Secrets are stored centrally and injected as runtime variables or build arguments. Groups are typed as either secret values or configuration values, with RBAC configured separately for each, so a builder can hold configuration keys without seeing a credential.
• Sandboxes for apps that execute untrusted code: MicroVM-backed workloads using Kata Containers or gVisor, designed to prevent container escape. The isolation costs little in startup latency: third-party benchmarks published by ComputeSDK (July 2026) measured Northflank's median time-to-interactive at 97ms sequentially and 167ms under concurrent burst load, at a 100% success rate.
• Preview environments per pull request: Full-stack, including databases, microservices, and background jobs. Idle environments shut down automatically, and changes carry an auditable history you can roll back.
• Audit logs at four scopes: Organization, team, project, and resource. Each event records its type, the user, the origin, a timestamp, and its parent and child events. Configuration changes show a diff of the previous and updated state.
• BYOC when the data cannot leave: Run the platform inside your own AWS, GCP, Azure, Oracle, Civo, CoreWeave, on-premises, or bare-metal infrastructure, with sandboxed runtimes, network policies, and mTLS. SOC 2 Type 2 certified.

Shadow IT in the context of AI-built apps is any application generated with an AI coding tool and deployed to infrastructure the organization does not govern: personal cloud accounts, unmanaged databases, public URLs without access control. AI-generated code can carry its own vulnerabilities, which review and scanning address. What defines shadow IT is that the deployed application handles real data outside the identity, secrets, isolation, and audit boundaries the security team controls, so those controls never reach it.

Shadow AI is a subset of shadow IT. Shadow IT covers any technology deployed without IT's knowledge. Shadow AI usually refers to unsanctioned AI tools, most often employees pasting company data into chatbots. The less-discussed and often more consequential version is the application an AI tool produced, running somewhere nobody governs. IBM's 2025 research found one in five of the breached organizations it studied reported an incident linked to shadow AI.

Banning AI coding tools rarely reduces the underlying activity by much, because it does not change the deadline that motivated it. What a ban reduces more reliably is visibility: some of the work moves onto personal accounts with no telemetry, no audit trail, and no way to revoke access at offboarding. The more durable control is a sanctioned deployment path that is easier to use than the alternative, with security controls applied by the platform rather than by the builder.

Separate the roles at the infrastructure layer rather than by policy. On Northflank, RBAC operates at organization, team, and project level, and secret groups are typed so that configuration values and secret values carry different permissions. A builder can deploy to their own project and read configuration keys without holding a production credential.

On a personal cloud account, the app usually keeps running and nobody notices. On a governed platform with SSO and directory sync configured, removing the user from their directory group removes the associated role, and their access to the associated environments goes with it. The application itself remains, owned by the team, visible in the audit log.

It depends on whether the application executes code at runtime. A dashboard that queries a database is ordinary application code, and a standard container is a reasonable fit. An application with an agentic feature, a code interpreter, or any path that runs user-submitted input as code is executing code nobody reviewed. Containers share the host kernel. MicroVM isolation gives each workload its own kernel boundary, which is the stronger choice when the code is untrusted.

• How enterprises should govern AI-built applications at scale: The infrastructure-level governance controls for AI-built software, covering RBAC, SSO, sandbox isolation, audit trails, and BYOC.
• How to build an internal vibe coding platform: The six components of a governed internal platform, and how to assemble them on Northflank's API.
• How non-technical employees can build and ship internal apps with AI, securely: The builder-side view of what secure deployment looks like without infrastructure knowledge.
• What is an AI internal developer platform (IDP)?: Why AI coding tools change what enterprises need from their internal developer platform.
• From prototype to production: the enterprise lifecycle of an AI-built app: Validation, staging, and governance at each stage of an AI-built app's life.