Fifty-four percent of enterprises have already had a confirmed AI agent security incident or a near-miss. That’s the headline number from a survey of 107 enterprises covered by VentureBeat AI, and it lands at an awkward moment: companies are handing agents real access to production systems while the guardrails meant to contain them are still on the roadmap.
What stands out here isn’t the incident rate. It’s the identity gap sitting right next to it.
📊 The numbers
Enterprises with a confirmed agent incident or near-miss: 54%
Enterprises giving every agent its own scoped identity: ~33%
Agents sharing credentials: Most
Read those three rows together and the picture gets uncomfortable. Roughly two thirds of companies running agents can’t tell you which agent did what, because the agents are borrowing the same credentials. When something goes wrong, there’s no clean audit trail. There’s just a service account that a dozen automations happen to share.
As VentureBeat AI puts it, agents are “being given real access to systems and data while the controls meant to contain them lag behind.”
🔍 What the researchers looked at
The study surveyed 107 enterprises about how they deploy agents and how they secure them. Two things got measured: whether an agent had caused a security event (confirmed incident or near-miss), and whether the organization issues each agent a distinct, scoped identity rather than a shared credential.
That second question is the useful one. Scoped identity is the difference between “an agent accessed the customer database” and “the invoice-reconciliation agent, running under its own service principal, read exactly the three tables it’s permitted to read.” One is a forensic dead end. The other is a log line you can act on.
⚠️ Why this matters for practitioners
A shared credential turns every agent into every other agent. Blast radius becomes total. If a prompt injection convinces one agent to do something it shouldn’t, it does so with the full permission set of the shared account, not with the narrow slice its actual job requires.
This is the same mistake enterprises made with microservices a decade ago, and then with CI/CD runners after that. The pattern repeats because shared credentials are the fastest path to a working demo. They just don’t survive contact with an incident review.
The 54% figure also deserves a second look. That’s confirmed incidents and near-misses, which means it counts the organizations mature enough to detect and classify the event. Companies without per-agent identity often can’t detect these events at all. The real rate is probably higher than what got reported, not lower.
🛠️ What you can actually do
Three moves, roughly in order of payoff:
- Issue every agent its own identity. Not per-team, not per-application. Per-agent. If you can’t name the agent from a log entry, you don’t have identity, you have a shared password with extra steps.
- Scope permissions to the task, not the team. An agent that summarizes support tickets doesn’t need write access to the CRM. Start from zero and add what breaks.
- Treat near-misses as incidents. They’re free data. The organizations in this survey that reported near-misses are the ones with enough visibility to catch them, which is a maturity signal, not a black mark.
🧭 The caveats
One survey, 107 enterprises. That’s a real sample but not a huge one, and self-reported security data always skews toward whoever’s willing to talk about it. The findings tell you about the shape of the problem, not the precise size.
Still, the direction is clear enough to act on. Agent deployment is running ahead of agent governance, and the identity layer is where the gap is widest. The companies that close it now are the ones that won’t be explaining a shared service account to their auditors next year.
Full details are available at the original source.