The State of AI Governance in 2026

We surveyed 307 senior technology and security leaders—CTOs, CIOs, and CISOs—at companies ranging from medium to enterprise to understand how leaders are really thinking about governing and securing AI-powered building. The findings show a growing gap between visibility and governance.

When asked how often their organization has experienced a production incident caused by an AI-generated internal tool, 51% of respondents said “not to my knowledge, but I can’t say for certain.” About one in five (19%) said they’d experienced at least one. With that uncertainty comes fear: 93% of respondents are at least somewhat concerned about vibe-coded internal tools running in production.

These technical leaders know something in governance is broken, and 55% say they want centralized platform-level governance to fix it. But with only 24% of respondents currently governing at the environment level, it’s clear that the current wave of vibe coding tools is missing something critical.

This report explores how these senior technology and security leaders are approaching governance in the AI coding age: what’s at risk, what’s working, and what’s to come.

Vibe coding has officially gone mainstream, unleashing all sorts of opportunities and threats to traditional software building. Earlier this year, the possibility that employees could prompt their way to replacing entire SaaS tools seemed so real that software stocks actually took a hit.

But that initial hype, it seems, has worn off for technical leaders (if it was ever there to begin with). 93% of senior technology and security leaders are at least somewhat concerned about vibe-coded internal tools running in production. 38% rank it among their top operational risks right now.

Just 4% say they have governance in place that covers AI-generated code regardless of how it was written. Another 4% say it hasn’t come up yet.

Vibe coding, coined by Andrej Karpathy in 2025, is the ubiquitous umbrella term for prompting AI into building a working app, website, workflow, or prototype without going through the traditional steps of software development. Eventually, the practice spread from technical circles to non-technical enthusiasts who could generate software without ever learning to code.

But these new builders aren’t just bypassing writing code. They’re bypassing review and testing steps that they may not have even known to worry about. And the popular vibe-coding tools that have emerged to meet this need often don’t have these governance processes in place.

The potential upsides of AI coding are huge, especially for businesses looking to cut down on software and engineering costs. But the technical C-suite sees the risks clearly. One CTO at a mid-market company had this to say about vibe coding: “I’ve had team members push actual production data to homegrown tools to vibe-coding solutions like Lovable. They have a very light security layer which becomes dangerous when they have real data there.”

Vibe-coding tools are optimized for speed to prototype, using natural language to bring a vision to life. That’s not enough to get tools to production safely, where builders will need to secure and maintain those apps over time.

2026 is the year that shadow IT (software employees use for work outside of IT oversight) becomes shadow AI: tools spun up via prompt to solve an immediate problem that go undetected by traditional governance. Instead of rogue software downloads, technical leaders now have to control the influx of AI-generated tools that are being built faster and out of sight.

Only 5% of senior tech and security leaders are very confident they have full visibility into what’s running in their own production environments. 43% are not confident.

Leaders can tie this lack of confidence directly to the rapid spread of AI-generated tools and concern over how those tools interact with company data.

“Tools get built in hours, sometimes minutes, and they don’t look like ‘systems’ to the people building them,” says one enterprise CISO. “So now you’ve got data moving through a prompt, an API call, a quick script someone pasted together at 10pm. It works. It ships. Nobody logs it anywhere.”

Lack of visibility becomes a tax not just on governance, but also productivity. Teams that have seen massive increases in their velocity are now left with even more tools to manage across sandboxes and staging environments. Once visibility becomes unmanageable at the team and management levels, execs don’t have a chance.

“Discovery is probably the hardest,” said one CISO at a medium-sized company. “By the time you know something has been built and is being used, you’re already too late. Let alone knowing what exactly they’re doing with it or if it’s safe and durable.”

Still, about half (52%) are somewhat confident: they know roughly what’s running but acknowledge that gaps still exist. This confidence could come from early adoption of emerging standalone AI monitoring tools like Harmonic and Fiddler, or implementation of features from legacy platforms like Microsoft and IBM.

This lack of visibility poses real risk to existing oversight of internal tools, and now strong governance has become a rare thing.

When asked about the state of internal tools at their companies, 40% of respondents reported their governance is mostly functional, but requires significant manual effort to maintain. 37% said it’s uneven—that some teams follow processes while others operate without oversight. Just 8% reported strong internal governance with centralized controls and few blockers for builders.

10% of respondents said they address governance issues reactively as they arise rather than proactively, and 4% outright admitted that governance hasn’t kept pace with building.

Governance has not been able to keep up with the new speed of tool creation across companies of all sizes, but mid-market companies (200-999 employees) are the least mature on formal governance—19% have no formal governance approach at all, compared to 8% at enterprise (1000+ employees) and 10% at medium organizations (50-199 employees).

Governance covers who can build, what data those builders can reach, where the resulting tools run, who reviews them before they ship, and how they’re monitored afterward. It also keeps tooling aligned with business goals.

IT departments use a variety of frameworks to evaluate tools based on security, stakeholder, and business requirements, and ensure those tools remained or were adjusted as the needs of the business changed. They were the traditional gatekeepers, along with the engineers who had the specific skills to actually build a custom tool from scratch when it was required.

When asked how governance is applied to internal tools, a slight majority (52%) said they use a mix of both policies applied at the environment level and governance of individual tools.

About one-quarter of respondents (24%) set governance at the environment level exclusively, and 12% rely on governing each tool individually. 11% don’t have a formal approach at all.

With existing governance strategies already uneven and managed case-by-case, they’ll be no match for the new builders excited to build their own tools.

Technical leaders are already fighting an uphill battle to effectively monitor and harness AI-powered building, and many can now add pressure from the business to their list of obstacles.

About one-third (31%) of respondents reported a significant increase in pressure and near-zero tolerance for friction from the business when it comes to enabling AI-powered building. More than half (59%) report more, but manageable, pressure. 8% said it stayed the same, and just 2% indicated a decrease in volume of requests.

Leaders are likely facing pressure from the top down and from the bottom up. Our 2026 Build vs. Buy report released earlier this year found that 75% of builders now work under AI directives (up from 66% in October 2025). Those builders also reported boosted performance, as more are able to solve their own problems with software without waiting for engineering.

New builders who’d previously never written a line of code are clearly energized, but are bumping up against (or just going around) real governance constraints that engineers and IT professionals have always been familiar with.

Meanwhile, top brass are facing mounting pressure from boards and investors to deliver on promised AI efficiency gains. Reports on AI’s actual ROI are all over the map. Many companies still haven’t been able to scale to the type of automation maturity needed to justify the spend, in part because real ROI comes from the data connections that AI needs to be effective at the organizational level.

The people most accountable for what goes wrong are also the ones being told to move fastest: 37% of CISOs say tolerance for friction is ‘near zero,’ compared to 29% of CTOs.

It’s harder to argue for constraints when it comes to AI, especially when some of the net impacts are positive by respondents’ own admission. More than half of leaders (58%) said AI coding tools had an overall net positive impact on their engineering teams’ productivity.

Another 27% call it roughly neutral. Just 3% say it’s net negative.

The productivity gains are real for most teams—they are producing more code. But a meaningful share is paying for them on the review side.

Code review has often been cited as something that either saves engineers time or bogs them down as they generate more code with AI. The data shows that despite mixed impacts across the broad respondent pool, CTOs and CISOs experience the code review challenge differently.

When we asked these leaders how code review time has changed since adopting AI tools, 34% said review time has increased, 37% said it’s decreased, and 25% said it’s stayed about the same.

CTOs feel the review burden most acutely. 45% of CTOs say review time has increased, compared to 30% of CIOs and 28% of CISOs. And only 47% of CISOs call AI coding tools net positive overall, compared to 71% of CTOs (a 24-point gap). The people writing the code see the upside; the people securing it see the trade-off.

The tangibility of these gains makes it hard for business users and leaders to imagine hypothetical threats. A CEO can see engineering teams are producing more code and shipping more products, while threats from unsecure data remain abstract until they aren’t. Shadow AI and tools going unaccounted for become a slow-moving maintenance issue, not an emergency.

It makes it easy, then, for a leader to sidestep traditional governance when being too conservative with AI could put the business at risk. But the technical C-suite knows that the risks are real.

Lack of visibility into AI-powered tooling doesn’t mean issues aren’t happening—they are. What’s worse is that almost half of respondents (59%) can’t say for certain whether an AI-generated internal tool has caused a production incident.

A slight majority of leaders (51%) say “not to my knowledge, but I can’t say for certain” when asked if they’d had a production incident from an AI-generated internal tool. And only 19% have monitoring in place that lets them confirm they haven’t had an incident.

22% of organizations have had at least one production incident caused by an AI-generated internal tool in the past 12 months. Fortunately, just 3% report it’s become a recurring issue.

Shadow AI means more uncertainty for CTOs, CIOs, and CISOs—fear that’s likely only getting worse as news of vibe-coding tool vulnerabilities starts to surface. One cybersecurity firm recently found 380,000 publicly accessible assets built with popular vibe-coding tools, about 5,000 of which had sensitive business information. It’s easy to see how that 3% figure could grow with just a few more big breaches.

Vibe-coding tools ultimately are designed to help individual builders with individual problems. They aren’t designed with your business and security in mind, mostly with app-level permissions that a new builder won’t know how to configure correctly.

Who’s left holding the bag when AI-generated tools run amok? About one-third of respondents (32%) said engineering leadership or the CTO is held accountable for incidents with AI-generated tools, while 23% said responsibility lies with the team or individual who built it. Another third (34%) say it depends on the situation, and 10% say they haven’t defined this yet.

Taken together, 44% of these technical leaders either have no clear default for accountability or haven’t decided.

Some companies are intentionally distributing accountability. Situationally dependent accountability is backed by IBM’s 2026 survey of 2,000 CEOs, which found that 79% are distributing and expanding AI accountability as more domain experts are empowered by the technology.

Case-by-case accountability may have worked for one-off shadow IT projects or data breaches, but the explosion of vibe-coded internal tools will outpace accountability the way it will observability and security.

Ambiguity doesn’t scale, and the C-suite knows that, when it comes down to owning a major security failure, the buck often stops with them.

“When anyone can ship a tool in an afternoon, nobody signs up to maintain it,” said one CITO. “AI failures are silent—confident output that’s quietly wrong—so rot stays invisible until something breaks.”

It puts the technical C-suite in an impossible position: they’re responsible for both accelerating AI and anything that goes wrong as a result.

When we asked leaders to choose the three things that matter most to them in governing how internal tools are built, 91% chose security and data access controls: the most universally held priority in the survey. Maintainability of tools (45%) and quality and reliability of what gets shipped (42%) come next.

About one-third of respondents (33%) chose permissions to build and deploy, 31% chose observability of existing tools, and 29% of respondents chose cost and resource usage as a top priority. 18% chose minimizing duplication and tool sprawl, and only 7% chose consistency of UX patterns and logic definitions.

In last place, just 5% of respondents chose reducing bottlenecks for faster builds, despite the mounting pressure to increase AI-enabled building.

The priorities are consistent across roles and company sizes with one exception: quality and reliability is the standout priority for CTOs (55%) and for medium-sized companies (58%), while it ranks lower for CISOs (35%) and enterprise respondents (36%). Security leaders and the largest organizations are more focused on access control and observability than on whether the apps themselves are well-built.

This shows that the whole C-suite’s objectives are at risk of diverging. CEOs remain largely focused on positive and negative outcomes from fast AI enablement, and the risk of inaction on AI still often outweighs the potential security risks—at least for now.

Respondents aren’t all trying to block new builders, but 1 in 3 technical C-suiters selecting permissions around building and deploying AI apps indicate a desire to pump the brakes on the “anyone can build” train.

Asked where primary responsibility for security and access controls should live when AI tools generate internal software, 55% of leaders said it should sit in a centralized platform underneath the app, regardless of how the app was built.

26% said it should live in a policy document that builders are trained on. Only 7% said it should be configured inside each generated app by the builder. 11% said they hadn’t thought of this yet.

It’s clear to a slight majority of the technical C-suite that governance needs to adapt to the AI building era, that individual app-based permissions will no longer be enough when there are potentially dozens of apps going unaccounted for.

The question also only assessed primary responsibility. As with all risky endeavors, the solution usually isn’t any single thing. But securing those apps at the platform level first can assuage nervous CTOs, CIOs, and CISOs about the security of all the AI-generated apps they can’t see or don’t know about.

The future of AI governance will require a robust, Swiss-cheese-style approach: combining rigorous internal policy and enablement with tooling that implements that policy org-wide.

The leaders surveyed know they carry significant responsibility for risks they can’t see. 95% of them acknowledge they don’t have complete visibility into what’s running in production. 92% say their governance isn’t strong. 93% are concerned about vibe-coded internal tools. And most agree on what should change: security and access controls belong in a centralized platform underneath the app, not in policies builders may or may not follow and not configured by whoever happened to build the tool.

The path from where governance is today to where the C-suite wants it to be won’t come at the expense of builders. The pressure to enable AI-powered building is too strong, and the productivity gains are too real. Instead, the constraints need to come from a single governed place: connected to real data with the right permissions, secured by the same policies that apply to everything else, and visible to the people responsible for those risks.

Retool’s new AI-native builder is built for exactly this moment. Whether your team prompts a tool into existence, imports an existing React app, or builds through Claude Code, Codex, or Cursor, the apps land inside a governed platform with the resource model, permissions, and deployment controls your organization already trusts. Building can start anywhere. It should ship somewhere safe.

This report is based on a survey of 307 senior technology and security leaders, conducted in partnership with Wynter in May 2026. All respondents hold CTO, CIO, or CISO titles (or close variants).

The respondent pool included 43% CISOs, 35% CTOs, and 22% CIOs across Enterprise companies with 1,000+ employees (43%), Mid-Market companies with 200–999 employees (28%), and Medium companies with 50–199 employees (29%). Industries represented include SaaS and software, IT services, financial services, manufacturing, healthcare, and professional services. Cross-tabs are directional.