- AvePoint’s survey of 750 IT leaders found 88.4% of organizations running AI agents had at least one agent-related security incident in the past year.
- The most common incident types were data leakage (50.1%) and prompt/input manipulation (49.6%), highlighting overbroad access and untrusted inputs as primary risk drivers.
- The visibility problem is accelerating: organizations unable to tell if employees use unsanctioned AI tools rose from 6.3% to 17.6% in a year, and 21.1% can’t account for unsanctioned agent activity.
- Agents shift governance from managing risky outputs to preventing operational damage because they can take actions across systems without a human in the loop.
- Regulated industries with mature security programs are still getting hit, suggesting agent risk is structural rather than limited to “move fast” organizations.
AvePoint surveyed 750 IT leaders and found 88.4 percent had at least one AI agent security incident in the past year. Data leakage and prompt manipulation lead the list.
The bigger problem is visibility: the share of organizations that cannot tell whether staff are using unsanctioned AI tools nearly tripled in a year, from 6.3 percent to 17.6 percent.
Governance stopped being a policy question the moment agents started taking actions instead of just producing text. The failure mode moved from embarrassing output to operational damage.
AvePoint's 2026 State of AI report went out to 750 IT leaders across financial services, healthcare, and government. These are regulated industries with security budgets and compliance teams. And 88.4 percent of them reported at least one AI agent security incident in the last twelve months.
Read that again. This is not a survey of startups moving fast and breaking things. It is banks, hospitals, and government agencies, the places that are supposed to be slow and careful, and almost all of them have already been burned.
What actually went wrong
The two most common incident types tell you where the risk lives. Data leakage showed up in 50.1 percent of reported incidents. Manipulation through malicious or untrusted input showed up in 49.6 percent. Roughly half and half, and both point at the same structural weakness.
Data leakage is the agent doing exactly what it was told, just with access it should not have had. Someone wires an agent into the CRM, the ticketing system, and a shared drive, and now a single badly scoped query can pull customer records into a summary that lands in the wrong Slack channel. The agent did not malfunction. The permissions did.
Manipulation is worse because the attack surface is the input itself. A support agent reads a ticket, and the ticket contains instructions. A code agent reads a dependency's README, and the README contains instructions. The model cannot reliably tell the difference between content it should act on and content it should merely process. I wrote about this exact failure a few weeks ago when a bug report turned out to be the attack. The AvePoint numbers say it is not an edge case. It is half of all reported incidents.
The visibility gap matters more than the breach count
One number should worry you more than the 88 percent. The share of organizations that cannot determine whether employees are using unsanctioned AI tools went from 6.3 percent in 2025 to 17.6 percent in 2026. For agents specifically, 21.1 percent cannot account for unsanctioned agent activity at all.
One in five companies has agents running that the security team does not know about.
This is the shadow IT problem, except shadow IT used to mean someone signed up for a SaaS tool on a company card. You could find it in the expense report. A shadow agent leaves a much fainter trace. Someone spins up a workflow in a tool they already pay for, points it at a few internal systems, and it runs. No procurement, no review, no line item. It just starts acting on company data.
The visibility gap nearly tripled in a single year because adoption outran the ability to see it. Nearly half of employees now use agents weekly or daily. The tooling to inventory those agents, scope their permissions, and log what they touch did not scale at the same rate. So the gap opened.
Why agents break governance that worked fine for chatbots
For two years the governance conversation was about generative AI, and it was mostly about output. Would the model say something offensive, leak a prompt, hallucinate a fact into a customer email. Those are real problems, but they are output problems. A human sits between the model and any consequence.
Agents remove the human from the middle. That is the entire point of an agent. It reads, decides, and acts, often across several systems, often without anyone watching each step. So when governance is weak, the consequence is no longer a bad sentence. It is a deleted record, a sent email, a merged pull request, a refund issued, a file moved. Operational, immediate, and hard to walk back.
This maps onto a framework I use constantly. The human's two jobs with any agent are to set the bar before it runs and hold the bar after. Set the bar means specify what it can touch and what good looks like. Hold the bar means verify what it did. The 88 percent number is what happens when companies deploy the middle, the acting part, without building either end.
What to actually do about it
None of this is an argument against agents. The adoption numbers are not going to reverse, and they should not. But the security data says three things are non-negotiable if you are running agents in production.
Scope permissions per agent, not per user. The most common failure is an agent inheriting a human's full access when it needs a thin slice. If your support agent can read the entire customer database to answer one question, you have already lost. Give each agent the narrowest set of credentials that lets it do its one job.
Treat every input as untrusted. Half the incidents came from manipulation. That means the ticket, the email, the document, the web page the agent reads are all potential injection vectors. The agent should not have the authority to act on instructions it finds inside content it was asked to process. Separate the two paths.
Build an inventory before you build more agents. You cannot secure what you cannot see, and one in five companies literally cannot see their agents. A simple registry of every agent, what it can access, and what it has done is boring infrastructure. It is also the thing that turns a shadow agent back into a governed one.
The 88 percent figure is going to keep climbing as long as adoption outpaces control. The companies that pull ahead will not be the ones that deployed agents fastest. They will be the ones that could still see every agent they deployed.
Assume agents are already creating risk in your environment and start by improving visibility: inventory where agents exist, who created them, what systems they can access, and what they do. Tighten permissions and data boundaries so agents only see what they need, and treat any external or user-provided text (tickets, emails, docs, READMEs) as untrusted input that must be isolated from instructions. Finally, add logging and review for agent actions—not just outputs—so you can detect shadow agents and investigate incidents quickly.