The demo is already in production

By the time security sees the app, the decision has been made.

Someone in marketing, finance, or support built something over a weekend on a no-code platform or with an AI coding assistant. It demos beautifully. Leadership has already seen it, already approved it, and already told the customer it is coming. The question in the room is no longer whether to build it. It is why security is slowing it down.

This is now one of the most common ways unmanaged risk enters an organization, and the security team is structurally set up to lose the argument.

Polish stopped being a signal

For most of the history of internal software, visual quality was a proxy for engineering effort. If a screen looked finished, someone had spent weeks on it, and those weeks had bought design review, backend work, and at least one argument about the data model.

That correlation is gone. An AI assistant produces a mockup with a considered layout, a real type scale, consistent spacing, empty states, and a dark mode in the time it takes to describe it. The output looks like the work of a product team because it was trained on the work of product teams.

Executives are still reading the old signal. They see a finished interface and infer a finished system. They are not wrong to; that inference held for twenty years. Nobody told them the two came apart.

So the demo does not only show that something is possible. It looks like proof the work is nearly done. That misread is what the rest of this article is about.

Why the demo always wins

A demo optimizes for one path: one user, clean data, no failures, no adversary. No-code platforms and LLM code generation have collapsed the cost of that path to roughly zero. A non-engineer can now produce a working, polished, clickable application in a day.

What none of it collapses is everything else. Authorization, tenant isolation, secret handling, audit logging, backup and restore, dependency provenance, data residency, key rotation, recoverability after an incident. The cost of all of it is unchanged.

The gap between “it works” and “it can be operated” never shrank. It became invisible to the person buying the demo.

What the beautiful thing is actually made of

The failures repeat across the builds we get pulled into:

• Authentication without authorization. The app knows who you are. It has no idea what you are allowed to see. Roles are enforced in the UI, and the API underneath answers anyone.
• Tenancy as a filter. Every customer’s records sit in one table, separated by a customer_id check that runs in client-side code.
• Credentials in the open. Production API keys pasted into a platform field, embedded in a prompt, or shipped to the browser in the bundle.
• Automations running as a person. The workflow is connected with a builder’s personal OAuth grant, inheriting full mailbox, drive, and CRM scope. When they leave, it either breaks or keeps running.
• Agents with write access and no trust boundary. An LLM step consumes untrusted input (a ticket body, an inbound email, a scraped page) and its output drives an action with real permissions.
• No usable logs. After an incident, nobody can answer what the app touched, for whom, or when.
• Data that left the governed estate. Records copied out of systems with retention and access controls into a platform nobody inventoried, in a region nobody checked.

None of this is exotic. It is the default state of an application that was never designed, only assembled.

Nobody made a bad architecture decision

That framing is wrong, and it is worth being precise about, because it changes the fix.

The builder in finance did not choose a weak trust boundary over a strong one. They did not know a trust boundary was being chosen. The data model, the tenancy model, the retention behavior, the identity the app runs as, and the lock-in to one vendor were all set by defaults.

Defaults are decisions. They were made by the platform vendor, and they were optimized for the demo, for time-to-first-working-screen, because that is what the platform is sold on.

The blame inversion

Here is the part that damages the security team, separate from the technical debt.

The app worked before you touched it. Everyone watched it work. So every failure after your involvement reads as something you caused.

Why is it breaking? Because the demo never had a failure mode. It was never tested with concurrent users, bad input, a rate limit, or an outage in a dependency.

Why is it taking so long? Because nobody is deploying an application. They are building the majority of it that was never built: the authorization model, the isolation, the logging, the operational runbook. All of it measured against a schedule set by the day the demo ran.

The result is a credibility problem. Security and engineering get re-cast as the drag on a project that was never viable, on a timeline that was never real. That reputation is then carried into the next argument, which may be one that matters far more.

The two responses that fail

Ban the platforms. The work does not stop. It moves to a personal account with a corporate card, and you lose the one thing you still had: visibility. Shadow builds are the same risk with the logs removed.

Approve everything. You inherit unbounded operational debt and the pager that comes with it, permanently, for applications you did not design and cannot support.

What actually works

The goal is not to make citizen development safe. It is to make the line between an experiment and a product explicit, and to enforce it before leadership has fallen in love with the experiment.

1. Tier by blast radius, not by tool. Whether something is “real code” is irrelevant. Classify on three questions: what data does it touch, what identity does it run as, and who can reach it. A spreadsheet automation over public marketing copy and an agent with write access to the CRM are not the same object.

2. Push guardrails into the platform tenant. Enforced SSO, scoped service identities instead of personal grants, egress restrictions, logging exported to your SIEM, regional data controls. Set once at the tenant level, these cover every app built on it, including the ones you have not heard about yet.

3. Build a paved road. A sanctioned platform, a sanctioned set of data connectors, and a starter template with authentication, authorization, and logging already wired in. Citizen builders are not avoiding your controls, they are avoiding a blank page. Give them a better starting point than the vendor does.

4. Put the checkpoint before the executive demo. This is the cheapest change on this list and the one that changes the outcome most. A 30-minute review before the prototype reaches leadership costs nothing. The same review after costs you the argument. Make “has this been triaged” a precondition for presenting internal builds, the same way you would for a customer-facing release.

5. Require a written ownership contract. Who is on call when it breaks, who patches its dependencies, whose budget runs it, and what date it gets retired. Any app without a named owner gets an expiry date, not an exception.

6. Publish the delta at demo time. When a prototype is shown, publish a one-page list of what separates it from production: authorization, isolation, logging, backups, support. Do it while the gap is still cheap to close and before it becomes someone else’s disappointment.

The conversation to have with management

Speed is not the disagreement. Nobody in security wants the business to be slow, and the tools genuinely do compress real work.

The disagreement is about undo cost. A prototype is a cheap experiment right up to the moment it holds customer data, runs with production credentials, or gets promised to a client. After that it is a liability with a nice interface, and the cost of unwinding it is paid by people who were not in the room when it was approved.

The ask is one sentence: let security define the line between experiment and product, and enforce it before the applause.

The takeaway

These platforms are not the problem and they are not going away. The problem is process. Organizations are letting a prototype’s success act as the approval gate for production, and then billing the difference to the security and engineering teams.

Move the gate earlier. It is the only intervention that is cheap.

If a build like this has already reached production in your environment and you need to understand what it exposed, Profero can help.