AI Website Builder Security Is Moving Into the Publish Flow

For much of the web’s history, security has appeared around an already-built website.

Build the site. Publish it. Then install a security plugin, configure hosting controls, connect a scanner, enable a firewall, or pay someone to monitor it.

That model is not disappearing.

But another model is becoming visible.

In a Base44 Publish dialog Quttera observed in September 2026, Security status appears directly beside the decision to put the application online.

The application was marked Out of date. A Scan action appeared beside the warning, and the interface showed when the previous scan had run.

Publish was still available.

That distinction matters. The security check was visible at the publishing decision, but in the state we observed it was not a mandatory gate.

The broader change is more significant than the button:

Security has entered the publishing workflow.

Once users see security beside Publish, they begin to expect security to be part of publishing.

Current implementations can be thought of as points on a spectrum from visible to blocking.

Base44 describes its Production Pack as three pre-publish capabilities: Verification, Testing Agent, and Security Scan. Security Scan reviews access controls and vulnerable dependencies. Its Enterprise Security Center extends this into portfolio-level visibility and adds software composition analysis (SCA), which examines dependencies, and static application security testing (SAST), which analyzes code for insecure patterns. (base44.com)

Lovable says its basic security scan runs automatically every time an application is published and checks areas including database configuration, row-level security (RLS), cloud settings, and authorization-related issues. Its current security page says Business and Enterprise workspaces can schedule recurring deep scans, while workspace admins can configure critical findings to block publishing. (lovable.dev)

Replit uses another model. It performs security analysis during development and before publication, while its Security Center continues checking dependency exposure across projects after deployment. (replit.com)

The implementations differ, but the direction is increasingly consistent:

Security is becoming part of the creation experience.

WordPress represents one of the web’s most successful open-platform models.

It is open-source software built around PHP and a database such as MySQL or MariaDB, with themes, plugins, APIs, and custom development providing extensive control and extensibility.

Security is developed around that architecture. Owners can combine hosting controls, security plugins, backups, scanners, firewalls, monitoring, and specialist services according to their needs.

Joomla and Drupal broadly belong to the same open and extensible tradition.

That model isn't inherently obsolete. It offers control, portability, extensibility, and mature ecosystems.

WordPress does not need to disappear for AI builders to change what users expect.

The change may be simpler:

With an open CMS, owners and developers often make explicit implementation choices: hosting, extensions, access controls, backups, and security services.

With an AI builder, the interaction may begin with:

The platform can generate much of the application, manage deployment, add dependencies, connect services, and abstract decisions that previously required a developer.

Security is following the same pattern.

Users should not need to understand SCA, SAST, or RLS simply to answer:

Publishing is becoming not only a deployment action, but a security decision point.

There is another important development.

AI builders don't necessarily try to provide every security capability themselves. They are becoming places where multiple security systems meet.

Lovable, for example, integrates Wiz findings directly into its Security view alongside its own scanners for dependencies, secrets, database security, and code vulnerabilities. (lovable.dev)

Its Enterprise positioning also describes Wiz and Aikido integrations alongside its native security controls. (lovable.dev)

That makes the builder less a walled garden and more a security integration surface.

The future is therefore unlikely to be:

It is more likely to involve several security perspectives converging around the same application.

That leads to the question most relevant to Quttera:

Even sophisticated publishing security does not freeze an application in time.

Lovable continues to check dependencies and supports recurring, deeper scans on eligible plans. (lovable.dev)

Replit says its dependency scans run in the background every few hours and when new CVEs are published. Separately, when Replit identifies a new CVE, it automatically checks it against project dependencies whether or not Auto-Protect remediation is enabled. Automatic patch preparation through Auto-Protect is opt-in and off by default at launch. (ld.replit.com)

Base44’s Security Center records scan state and risk across a workspace and allows administrators to rescan or unpublish applications. (base44.com)

The lifecycle is therefore becoming more sophisticated than:

BUILD → SCAN → PUBLISH

A more useful model is:

BUILD → VERIFY → PUBLISH → OBSERVE → VERIFY AGAIN

That is the lifecycle already emerging.

Dependencies change. New vulnerabilities are disclosed. New versions ship. Configuration changes. Third-party resources change. Credentials can be compromised.

The application verified at publication is not automatically in the same state weeks later.

Base44’s own interface makes the idea unusually tangible:

a security result can become out of date.

A builder can know things an outside observer may never see: source code, packages, build history, database policies, workspace permissions, secrets configuration, and deployment state.

That context is extremely valuable.

Independent observation starts from another direction: what the deployed asset is actually presenting to the outside world.

For example:

• A third-party script that was legitimate at publication later changes behavior.
• A redirect begins affecting only certain visitors or navigation paths.
• A domain acquires a blacklist or reputation warning even though its source repository has not changed.

Quttera’s current public platform focuses on this deployed perspective through outside-in scanning, behavioral and heuristic detection, malicious-script and integrity analysis, and blacklist and reputation monitoring. (quttera.com)

One perspective asks:

How was this application built?

The other asks:

What is this application presenting to the world now?

Those are different questions.

The machine-facing surface of a website is changing as well.

WebMCP is an emerging browser API that allows websites and web applications to expose functions as structured tools that AI agents can discover and invoke directly. Instead of relying only on visual interfaces or interpreting page content, an agent can be told explicitly which actions a website supports, what inputs those actions require, and how to execute them. (WebMCP specification)

As of October 2026, WebMCP remains experimental. The specification is published as a W3C Web Machine Learning Community Group draft, not a finalized W3C standard, and Chrome currently exposes WebMCP through experimental support and an origin trial. (Chrome for Developers)

But the direction is significant.

A live web asset may increasingly expose several different surfaces at the same time:

what humans see
what browsers execute
what crawlers and AI systems read
what AI agents are allowed to do

That final layer changes the Web Integrity question again.

A website may not simply provide information to an AI agent. It may expose actions such as searching, submitting a form, changing application state, making a booking, or initiating another consequential workflow.

The integrity of those capabilities therefore matters alongside the integrity of the page itself.

Chrome’s own WebMCP security guidance highlights risks around untrusted tool output, indirect prompt injection, consequential actions, and the origins that are permitted to discover or execute exposed tools. It recommends explicit signals for untrusted content and consequential actions, along with careful controls over which origins can access a tool. (Chrome WebMCP security guidance)

This extends a question Quttera has already explored in the context of websites serving humans, bots, and AI agents:

For Quttera, this extends the Web Integrity question: as live web assets become more dynamic and machine-operable, should integrity evidence also cover the capabilities they expose to AI agents?

Traditional website compromise often brings to mind modified PHP files, web shells, infected plugins, or malicious scheduled tasks.

That mental model does not map neatly onto every builder-hosted application.

If the website owner does not control the underlying server, the relevant risk may appear elsewhere:

• Client-side: compromised scripts, unsafe embeds, or malicious redirects.
• Account and configuration: stolen publishing credentials, exposed secrets, or unsafe access rules.
• Supply chain: vulnerable or malicious dependencies.
• Reputation and abuse: phishing, spam, blacklist exposure, or other misuse of the deployed domain.

The evidence we need has to match this new risk surface.

The same change has another side.

AI is not only reducing the effort required to build legitimate applications. It can also reduce the effort required to create the web asset used in an attack.

Cisco Talos documented a 2026 phishing incident in which attackers used Softr, an AI-based web application development service, to generate a credential-harvesting page targeting Microsoft Exchange and Outlook Web Access users. Talos said the page could be created from a form template with a few prompts and without conventional coding. (blog.talosintelligence.com)

That changes an important assumption.

A malicious web presence does not necessarily have to begin with a compromised CMS or hacked server.

The web asset itself can be created for abuse.

It might present itself as a login page, survey, registration form, support workflow, campaign page, or another ordinary-looking web experience.

It doesn't have to exist in isolation.

A malicious or compromised asset can be reached from a legitimate website, distributed by email or social media, included in a customer journey, presented as a survey, supplied by a partner, or shared through another trusted workflow.

From the visitor’s perspective, the mechanism may look completely normal:

click a link → open a page → interact with a web application

The technology used to create that page may be an open CMS, a conventional site builder, an AI application platform, or something generated specifically for a temporary campaign.

The common object is still the web asset.

This broadens the integrity question:

Quttera’s API already supports programmatic scanning of websites and domains for malware, blacklist status, and integrity findings. In an integrated workflow, that evidence can inform whether to trust, approve, distribute, or investigate a web resource.

That means the Web Integrity problem extends beyond monitoring websites an organization owns.

It can also apply to web assets an organization is about to trust, link to, distribute, approve, or expose to users.

The pattern is not limited to website creation.

In September 2026, Cisco Talos published research on CLOSEDQUORUM, an experimental Windows malware implant designed to delegate tactical command-and-control decisions to commercial large language models.

Talos did not confirm deployment in the wild, so CLOSEDQUORUM should not be presented as evidence of an active autonomous-malware campaign.

Its importance is narrower: Talos describes it as an example of effort displacement, where parts of an attack phase that previously required an operator can increasingly be delegated to AI-driven decision-making. (blog.talosintelligence.com)

Taken together with the Softr incident, the direction is worth watching:

AI can reduce the human effort required both to create malicious web assets and to automate other parts of an attack chain.

That does not make AI-built applications inherently suspicious.

It does suggest that the number, variety, and speed of web assets requiring trust decisions may grow.

The future is unlikely to be WordPress or AI builders.

Organizations will operate several models at once.

An agency might manage a WordPress corporate site, a Shopify store, a custom React portal, a Base44 application, a Lovable customer tool, and a Replit application.

But the relevant universe can be larger than the properties it owns.

It may also include partner landing pages, affiliate destinations, campaign microsites, survey links, externally hosted forms, and other web resources that customers or employees are expected to trust.

For an organization dealing with ten owned sites and dozens of external destinations, the operational question is not simply:

It becomes:

That question survives every change in development technology.

The live web asset remains a common denominator.

Quttera uses Continuous Web Integrity to describe a framework for maintaining security and integrity evidence about a live web asset over time, rather than treating one scan, one deployment, or one initial approval as permanent proof of safety. Quttera’s current public positioning emphasizes outside-in monitoring, behavioral detection, malicious scripts, integrity signals, and blacklist and reputation visibility. (quttera.com)

The asset may be owned by the organization, created through a builder, supplied by a partner, or encountered as part of a customer journey.

The common question is:

In practical terms, that evidence can include how the site behaves, which resources it serves, whether suspicious redirects or malicious content appear, how its reputation changes, and whether its observed state remains consistent with what its owner or operator intended.

A useful way to think about the emerging model is:

Builder context

• connected application-security tools
• platform-independent deployed-state evidence

→ a more complete Web Integrity picture

That is the model we believe deserves further testing.

This analysis is based on current public documentation from Base44, Lovable, and Replit; Quttera’s hands-on use of builder workflows; direct observation of relevant user interfaces during August and September 2026; and published threat research from Cisco Talos.

It is not an exhaustive security assessment of any platform.

We did not use privileged access to the builders’ internal systems, and capabilities may vary by plan, configuration, and application type.

Because these products are evolving quickly, treat individual feature descriptions as dated observations rather than permanent characteristics.

The market change is visible.

The product and engineering implications still require testing.

Four questions guide our work:

1. What can Quttera reliably establish from a deployed application without privileged platform access?
2. Where could independent verification fit naturally into an existing build or Publish workflow?
3. When would a deeper connector provide enough additional evidence to justify the extra access and complexity?
4. Can the same integrity evidence help assess web assets an organization does not own but is about to trust, distribute, link to, approve, or expose to users?
5. As standards such as WebMCP emerge, should Web Integrity evidence also cover the tools and actions a live website exposes to AI agents?

These questions inform Quttera’s ongoing research across its website-security platform, ThreatSign, and Security & Compliance API.

They do not announce integrations with Base44, Lovable, Replit, or any other builder.

The objective is not to reproduce security functionality those platforms already provide.

It is to identify where platform-independent evidence adds information that remains useful across different creation technologies and trust relationships.

Modern AI-built applications may depend heavily on JavaScript, client-side rendering, authenticated states, and platform-managed backend behavior.

An outside scanner can only make claims about what it can reliably observe.

That creates practical research questions:

• How much of a heavily client-rendered application can be observed from outside?
• Which important application states require authentication?
• Which behaviors require browser execution?
• Where does independent observation cease to be sufficient?
• When does platform-provided or connector evidence materially improve confidence?

We are testing how much of heavily client-rendered, authenticated applications we can observe reliably from outside, and where deeper evidence becomes necessary.

We should demonstrate outside-in coverage, not assume it.

For organizations already using AI builders or managing mixed web portfolios, four practices are useful today:

1. Understand scan coverage and timing. Know what your platform checks, when it checks it, and whether findings are advisory or blocking.
2. Treat stale security state as meaningful. “Clean two months ago” describes two months ago.
3. Verify the live asset after important changes. What you intended to deploy and what the outside world receives should agree.
4. Maintain visibility across assets and platforms. Owned websites, partner destinations, redirects, reputation, and other trusted web resources should not become separate security universes simply because they were created differently.

AI is changing more than how quickly we can build software.

It is changing the relationship between people and the technology underneath.

Security is moving with it.

The long-term consequence may not be that every website becomes AI-built.

It may instead be that every web platform—and eventually every web asset entering a trust relationship—is judged against a higher expectation:

Security should be part of creation.
Verification should be part of publication.
Evidence should continue after deployment.

The technology used to build the asset will keep changing.

The live web asset remains.

And increasingly, so should the evidence about its integrity.

The Publish button is becoming a security decision point. It should not become the end of the security lifecycle.