Your AI-Built App Passed a Security Scan. Production Is Where the Story Starts.

AI app builders are adding serious security features.

That is a very good thing.

Lovable recently announced AI-powered penetration testing for applications built on its platform. Its existing security tooling already checks areas such as source code, dependencies, secrets, and Row Level Security configuration before an application is published.

This is an important shift. Security is moving closer to the moment software is generated rather than being treated as something teams add months later.

But passing a security scan does not mean the security problem is finished.

It means the application passed a particular assessment at a particular moment.

Production begins immediately afterward.

A security scan is a snapshot

Pre-deployment security tools answer valuable questions:

• Does the code contain a known vulnerability?
• Are dependencies outdated?
• Are database policies missing or overly permissive?
• Is sensitive configuration exposed?
• Can a tester bypass authentication or authorization?
• Is the deployed application vulnerable to common attack techniques?

Every team should perform these checks.

The limitation is time.

A scan evaluates the application as it exists during the scan. The application will continue changing after that:

• A coding agent generates another migration.
• A developer temporarily relaxes a policy while debugging.
• A new Edge Function is deployed.
• An integration receives more privileges.
• A secret is accidentally used in the wrong environment.
• Real users begin exercising workflows nobody tested.
• Automated traffic discovers an exposed endpoint.
• A valid account starts behaving in an unexpected way.

None of these changes has to crash the application.

In fact, many security failures make an application appear to work better.

Removing a permission check can fix an empty response. Using an administrative key can make a failed request succeed. Making a storage bucket public can fix a broken image. Disabling Row Level Security can make missing rows reappear.

The feature works.

The boundary protecting the data no longer does.

The production backend is the real security boundary

A modern Supabase application is more than its frontend.

A project can include:

• Authentication and session handling
• Auto-generated data APIs
• PostgreSQL and Row Level Security
• Storage buckets and object access
• Realtime subscriptions
• Edge Functions
• Service credentials and third-party integrations

Supabase records activity across these services in its platform logs. Those logs provide the production evidence of what the backend is actually doing—not what the code, prompt, or deployment summary says it should be doing. Supabase documents these log sources directly.

That distinction matters for AI-built applications.

A coding agent can tell you that it implemented authorization. A pull request can show a policy. A test can confirm that one expected request succeeded.

Production activity answers a different question:

What is happening to the application now?

That includes legitimate users, automation, developers, coding agents, integrations, misconfigurations, and attackers. Once their actions reach the backend, the backend sees the result without caring which tool generated the code.

Code review, pentesting, and monitoring solve different problems

These security layers are complementary.

Code and configuration scanning

This examines what has been written.

It is useful for finding vulnerable dependencies, leaked secrets, dangerous patterns, and incorrect configuration before deployment.

Penetration testing

This actively exercises the application like an attacker.

It is useful for finding exploitable endpoints, authorization failures, injection paths, exposed data, privilege escalation, and business-logic weaknesses.

Lovable’s move to make this more accessible is meaningful precisely because “the application builds” and “the application resists attack” are different outcomes. Lovable describes that gap in its pentesting announcement.

Continuous production monitoring

This observes what happens after deployment.

It is useful when:

• The application changes after its last assessment.
• A valid credential is used in an unsafe context.
• Authentication traffic becomes suspicious.
• A data-access boundary changes.
• Production behavior differs from the expected application flow.
• An attacker begins exercising a weakness that was previously unknown.

A scan asks, “Can this be exploited?”

Monitoring asks, “What is happening right now?”

A production application needs both answers.

The AI development loop makes continuous visibility more important

Traditional development usually creates friction between an idea and a production change.

Someone writes code. Someone reviews it. Tests run. A deployment is prepared. The change reaches production.

AI coding compresses that loop.

A developer can describe a feature, approve the result, and deploy it within minutes. That speed is valuable, but it also means security-sensitive changes happen more frequently.

Consider a common Supabase debugging sequence:

1. A query returns no rows.
2. The coding agent assumes the table or query is incorrect.
3. It changes an access policy so the expected data appears.
4. The feature starts working.
5. The change is deployed.

An empty result and a denied result can look similar from the application side. A broader policy may therefore look like a successful fix.

The agent completed the task it was given. The developer saw the feature work. The application may continue operating normally.

The security regression becomes visible only when someone deliberately reviews the policy—or when production activity exposes its consequences.

This is not an argument against coding agents.

It is an argument for giving fast-moving development teams an independent view of the backend.

Where Defencecore fits

Defencecore is a continuous security monitor for Supabase applications.

It connects to a Supabase project with read-only access and watches the platform activity the project already produces across Auth, Postgres, API traffic, Storage, Realtime, and Edge Functions.

When something requires attention, Defencecore opens an incident that includes:

• A plain-language explanation
• The affected part of the project
• Relevant production evidence
• A recommended investigation or remediation plan

That plan can be handled manually or passed to a coding agent such as Claude Code or Cursor.

Defencecore does not modify the database, deploy code, rotate credentials, or automatically rewrite production. Read-only operation is intentional: the system watching production should not have the ability to become the production incident.

You do not need to instrument every generated feature or depend on a particular AI builder. If the application uses Supabase, the relevant backend activity reaches the same production surface whether the frontend was created with Lovable, Bolt, Replit, Claude Code, Cursor, or by hand.

The security stack for AI-built apps

A sensible workflow now looks like this:

1. Generate quickly.
2. Review security-sensitive code and configuration.
3. Scan before publishing.
4. Pentest important releases and workflows.
5. Monitor the production backend continuously.
6. Give developers—or their coding agents—enough evidence to respond safely.

AI has dramatically reduced the cost of creating software.

The next step is reducing the cost of understanding what that software is doing in production.

That is what we are building at Defencecore.