Artificial intelligence is changing software development at an incredible pace.

Today, a developer can describe an idea in plain English and, within minutes, an AI assistant can generate a working application with a web interface, REST API, database, Docker Compose configuration and deployment instructions.

The result often works surprisingly well.

But there is an important question many teams are still not asking:

Who built the security?

That question matters because working software and trustworthy software are not the same thing.

AI optimizes for functionality

Large Language Models are incredibly good at producing working software.

If you ask:

Create a web application with PostgreSQL, Redis and a REST API.

The model will usually generate a solution that is easy to build and easy to run.

Most often, that means Docker.

From a developer’s perspective, this is exactly what they wanted.

The application starts immediately. The database is available. The API responds. Everything looks good.

Mission accomplished.

Or is it?

Functional does not mean secure

A generated application may contain no hardcoded credentials.

It may not expose secrets in a .env file.

It may even follow good programming practices.

And yet, the overall deployment can still introduce unnecessary security risk.

Typical examples include:

  • services listening on 0.0.0.0 by default,
  • databases unnecessarily exposed to external networks,
  • containers running as root,
  • unrestricted container capabilities,
  • images referenced using the latest tag,
  • missing resource limits,
  • missing health checks,
  • overly permissive Docker networking,
  • no security policy for production deployment.

None of these issues necessarily prevents the application from working.

But each of them can increase the attack surface.

That is the uncomfortable truth of : the application can function correctly while its deployment model is still too trusting.

AI is not doing anything wrong

This is not a criticism of AI.

Large Language Models are doing exactly what they were designed to do.

They optimize for the objective they are given.

If the objective is:

Build a working application.

Then they will optimize for functionality.

They cannot automatically know:

  • your organization’s security policy,
  • your network architecture,
  • your model,
  • your compliance requirements,
  • your operational environment,
  • your risk tolerance.

Security is context-dependent.

And that context usually exists outside the prompt.

Convenience often wins over hardening

Many open-source AI projects focus on making installation as simple as possible.

This is completely understandable.

The easier it is to install software, the faster users can evaluate it.

But production security is a different objective.

The safest production configuration is rarely the easiest installation.

Hardening usually requires:

  • reducing privileges,
  • limiting network exposure,
  • applying least privilege,
  • configuring authentication,
  • restricting filesystem access,
  • monitoring runtime behavior,
  • establishing auditing and evidence.

These steps are rarely part of a default installation.

The default path is usually optimized for adoption.

Production requires a different path: one optimized for trust.

The growing security debt of vibe coding

A common pattern is emerging:

  1. AI generates the application.
  2. Docker Compose starts successfully.
  3. The project goes into use.
  4. Security is planned “later”.

Unfortunately, later often becomes months or years.

By that time, the application may already depend on its original assumptions.

The network layout is already expected. The container model is already part of operations. The deployment instructions are copied into environments. The database exposure is normalized. The missing boundaries become invisible.

Security debt accumulates quietly.

And the longer it stays invisible, the more expensive it becomes to fix.

Recent incidents show the trend

Recent vulnerabilities affecting AI infrastructure have demonstrated that the greatest risks are often not the language model itself, but the surrounding deployment.

Misconfigured AI services, exposed management interfaces, insecure MCP servers, overly permissive Docker configurations and insufficient authentication have all contributed to real-world security incidents.

The challenge is shifting.

It is becoming less about whether AI can generate software.

It is becoming more about whether we can trust the environment in which that software runs.

AI needs a security layer

I believe the next generation of AI infrastructure will require an additional layer between AI-generated applications and production deployment.

Not another coding assistant.

A security and compliance layer.

One that can:

  • analyze deployment configurations,
  • identify security weaknesses,
  • recommend hardening,
  • verify compliance,
  • generate ,
  • continuously validate that systems remain trustworthy over time.

In other words, AI can build the application.

Another system should verify whether that application deserves to be trusted.

Security must become part of the AI workflow

Security cannot remain a final manual checklist after the application is already running.

It has to become part of the AI workflow itself.

That means the question should not be only:

Can the AI generate the application?

It should also be:

Can the deployment be hardened?

Are services exposed only where necessary?

Are containers running with minimal privileges?

Are secrets managed correctly?

Are dependencies pinned and reviewed?

Is there monitoring?

Is there evidence that the system was checked?

Without those questions, vibe coding can create speed, but also hidden operational risk.

Functionality is only the beginning

AI has fundamentally changed how quickly we can create software.

That is an extraordinary achievement.

But production systems require more than functionality.

They require trust.

In the coming years, one of the biggest challenges in software engineering will no longer be generating code.

It will be proving that AI-generated systems are secure, compliant and trustworthy enough to operate in the real world.

Vibe coding can build the application.

But somebody still has to build its security.