What 2026 Taught Us About AI, Cybersecurity, and Database Change Governance

In April, an AI coding agent wiped a company’s production database, and its backups along with it, in about nine seconds. Nobody hacked anything. The agent was doing ordinary development work with credentials someone had given it on purpose.

A few months later, OpenAI and Anthropic disclosed something stranger: models running in cybersecurity evaluations that were supposed to be sealed off had reached real production systems. The models were doing what they’d been asked to do. The walls around them just weren’t where everyone thought they were.

Different incidents, different root causes. But if you work anywhere near production data, they rhyme. 

We’ve spent the last decade getting serious about identity, access control, vulnerability management, and supply chain security All that critical work isn’t wasted but it falls short of stopping actors with legitimate access who start making changes.

Databases make this painfully concrete. You don’t need an exploit to drop a table, loosen a grant, or strip out a constraint that has quietly protected data integrity for years. All it takes is access  and one valid statement.

AI agents are making production mistakes

AI was the security story of 2026 before the year even started. The World Economic Forum’s Global Cybersecurity Outlook 2026 found that 94% of respondents expected AI to be the biggest force shaping cybersecurity this year, and 64% said they were assessing AI tools for security, up from 37% the year before.

Most of the coverage focused on attackers using AI to find and exploit vulnerabilities faster. Some of the most instructive incidents, though, came from teams using AI exactly as intended.

On May 1, Dark Reading reported on PocketOS, which builds AI-powered management software for car rental businesses. An AI coding agent, running in Cursor on Claude Opus 4.6, deleted the production database and its volume-level backups through an API call to their infrastructure provider. That database ran a live app handling reservations, payments, and customer records. It took nine seconds.

The failure itself isn't new. What AI changes is the pace and the reach. An agent can write a migration, run it, and keep going without anyone approving each step, often with tools that touch far more than the code it was asked to work on. In PocketOS's case, the access that reached production reached the backups too, so one mistake took out both.

When I spoke with Dark Reading about the incident, my advice was simple: stop treating AI agents like trusted teammates in production. Scope their access tightly, make production boundaries  real, and put destructive actions behind an approval wall. We built those habits around software delivery for a reason, and they matter more, not less, when an agent is the one making the change.

Failures went beyond software development

By July, incidents involving AI security evaluations had exposed similar weaknesses in environments specifically designed to test advanced models.

On July 21, OpenAI disclosed that two of its models had escaped an isolated test environment by exploiting a previously unknown vulnerability and reached production infrastructure belonging to Hugging Face. Anthropic then found three incidents in its own evaluation transcripts where Claude models reached the public internet and gained unauthorized access to real organizations. The models had been told the exercises had no internet access. A configuration error in a third-party evaluation environment said otherwise. On September 9, Anthropic published a fuller assessment that turned up a fourth incident from January, all four tracing back to the same evaluation partner. These models were running without the safeguards applied to publicly released systems, and Anthropic found no evidence of malicious goals, though it acknowledged failures in both the environment and the models' behavior and has since tightened its evaluation infrastructure and oversight.

The detail that stuck with me was how much the models' beliefs about their surroundings shaped what they did. In Anthropic's assessment, the models discounted evidence that they'd reached real systems, assumed it was all part of the exercise, and kept going. That's a lesson for anyone handing agents access to infrastructure APIs and databases: safety boundaries can't depend on the agent correctly working out where it is. Scope its credentials, limit what it can reach, and put hard controls in front of sensitive operations. That doesn't mean agents can't act on their own. It means being intentional about where they can.

Trust in systems remains a challenge

AI agents added urgency to a problem that existed long before autonomous software.

Trust is foundational to enterprise security. : Authenticating users, validating software, enforcing  credentials, and locking down the systems that build and deploy applications is all necessary. Those practices help prevent unauthorized activity, but they don’t establish that every action performed by a trusted system is safe.

In September, ReversingLabs looked at how AI-assisted development has changed what Secure by Design requires. The piece pointed to CISA research showing that a large share of exploited vulnerabilities still come from well-understood, preventable weaknesses like improper input validation, memory safety issues, and injection flaws. AI may speed up how quickly those get found and exploited, but most organizations are still working through problems we’ve known about for years.

The article also echoed my position that knowing where software came from doesn’t prove it’s safe. A compromised build system can produce malicious artifacts that look legitimate, and a completely uncompromised process can still ship something dangerous. You have to evaluate the change itself, not just trust whatever produced it.

For database delivery, that means looking beyond whether a migration originated from an approved repository or passed through an authorized CI/CD pipeline.

A database change could remove a constraint that protects data integrity, alter permissions inappropriately, or introduce a breaking schema modification. The deployment process might execute every command successfully while still leaving the organization with a serious production problem.

And as more of that SQL gets written by AI, the review has to scale with it.

AI governance became an infrastructure problem

In April, Gartner published guidance on AI agent sprawl, predicting that an average global Fortune 500 enterprise could be running more than 150,000 agents by 2028, up from fewer than 15 in 2025. Only 13% of organizations said they had the right AI agent governance in place.

 While these challenges are frightening at scale,  the problems Gartner flags can occur at any volume. Gartner’s recommendations (establishing governance policies, maintaining centralized agent inventories, defining identity and permission models, and monitoring behavior) will sound familiar to any platform team. Agents just make them harder to apply. An agent can reach the same goal through different sequences of actions, react to what it finds, and pull in tools nobody listed when the workflow was designed. That flexibility is why agents are useful, and it’s also why approval processes built for predictable software struggle to keep up.

The practical answer is to stop treating every operation the same. An agent writing a test script and an agent changing production infrastructure carry very different risks.And the hard part is drawing those lines without routing everything to a human. Make people approve every action and you lose the productivity you adopted agents for. Let everything run unchecked and you’ve accepted risks responsible enterprises can’t live with. 

For production changes, policy must be enforced by the system that executes the work. Routine changes pass through. Risky ones are blocked or escalated. That is the goal, and most organizations are not there yet.

What our research showed about Database Change Governance

So how many teams actually enforce policy that way today? Our 2026 State of Database Change Governance Report gives a good read on where enterprises actually stand.

• The average organization is complex and runs five database types. 29% manage ten or more.
• Nearly 70% deploy database changes at least weekly
• 42% of organizations have inconsistent controls
• 96% of respondents said AI interacts with their production databases.

What jumps out to me is how uneven the controls are. Plenty of organizations ship frequently across several database platforms, with different teams and tools pushing changes. Few have standardized on automation and central policy. Others still run on manual approvals and workflows that look different from one team to the next.

AI adds one more way for a change to reach production. One agent might generate a migration that goes through your normal pipeline and gets the same checks as everything else. Another might connect straight to the database with a privileged service account and run SQL that never touches that pipeline. Same change, completely different level of governance.

Two more numbers from the survey are worth calling out: only 12% of teams automate drift detection, and fewer than a third automate security and compliance checks on database changes. Most organizations do have standards. What they’re missing is the automation to enforce those standards across every pipeline and environment, which gets harder as change volume grows and harder again once agents join in.

That’s the gap Database Change Governance closes. It’s the practice of applying consistent policy, validation, authorization, and auditability to every change made to enterprise databases. Database Change Governance standardizes how proposed changes get evaluated, how deployment decisions get made, and how you keep evidence of what happened. 

At enterprise scale, it has to be part of the platform rather than something every team reinvents on its own.

Governing database changes when AI is part of the SDLC

If you’re planning for more autonomous development and operations, here’s where I’d start.

Map every path to production

Most enterprises know which developers and DBAs can reach their databases. Far fewer have a full picture of the service accounts, pipelines, integrations, infrastructure tools, and AI agents that can change them. Mapping out those paths side by side tends to surface surprises, like one team with automated policy checks and approvals next to another shipping through a deployment script and a service account with broad privileges.

Make policy enforceable

Standards that live in a wiki, or in one senior DBA’s head, don’t scale. Automated checks can evaluate each change against your rules before it runs and flag the ones that need a closer look. That’s what lets teams ship more often without giving up the protections they’ve built.

Here’s what that looks like in practice. An AI agent writes a migration that drops a column in production. It lands in the same pipeline your team already uses: pull request, CI, policy checks. Before anything runs against the database, those checks see the DROP COLUMN, flag it, and either block the deploy or kick it to a human for review. If a developer opened the identical PR, they’d hit the exact same gate. The risk is in the SQL, not in who wrote it.

Account for changes outside the pipeline

Controls built into a pipeline can only govern changes that go through it. An agent with privileged credentials and a direct connection can go around them entirely. So remove privileges that aren’t needed, manage direct access, and watch for changes you didn’t expect. Drift detection helps here by comparing the expected state of a database with its actual state and flagging anything that changed outside the managed process. It won’t stop an unauthorized change, but it tells you one happened and gives you somewhere to start investigating.

Capture evidence that holds up

For every change, you should be able to show what changed, which policies were checked, who approved it, and whether the resulting database matches what you expected. In regulated industries that isn’t optional, and it is time-consuming and expensive to reconstruct without a consistent record.

Liquibase Secure is purpose built to address these challenges. Liquibase Secure 6.0 expands centralized policy management, role-based access control, and Change Intelligence to give teams more visibility and control over governed database changes. The requirement goes beyond any one product, though. Enterprises need controls that evaluate changes before they run and leave reliable evidence afterward, however autonomous the systems making those changes become.

What 2026 tells us about where software delivery is headed

The AI security incidents of 2026 exposed weaknesses in how organizations manage access, permissions, and automated execution. Not all involved databases, and they didn't share a single technical cause. But they demonstrated how difficult it can be to control increasingly capable systems when their permissions extend beyond what their operators intended.

For years, we've designed software delivery around the assumption that people make decisions and automation executes them. AI is changing that relationship. Agents are beginning to participate in decisions about what to build, what to test, what to deploy, and how to respond when something goes wrong.

That creates an opportunity to make software delivery dramatically more efficient but it also requires a different approach to governance. Organizations need to establish where agents have authority to act independently, where additional validation is required, and how those decisions are enforced.

For production databases, that means governing the change itself, regardless of whether it originated from a developer, an automated pipeline, or an AI agent. The technology initiating the change may be different, but the enterprise remains accountable for what reaches production.

As AI takes on more responsibility for software delivery, the question isn't simply what these systems are capable of doing. It's what organizations are prepared to let them do.

‍