9 in 10 Enterprises Had an AI Agent Security Breach — Your AI-Powered App Is Next

Three separate sources, three different methodologies, one message: if you deployed an AI agent last year, it probably got breached.

AvePoint surveyed 750 IT leaders across financial services, healthcare, and government. Result: 88.4% of organisations had at least one AI agent-related security incident in the past 12 months. Token Security analysed its enterprise customer base and found 65% had suffered AI agent security events. On Reddit's r/cybersecurity, a community-maintained tracker now catalogues 90 confirmed incidents, updated weekly.

These are independent data sets collected by people with different incentives and different definitions of what counts. They all point the same direction.

The top two attack vectors explain the pattern. Data leakage accounts for 50.1% of incidents. Prompt injection and input manipulation for 49.6%. Together they represent virtually all breaches, and they share a common root cause: AI agents are being connected to sensitive systems without a proper access control layer.

This started in enterprise IT, but it won't stay there

It is tempting to file a survey of 750 regulated-organisation IT leaders under "someone else's problem." Enterprise IT has compliance departments, security operations centres, and budgets that would fund a small country's defence ministry. Your ops team has none of those things.

But the mechanics of these breaches do not care about company size. The architecture that produces a data leak at a bank is functionally identical to the one that produces it at a 50-person firm: an agent gets access to data, nobody enforces boundaries around what it should actually reach, and sensitive information walks out.

The difference: the bank has cyber insurance and an incident response retainer. The 50-person company has a Google Doc called "security plan" that nobody has opened since onboarding week.

The AvePoint report also surfaced a stat I find more troubling than the breach rate. The proportion of organisations unable to determine whether employees use unsanctioned AI tools went from 6.3% in 2025 to 17.6%. Nearly tripled. For AI agents, the blind spot is 21.1%.

In plain English: the tools are spreading faster than anyone's ability to track them, and the tracking is getting worse.

How your AI-built app becomes an attack surface

The structural problem with AI coding tools is not that they write bad code. It's that they write functional code without ever asking about security.

Prompt an AI to build a customer dashboard, and it spins up an API endpoint that queries your database and returns results. It will not ask whether the endpoint requires authentication. It will not ask which rows each user should see. It will not warn you that the API key embedded in the frontend is visible to anyone opening browser dev tools.

The tools optimise for "does this do what you asked" and treat everything else as noise. When the person prompting has never heard "principle of least privilege" and assumes the tool would flag problems, your customer database gets an unauthenticated front door.

The Reddit tracker includes multiple incidents matching this exact pattern: AI-generated internal tools exposed production data because nobody thought to wire up authentication. The tool worked, the team celebrated, and months later someone discovered customer records were visible to anyone with the URL.

How the attacks actually work

Data leakage is the simpler vector. Your agent or AI-built app connects to something it should not, reads more than it should, or exposes what it read. Most AI-generated apps have no access model. The agent inherits the permissions of whoever set it up. In a small company where the ops lead has database admin access, that is everything.

Prompt injection is stranger and harder to defend against. An attacker hides instructions inside something the agent processes, a document, an email, a webpage. The agent reads it, treats the hidden instructions as legitimate, and acts. It might exfiltrate data, change permissions, or forward internal messages externally. The agent did not malfunction. It followed the instructions it found, exactly as designed.

The core problem: agents cannot distinguish your instructions from an attacker's. That is not a bug. It is the current state of the technology. OWASP ranks prompt injection as the number one risk for LLM applications. Every major AI lab acknowledges it as unsolved.

Combine these two vectors and you get the 88% breach rate: agents that can reach everything and will cheerfully obey anyone who knows how to phrase the request.

The visibility gap is a design feature, not an accident

The tripling of "we don't know what our employees are using" deserves its own moment. AI tools are built for individual productivity. Sign up with an email, start prompting, get results. No procurement, no security review, no architecture board approval. That is the value proposition.

The problem arrives when the thing you built in an afternoon becomes what the whole department relies on. Nobody knows who owns it, what it connects to, or whether it logs anything. Security teams cannot protect what they don't know exists.

AvePoint also found 35.5% of enterprise data is already AI-generated, projected at 42.1% within 12 months. AI is becoming the primary way data enters organisations. If the tools producing that data have no governance, the governance problem scales with the data volume.

Build on a foundation that already has guardrails

Enterprises are responding by buying AI governance platforms. Nearly nine in ten have delayed AI deployments by an average of six months because their readiness posture isn't where it needs to be. That approach makes sense if you have a compliance mandate and the budget to match.

Most teams reading this have neither. They need governance that arrives with the tool, not governance they bolt on afterwards.

That is the structural argument for platforms where access control is not optional. Build on Bubble or Webflow, and the platform enforces authentication and permission models because those things are built into how it operates. You cannot accidentally expose every row in your customer table because the platform won't let you. Stacker, the platform we build at nocode.tech, takes the same approach: portals, roles, and row-level permissions are infrastructure, not features you remember to add later.

This is an argument about which category of tool is safer when the builder lacks a security background. AI coding tools give maximum flexibility with zero guardrails. Structured platforms give less flexibility with built-in guardrails. For internal business applications where data is sensitive and the builder is an ops person who learned prompting last month, the trade-off is obvious.

The three data sources agree on the what. Between two-thirds and nine-tenths of all AI agent deployments experienced a breach. They agree on the why: absent access controls and prompt injection. The fix, for anyone not running a security operations centre, is simpler than the industry would have you believe. Pick platforms where permissions are infrastructure, not an afterthought. Then, at minimum, you know the breaches everyone else is having are not happening on your watch.