Your security team didn't fail. Your AI deployment process did, and last year, 78% of enterprises found out the hard way.
That number comes from a DigiCert-commissioned survey of 1,001 IT and cybersecurity leaders conducted in 2026. Nearly four out of five enterprises reported AI-related security incidents or identified material AI-related vulnerabilities in the prior twelve months. Most of those incidents were not caused by flawed AI models or broken code. They were caused by unauthorized or misconfigured AI agents. These tools were deployed without defined permissions, clear ownership, or anyone in security knowing they existed.
That is a deployment governance problem. Not a model problem.

The Vendors Are Asking the Wrong Question
Every security vendor citing this survey is selling you a detection tool. The pitch is predictable: AI creates new attack surfaces; you need better visibility, here's our platform.
The framing is wrong, and it will cost you.
Detection only works on threats you can see. If you don't know what AI agents are running in your environment, what data they can access, and who authorized them, no detection tool closes that gap. You are not looking for a needle in a haystack. You are standing in a field that may or may not be a haystack.
The enterprises that avoided incidents in the DigiCert survey didn't have better detection. They had better discipline: defined agent permissions, deployment pipelines with real governance, documented ownership, and clear lines on what AI tools are authorized and unauthorized to touch.
That discipline is not a security capability. It is an AI deployment capability. And most organizations don't have it.
Why "Experimentation Culture" Became a Security Liability
A companion analysis published the same week put a sharper edge on the root cause. AI doesn't introduce new threat categories; it acts as a force multiplier on the technical debt and governance gaps that already exist.
Most enterprises spent the last two years encouraging AI adoption. Product teams ran pilots. Engineers connected tools to internal systems. Department heads subscribed to AI platforms on corporate cards and integrated them into workflows without an IT ticket. This wasn't recklessness. It was the culture of organizations deliberately built to accelerate adoption.
The problem is asymmetric accountability. The teams building with AI are rewarded for speed. The teams responsible for security inherit the surface area. By the time security learns that an AI agent was granted broad access to a customer's data repository, the deployment has been in production for months.
This is what "experimentation entitlement" looks like at scale. And the 78% figure reflects where it lands.
The Gap Between "We Deployed AI" and "We Deployed AI Responsibly"

Three governance failures show up consistently in enterprises that experienced incidents:
No agent inventory. Most organizations cannot produce a complete list of AI tools deployed across their environment — who deployed them, when, what systems they connect to, and what permissions they hold. If you can't inventory it, you can't govern it.
No permission framework. Deploying an AI agent without defined permission boundaries is equivalent to onboarding an employee without telling them which systems they can access. It works fine until it doesn't. At enterprise scale, "until it doesn't" will arrive faster than most security teams would expect.
No ownership accountability. When an AI agent causes an incident, the question "who owns this?" should have a single, immediate answer. In most enterprises, it doesn't exist. The deployment was approved by one team, built by another, and integrated by a third — and nobody explicitly accepted ongoing accountability for its behavior.
These are not security architecture failures. They are operational governance failures that create security consequences. The distinction matters because the fix is different.
What the Enterprises That Avoided Incidents Did Differently

The pattern is consistent across organizations that have formalized AI governance before incidents forced the issue: they treated AI deployment like any other access-granting event in their environment.
Before a new AI agent goes into production, it has a defined owner. Its permissions are scoped to the minimum required. It is logged in the same systems that track every other privileged tool. Someone is accountable for reviewing its behavior on a defined cadence.
None of that requires a new security platform. It requires a governance process—applied specifically to AI deployment —built before deployments scale beyond the point where governance becomes practically impossible to retrofit.
The window for building this before the incident is closing. The 78% figure is last year's data. Organizations that still haven't formalized AI deployment governance are accumulating surface area every month. This year's survey number will be worse for them.
Three Questions Your IT and Security Leadership Should Be Able to Answer Today
If the answers aren't immediate, the governance gap is already material:
1. How many AI agents are currently deployed in your environment — across all teams and departments? Not estimates. A documented inventory.
2. For each agent, who is the named owner accountable for its permissions and behavior? A team name is not the owner. A person is.
3. What is your process for reviewing and revoking AI agent access when scope changes or the agent is decommissioned? If the answer is "we'd figure it out," that is not a process.
The Starting Point Is Inventory, Not Detection
Before your security team can defend an AI deployment, your IT leadership needs to know what they're defending. That means an honest inventory of what's deployed, a clear picture of what each agent can access, and a governance framework that makes future deployments auditable by default.
That work happens before the security tooling conversation. It's an AI readiness problem, not a detection problem.
Redapt's AI Readiness Assessment gives your IT and security leadership a structured three-week engagement to inventory AI tool deployments, map agent permissions, identify governance gaps, and build a prioritized remediation roadmap — before your incident becomes a statistic in next year's survey.


