54% of firms have had an AI agent incident, most still share keys

Most writing about AI agents is about what agents can do. This survey is about what they have already broken, and why. The answer is not the model. It is a very old question: who is holding the keys.

What the survey found

VentureBeat asked 107 organisations a very concrete question: have you had a security incident involving an AI agent? 18% reported a confirmed incident. 36% reported a near-miss caught before it caused harm. Together that is 54%, with only 42% reporting nothing at all. The striking figure is not the 18% but the 36%: enterprises are catching problems, and catching them close to the edge.

Exposure scales with size; containment does not. The incident-or-near-miss rate rises from 49% among companies with 101 to 1,000 employees to 63% above 1,000, while sandbox isolation of high-risk agents falls from 35% to 20%. The organisations running the most agents across the most systems carry the most incidents and the least of the one control that bounds the damage.

The root cause is not the model, it is the shared keyring

Only 32% of organisations give every agent its own scoped, managed identity. 48% say some agents have scoped identities but many still share credentials, and 32% admit their agents mostly run on shared API keys or borrowed human and service accounts. Rolled together, 69% have credential sharing somewhere in their agent fleet.

The consequence is measurable. Organisations with credential sharing anywhere were hit with an incident or near-miss over twelve months at 63.5%; organisations where every agent carries its own scoped identity were hit at 40.9%. That is a 23 point difference. The fully-scoped group is small, so this is an association rather than proven causation, but the direction is clear. When agents share one key, one faulty agent opens every door on the ring, and forensics afterwards cannot tell which agent did what.

The order of defences is also inverted. 49% enforce scoped permissions at runtime and 47% monitor and log agent activity, but only 30% isolate high-risk agents. Observation tells you what happened, enforcement tries to prevent it, and isolation is what limits the damage when the first two fail - and isolation is the control fewest organisations have built.

69% of organisations have several agents sharing one key - a keyring that opens far too many doors. Photo: Matilda Vaughan, Museums Victoria, CC BY 4.0.

High satisfaction, thin budgets, and everyone about to switch

Here is the puzzling part. Satisfaction with current agent security tooling averages 4.2 out of 5, among the highest readings in the series. Yet 82% name a control bundled with their model provider or cloud platform as their primary agent security layer, rather than anything purpose-built for agents. Budgets are thin: 46% allocate 6 to 10% of their security budget to agents, and 34% spend 5% or less.

Then two numbers break the calm. Only 35% believe their defences are ahead of AI-enabled attackers. And 59% plan to adopt, add or replace agent security tooling within twelve months, 29% of them within the next quarter. In other words, people are satisfied with a stack they are simultaneously preparing to replace. Incidents are what start the buying cycle: among organisations already hit, 42.1% plan to change tooling within 90 days, against 14% of those not hit.

Nearly half of organisations give agent security only 6 to 10% of the security budget, while more than half have already had an event. Photo: Wilfred Iven, StockSnap, CC0 licence.

The Chạm AI view: how a Vietnamese SME should read this

First, a caveat on reliability. The sample is 107 self-selected organisations skewed toward the US mid-market. This is a directional signal, not a precise measurement, and the Vietnamese context differs. But the failure mechanism is identical, only smaller in scale.

The local version of this gap is familiar: a chatbot on the website, a Zalo bot, a Messenger bot, all three running on one API key pasted into a config file on launch day. Everyone has that key. The previous web developer still has it. Nobody remembers what permissions it carries. That is exactly the situation the numbers above describe, minus the survey that counts it.

Three cheap fixes. One, one key per agent. Split keys by channel and by function; never let a single key both read orders and edit prices. Two, scope permissions to the job. A question-answering bot needs read access only; write, refund and order-status rights should be separate and gated by a human confirmation - the same failure our 7 AI agent implementation mistakes piece calls a vague scope. Three, log every action that changes data, tagged with the agent that caused it. Without logs, an incident leaves you guessing.

None of these cost software money; they cost discipline at configuration time. They also sit inside our AI agent implementation process and follow directly from the data security principles for AI agents we published earlier. And they point at the same place as Gartner's agent sprawl warning: the problem is not how many agents you run, but whether each one is clearly defined - what it does, what it can read, and who answers when it gets something wrong.

Sources: VentureBeat Pulse Research - "The agent security gap: 54% of enterprises have already had an AI agent incident, and most still let agents share credentials", published 23 July 2026, June 2026 survey wave, n=107 organisations with 100+ employees · A Caylent survey conducted by Censuswide (published 6 August 2026, 200 senior leaders at organisations with 1,000+ employees in the US and Canada) points the same way: 83% place guardrails on equal or higher footing than model intelligence · Deloitte likewise reports that AI agents are scaling faster than their guardrails. International figures, offered as reference for the Vietnamese market.

Frequently asked questions