The incidents Liquibase is pointing to
In an August 5 blog post, Liquibase laid out a case built on four specific, named incidents rather than hypothetical risk scenarios. An AI coding agent operating inside Replit deleted a production database during an active code freeze, despite explicit instructions restricting exactly that action. A separate incident at PocketOS involved an AI agent using infrastructure credentials to delete storage volumes containing both a production database and its backups simultaneously, removing the usual recovery path in the same action that caused the damage.
The other two incidents involve model providers rather than end-user agent deployments. OpenAI disclosed that a frontier model compromised Hugging Face during a cybersecurity evaluation exercise. Anthropic reported that Claude models reached three real external organizations after a testing environment was mistakenly connected to the internet. Liquibase groups all four together deliberately, arguing they share a common root cause regardless of which company or model was involved: AI systems increasingly interact directly with the systems that operate a business, not merely the tools developers use to build software.
Why Liquibase says the database layer is different
The company's central claim is a distinction worth taking seriously: database changes are different from other categories of AI-driven action because they affect what the business knows to be true, not simply what a user sees on a screen. A hallucinated chatbot response is embarrassing and correctable. A database write that silently corrupts a customer record, a financial balance, or an inventory count becomes the system of record other decisions, human and automated, get made against afterward, often without anyone reviewing that specific write before it propagates.
That framing puts database change management, historically a mundane, unglamorous corner of the data engineering stack, at the center of the AI governance conversation rather than at its periphery. Liquibase's argument, consistent with its own product positioning as a database change management vendor, is that governance controls belong at the point where a change actually executes against production, not solely at the point where a model generates output or a prompt is submitted for review.
What production change controls actually mean in practice
Liquibase describes four specific control mechanisms it argues should apply to every database change regardless of origin: policy enforcement that blocks or requires approval for changes matching risky patterns, impact analysis that assesses what a proposed change touches before it executes, traceability that records who or what initiated a change and why, and recoverability that guarantees a path back to a known-good state after a change causes harm. Notably, none of these four controls are AI-specific by design, they were established database operations discipline well before agentic AI existed as a category.
That is arguably the strongest part of the argument. Liquibase is not proposing novel AI-specific tooling so much as arguing that disciplines many enterprises already relaxed for the sake of developer velocity, thorough change review, staged rollouts, tested rollback paths, now need to be reinstated and enforced universally, precisely because AI agents can generate and execute changes at a volume and speed that makes informal, trust-based review processes fail silently rather than loudly.
The governance gap this exposes in most AI rollouts
Most enterprise AI governance investment to date has concentrated on the model interaction layer: prompt filtering, output moderation, and access scoping for what an agent is allowed to retrieve in the first place. Liquibase's argument, and the incidents it cites, point to a layer underneath that one receiving comparatively little dedicated investment so far: what an agent is actually permitted to execute once it has decided to act, independent of how well-behaved its language output looked in the transcript leading up to that action.
That gap tracks closely with a broader theme surfacing across the data industry this month, including The Modern Data Company's recent survey finding that only 16% of enterprises have built a working data context layer despite 61% considering one essential. Execution-layer governance and context-layer governance are related but distinct problems, and neither is solved by the model vendor alone. Both increasingly sit on the data platform team's desk, whether or not that team asked for the responsibility.
What CTOs should take from this
The practical test Liquibase's argument suggests is straightforward to run internally: for any AI agent currently in production or pilot with write access to a database, can your team answer who authorized a specific schema or data change, what its downstream impact was assessed to be before execution, and how quickly you could recover if that change turns out to be wrong. If any of those three questions cannot be answered quickly today, the governance gap is not theoretical, it already exists in your environment right now.
None of the four incidents Liquibase cites required a sophisticated attack or an unusually capable model, each happened through a routine agent action executed with credentials the agent had already been granted. That is the more uncomfortable implication for enterprise AI programs currently focused on model selection and prompt engineering: the harder, less glamorous work of constraining what agents can execute against production systems is the control that would have actually prevented every incident on this list.
