IBM put out its annual Cost of a Data Breach Report this summer, and Cybersecurity Dive pulled out the stat everybody's going to quote at your next board meeting:

"The vast majority (92%) of organizations that suffered attacks on their AI models failed to properly control access to those tools."

Let me spell that out… Ninety-two percent. Only four in ten organizations said they limit access to their AI systems at all. The average breach now costs $5 million, up 12% in a year, and the attacks that go after the AI itself (prompt injection, model inversion) run closer to $6 million.

Then there's the line I keep coming back to. IBM's researchers say identity controls "have failed to keep pace" with AI's sprawl across corporate networks, and:

"The outcome is predictable: expanded attack paths, higher financial impact and incidents driven by basic enforcement gaps that don't even require attacker sophistication."

Don't even require attacker sophistication. Nobody's burning a zero-day here. The door was open. Actually... there were a lot of doors, and most of them were open.

Sprawl is the story, not AI

It's tempting to read this as "AI is dangerous, buy an AI security tool." (IBM also found 85% of breached organizations plan to spend more on "security tools and governance." More tools! That'll help!)

But look at the word IBM actually used: sprawl.

That's the story this publication has been telling since day one. The cloud made adding free. A new database is a few more lines in a template. A new queue, a new cache, a new vector store... a few more lines each. The cost of owning all of it (the bill, the attack surface, the 3am page) never went down. It just got harder to see.

AI didn't invent this. It removed the last bit of friction. Somebody spins up an agent, gives it a service account "just to try it out," points it at the warehouse, and now there's a new door into your data that never went through a security review because... well, there was no moment when anybody decided to add it. It just showed up.

IBM measured exactly that. Shadow AI was involved in 43% of security incidents, more than double the year before. More than two-thirds of organizations have no process to limit it.

You can't govern what you can't count. And you can't count what gets added for free.

Every path to the data is a door

Here's the way I think about it. An attacker (or a confused agent, or a very helpful prompt injection) doesn't care about your org chart. They care about paths to the data.

In a typical enterprise stack, count them:

the BI tool           → its own service account → warehouse
the app backend       → ORM → connection pool → warehouse
the new AI agent      → "temporary" API key → warehouse
the other AI agent    → someone's personal token → warehouse
the reverse-ETL job   → another service account → warehouse
the data science box  → a copy of the data → S3 bucket nobody remembers

Every one of those arrows is a door. Every door needs its own lock, its own key rotation, its own audit trail, and its own person who remembers it exists. IBM's 92% isn't people being lazy. It's people trying to guard more doors than they know they have.

That's Rule 4 of the Flat Stack: security, availability, and resilience are not features. Security at the gateway, never bolted on. If there's one road to the data, you guard the road. If there are forty, you're going to miss some, and IBM just told you you're probably missing most of them.

The glue layer is where the doors breed

This part doesn't show up in a breach report, but it's where a lot of this sprawl actually lives.

Think about how much code sits between "the user clicked a button" and "the data came back." There's a fetch wrapper. A client-side cache. A state-management library to hold what came back. A query library to keep that state in sync with the server. An auth middleware. A server-side cache adapter. An ORM. A retry library. A library that serializes dates, because of course dates.

Every one of those is an npm install. Every npm install pulls in its own little city of dependencies. And (we covered this three weeks ago when 400+ packages in the keyv ecosystem shipped credential-stealing malware) every one of them runs with the privileges of your process, not the privileges of its job.

Your little cache adapter can read the same environment variables as your payment code. It can see the warehouse credentials. And if you've wired an AI feature into that app, it can see the model API keys too.

That's the glue layer. Dozens of middleman packages whose whole job is to shuttle data between the front end and the back end, and each one is:

  • another thing to patch,
  • another maintainer account that can get phished,
  • another spot where a credential sits in memory,
  • another place where "who is asking for this data?" gets lost on the way through.

That last one matters most for the IBM story. By the time a request has gone through six layers of glue, the original caller's identity has usually been swapped for one big shared service account. The database has no idea whether a person, a cron job, or a prompt-injected agent is asking. So of course access control fails. The information it needs got thrown away three packages ago.

Rule 5: every dependency is a decision. The glue layer is a pile of decisions nobody made.

What flat looks like

A flat stack doesn't fix this with a better lock on every door. It fixes it by building fewer doors.

Collapse the glue. Most of what that middleman layer does falls into a few jobs: cache the answer, check who's asking, fetch the data, write down what happened. You don't need a dozen packages for that, spread across your front end and back end, each one running as you. Do those jobs once, in one place, in front of the data. Where the answer can be precomputed, precompute it and serve it as a static file. That isn't just a performance trick. A static file has no runtime to exploit, no dependency to poison, and no credential to leak.

Keep identity intact all the way to the data. The caller's own token should be what reaches the database, so your row-level security and masking rules actually apply to the person (or the agent) asking. No shared god-account in the middle.

One path, including for agents. AI agents shouldn't get a special side door. They should come through the same road as everything else, under the same rules. If the only way to the data is the governed way, shadow AI stops being invisible, because there's nowhere else for it to go.

Keep the data low and yours. IBM also found that on-premises systems got breached more than any cloud environment, and most victims hadn't encrypted their data. Rule 2 says keep your center of gravity low: data in one place, in storage you control, in open formats. That's not "move everything to the cloud." It's "stop scattering copies." The forgotten extract on the data science box is a door too.

Write it down where you can read it. When something does go wrong, you want one audit record per query, in one format, in your own storage. Not a hunt through seven vendors' log formats during the worst week of your year.

Where airbrx fits (yes, this is the plug)

This publication is a community project of airbrx, and this is exactly the problem the airbrx gateway was built for: it's the flat-stack doctrine shipped as a product.

It sits in front of Snowflake, Databricks, and Postgres, speaks the protocols your apps already use, and becomes that one road to the data:

  • Credential pass-through. Queries run under the caller's own token, so the row-level security and masking you already have apply exactly as they do today.
  • A rules engine at the gateway. Serve a request or turn it away by caller, by identity, or by time of day, before it reaches the engine.
  • The same controls for agents. An MCP server gives AI agents the same governed path as everything else, not a side door.
  • Audit in your own bucket. One record per query, in a fixed shape, written to storage you own.
  • Deterministic caching. Repeated questions get answered from a predictable key without waking the warehouse, which does a lot of the job that half your glue-layer cache packages were installed for.

One hostname changes. The apps you haven't pointed at it keep working exactly as they did.

Is that the whole answer to IBM's report? No. You still need encryption, you still need to patch things, and you still need someone who says "no" to the fifth agent pilot this quarter. There's always a tradeoff. Putting everything through one road means that road has to be solid, which is why it runs in your own account if you want it to. But one well-guarded road is a problem you can actually solve. Forty roads with forty different locks is the problem IBM just measured.

The bottom line

IBM's numbers read like an AI story. They're really an inventory story.

92% didn't control access to their AI because nobody had a list of the doors. Shadow AI doubled because adding it cost nothing. Breach costs went up 12% because every new path to the data is one more path an attacker gets to try, and "attacks that don't even require attacker sophistication" is just what it looks like when somebody finds a door you forgot you built.

You don't need more locks. You need fewer doors.

Access control fails when identity gets lost on the way to the data. Every layer of glue between the caller and the data is a place for it to get lost.