Closing the Gap in Enterprise AI Security

UltraViolet Cyber runs security programs across red, blue, and purple team disciplines for more than 400 Global 2000 enterprises and federal agencies. That work gives us a direct view of how large organizations actually run their security functions. As AI reshaped those programs, we started seeing the same questions, the same gaps, and the same improvised controls show up across clients in different industries. This study makes that pattern visible, at scale, with one methodology. Our team includes former U.S. intelligence operators with more than 30 years of combined experience defending national and commercial systems.

The AISec Study is a practitioner-led benchmark for how organizations govern, build, and defend AI. It applies the interview-based methodology behind BSIMM, the long-running benchmark for software security programs, to AI for the first time. UltraViolet interviewers sat down with security, AI, governance, and engineering leadership at 10 organizations and scored each program against a fixed catalog of 64 activities across 10 capabilities. That produced 640 scored observations, replacing guesswork about AI security posture with data drawn directly from the people who do the work.

Overall AI security coverage, the share of the 64-activity framework each organization has in place, ranged from 43% to 85%, with a pool median of 55%. The AISec Study groups that score into four bands: Leading (80%+), Established (60-79%), Developing (40-59%), and Early (below 40%). Seven of the 10 organizations landed in Developing, two reached Established, and one reached Leading. None scored Early.

Governance and oversight run ahead of the engineering and assurance work that puts governance into practice at every organization in the study. All 10 have a documented AI strategy, executive sponsorship, and a central AI inventory. Only 2 of 10 track whether code was AI-generated, only 3 have working bias testing, and detection of automated attacks against AI showed up at just 1.

The sections that follow walk through how the study was built, where the data pool is strongest and weakest, and the practices the highest-scoring programs share.

No two programs in the study think about AI security in quite the same way. The interviews surfaced strong, and sometimes opposing, convictions about what the work should be. A few stood out, along with one problem almost everyone named.

AISec is practitioner-led. Each participant is assessed through confidential interviews with security, AI, governance, and engineering leadership, then scored against 64 activities organized into 10 capabilities across three domains (Direction & Oversight, Engineering & Usage, Assurance & Protection), producing 640 scored observations in this phase.

Each activity is scored Established (consistently performed with process and tooling, 1.0), Emerging (partial, piloted, or planned, 0.5), or Unobserved (no evidence, 0). Capability and overall coverage scores are the sum of activity scores as a share of the maximum possible. The scale is deliberately simple so results stay comparable as the data pool grows.

Every score comes from a conversation, not a questionnaire. Interviewers sit with the security, AI, data, governance, and engineering leaders who run the work day to day, and map what they hear against the catalog rather than taking a self-rating at face value. It is slower than a survey and much harder to overstate. It is also the reason the results describe what teams actually do, not what they intend to do.

The 64 activities roll up into 10 capabilities, which sit inside three domains. The domains are the simplest way to read the results: they separate deciding what to do with AI from building with it and from defending it.

A capability score is the share of its activities that are in place, weighted by depth. Domain and overall scores use the same calculation across every activity in the group, so they are activity-weighted and need not match a simple average of the capability scores. Breadth, meaning how many of the 64 activities an organization has started at all, is tracked separately from depth, meaning how consistently those activities are performed. Borderline calls are calibrated against how peer organizations scored the same activity, so a given score means the same thing across the pool.

Overall coverage scores ranged from 43% to 85%, with a data-pool median of 55.0%. The ten organizations span banking and financial services, enterprise software and SaaS, healthcare, manufacturing, hospitality, government, and the nonprofit sector.

The pool is mixed on purpose. It spans a few-hundred-person software company to a global bank, and public companies, private companies, a nonprofit, and a government agency. That range is what lets the study check whether the same patterns hold regardless of size or structure. Several have reshaped their business around AI over the last few years, moving to an AI-native or AI-first model, and have had to adapt their security programs and practices just as quickly.

The organizations cluster more tightly than the 43-to-85 range suggests. Seven of the ten fall in the Developing band, two are Established, and one has reached Leading. The mean is 58.7 percent and the median 55, so a couple of stronger programs pull the average above where most of the pool actually sits.

The takeaway for a participant is less about the top and bottom of the range than about the middle. Because most of the pool sits inside a fifteen-point window, small differences in how consistently a handful of harder controls are performed are enough to move an organization several places.

Governance & Policy is the strongest capability at 80%; Incident Response is the weakest at 47%. By domain, Direction & Oversight averages 72%, Assurance & Protection 55%, and Engineering & Usage 53%.

This is not a quirk of the sample. The capabilities that depend on policy and oversight, Governance & Policy (80%), Visibility (70%), and Strategy (66%), lead the framework. The capabilities that depend on sustained engineering work, AI-Augmented SDLC (49%), AI-Augmented SecOps (50%), and Incident Response (47%), trail it. Strategy is the most evenly developed capability: every organization scored at least 50%. AI-Augmented SDLC has the lowest ceiling, only one organization exceeded 60%.

A clear set of table-stakes controls is now observed at all 10 organizations, while a frontier of verification and detection activities remains rare across the pool. 13 of the 64 activities are not yet Established at any organization.

The rarest activities cluster around verifying that AI behaves as intended: only 2 of 10 organizations track whether code was AI-generated, only 3 have operationalized bias testing, and detection of automated attacks against AI is observed at just one. These are the controls that turn a governed program into a defended one, and they are the clearest shared opportunity across the pool.

In about three years the software development lifecycle has started to change shape. Across the ten organizations, teams now approve fleets of AI coding and testing agents, feed them the codebase and coding standards, and route their output through the pipeline. The industry has started to name this: AWS calls it the AI-Driven Development Lifecycle (AI-DLC)¹, the literature calls it the AI-Native SDLC. The harder question now is not how to build with AI, but how to secure a development process that runs at machine speed.

The study data gives an unusually clear answer to where that securing actually stands. Measured strictly, by whether a control is repeatable and enforced rather than merely started, one control is universal and the rest of the lifecycle is still being built.

1. AWS, “Introducing the AI-Driven Development Lifecycle (AI-DLC),” re:Invent 2025 (session DVT214).

The same finding holds here: adoption and governance have outrun engineering and assurance, this time in how software gets built. Every organization has learned to let AI into the lifecycle at the front door, approving the agents and scanning their output, but almost none has built the assurance the AI lifecycle specifically demands. The frontier is the same everywhere: the ability to know which code an agent wrote and to prove it is clean to ship. As the pool grows, this is the practice to watch, and the clearest place the field’s next investment needs to go.

No organization has a complete secure AI lifecycle, but several have built real, independent pieces of one without a shared blueprint. When separate teams land on the same controls without comparing notes, that signals more about where the field is heading than any single score does. These are real programs from the study, described anonymously.

What to watch. The next phase of this practice is the assurance that wraps the lifecycle: provenance and attribution of AI-written code, license and IP screening built for generated code, and continuous AI-specific validation. These are the controls almost no one has established, and they are where the study expects the fastest movement as the data pool grows.

Behind the scores are recurring practices. Because every organization is assessed against the same activities, the study can see not only where the data pool sits but how the leaders got there. The practices below appear independently across multiple programs, described here without attribution. When several programs build the same control without comparing notes, it is a fair sign the practice is becoming standard.

Some controls are now established at most organizations, while the engineering and assurance controls behind them are not. The pattern below follows the study's central finding: the closer a control sits to policy and oversight, the more organizations have made it routine; the closer it sits to hands-on engineering, the fewer have.

The following are drawn from the highest-scoring programs in the pool and generalize cleanly. None depends on scale or sector; each is a practice a mid-pack program could adopt to move from a governed program to a defended one.

The AISec framework is a fixed catalog of 64 observable activities, organized into 10 capabilities across three domains. Every organization in the study is scored against this same list, which is what makes the results comparable. The full catalog is reproduced below so a reader can see exactly what is measured. For each activity, obs is how many of the 10 organizations show the activity at all (Established or Emerging), and est is how many have it fully Established, meaning consistently performed with process and tooling behind it.

Plain-language definitions of the framework terms, standards, and technical terms used in this report.