On April 20, 2026, Lovable - the AI-powered vibe-coding platform valued at roughly $6.6 billion - became the center of one of the biggest AI security stories of the year. Researchers disclosed a Broken Object Level Authorization (BOLA) vulnerability that exposed source code, database credentials, AI chat histories and customer data across applications built on the platform. Lovable's initial response described the behavior as "intentional."
That response caught my attention more than the vulnerability itself.
Calling exposed customer data "intentional behavior" tells us something important about how many AI platforms are being built today. The priority is getting users from idea to application as quickly as possible. Security and governance are expected to follow. The assumption is that trust can be added later, once the application already exists.
I think that's backwards.
For compliance-led organizations, governance is the first step. It determines who can access content, what AI systems are allowed to do and how every action is monitored, approved and audited. Trust isn't something you grant and then govern. Governance is how trust is earned.
The most dangerous default in AI isn't speed. It's trust without governance. We have become remarkably comfortable giving AI systems access to production data, enterprise applications and business workflows before asking whether they have earned that level of trust. Every new AI tool promises to remove friction, but very few force organizations to think about governance before deployment.
The Lovable incident is not interesting because one platform experienced a security issue. Security incidents happen every day. It matters because it reflects a broader shift happening across enterprise technology. AI is no longer sitting on the edge of the business as a productivity tool. It is increasingly becoming part of the infrastructure that creates, manages and delivers digital experience. When infrastructure is trusted by default instead of governed by design, incidents like this become much more than isolated mistakes.
How we got here
The Lovable incident happened because AI is changing its role inside the enterprise. A few years ago, most AI tools generated text, summarized meetings or answered questions. Today they write code, build applications, connect to APIs and interact directly with production systems. They have gone from assistants to foundational systems to participants, yet many organizations still govern them like simple productivity tools.
Content platforms have undergone a similar transformation. A CMS used to exist primarily to publish web pages. Today it supplies content to websites, mobile applications, AI assistants, customer support tools, search engines and retrieval systems that power large language models. Content no longer has a single destination. It moves continuously between systems, which means the CMS has become part of the infrastructure that feeds AI. The value of that content has increased, but so has the importance of governing who - or what - can access it.
At the same time, AI adoption has spread faster than most organizations can inventory it. Marketing teams build internal tools. Sales teams experiment with AI assistants. Operations teams automate repetitive work through third-party platforms connected with a few clicks. Many of these tools are adopted without formal security review, creating a growing layer of shadow AI across the enterprise. IBM's 2025 Cost of a Data Breach Report found that organizations experiencing AI-related security incidents overwhelmingly lacked proper AI access controls, while shadow AI added an average of $670,000 to the cost of a breach.
The way these tools connect has also changed. Modern AI platforms rarely operate in isolation. They authenticate through OAuth, consume APIs and inherit permissions from the systems around them. A compromise is no longer contained to one application. It can extend to every connected service that trusts it. The Vercel breach demonstrated exactly that pattern. The compromise began with a third-party AI tool and eventually reached production systems through a chain of trusted connections. That is becoming the defining characteristic of AI-era security. Organizations are no longer securing individual applications. They are securing relationships between them.
Trust is built with the right architecture
For years, enterprise security has focused on protecting applications. Scan the code. Patch the vulnerability. Fix the misconfiguration. OWASP Top 10. Those practices still matter, but AI is changing where the real risk begins. Increasingly, the question is not whether an application is secure. It is whether it should have been trusted with access it’s not prepared for yet, in the first place. This proved to be true with a patent of mine since day 1.
That is why I believe shadow AI is not a productivity problem. It is a governance problem. Every week, teams adopt new AI tools that many of them connect to enterprise systems in minutes using OAuth or API keys. They never go through stringent architecture & security reviews. If your security team does not threaten to model a tool, it cannot evaluate its data flow and access, what permissions it inherits or what happens if it is compromised.
This changes how we should think about adoption and governance. AI tools don’t require a checklist you complete before an audit, and it is not a policy document that lives in your intranet. Governance is the process of deciding what systems deserve trust before they are connected to the rest of your business. Once an AI application has access to your content, your customers or your production environment, you have already made that decision whether you realized it or not.
That is why the next generation of AI security will not be won by organizations with the best prompt engineering or the fastest development teams. It will be won by organizations with the clearest understanding of what AI tools exists inside their business, how it's being used within the organization, the number of disparate systems, the skills being created, what it can access and who approved the access. Governance should be the starting point for AI adoption.
What this means for digital experience teams
Digital experience teams are now responsible for more than creating and publishing digital experiences. They are increasingly responsible for the systems that create, move and distribute content across the enterprise. That does not make marketers security experts, but it does mean content operations can no longer treat security as someone else's responsibility. Remember the classic saying “Security is everyone’s responsibility”. The decisions made during implementation often determine whether governance is built into a workflow or bolted on after something goes wrong.
The first step is understanding what has access to your content.
Every AI platform, plugin, integration and SaaS application connected to your CMS should be inventoried and reviewed. If a tool can read content, write content or authenticate against your content platform, it is part of your attack surface. You cannot govern systems you do not know exist, and you cannot secure relationships you have never documented.
The second step is changing how you think about trust.
AI-generated code should be reviewed before it reaches production. Environment variables and credentials should be treated as sensitive by default rather than relying on developers to label them correctly. Not every piece of content belongs in an AI retrieval system, so organizations should establish clear rules around what content can be indexed, what should remain internal and how AI-generated interactions are logged and audited. Good governance starts long before a model generates its first response.
Finally, make governance part of everyday operations instead of an annual compliance exercise.
Patch AI-enabled platforms as quickly as you patch operating systems. Separate automated activity from human activity in your logs so unusual behavior is easier to detect. Review permissions regularly as new AI tools are introduced. None of these practices are particularly new, but AI has made them significantly more important. The organizations that adopt AI successfully will not be the ones with the longest list of tools. They will be the ones with the clearest understanding of how those tools interact with their content.
Where dotCMS stands
At dotCMS, we've never viewed security as a standalone feature. It has always been part of a broader governance framework and baked into our core architecture from the beginning. As AI becomes another consumer and creator of enterprise content, that philosophy becomes even more important. Governance should be built into the systems that create, manage and deliver content, not layered on after new tools have already been connected.
That philosophy is reflected throughout the platform. Each customer is granted exclusive access to their own content management environment and database instance. Security patches are rolled out automatically in dotCMS Cloud, while security controls including a Web Application Firewall, AES-256 encryption at rest, TLS 1.2 in transit and cross-region daily backups help maintain the platform's security posture. Organizations building automated workflows can use dotCLI for secure, role-aware access within CI/CD pipelines. International certifications such as SOC 2 Type II, ISO/IEC 27001:2022, ISO/IEC 42001:2023 and TX-RAMP Level II demonstrate that these controls are independently audited and continuously validated.
The AI era does not mean organizations should care less. It rather requires them to trust differently. Organizations should build trust as a foundation where governance comes first and is earned with security.